draft-beaulieu-ike-xauth-02.txt

ipsec vpn

7. XAUTH Notification

   It is important the edge device be able to notify the remote device
   of its intent to prompt for extended authentication.  If such a
   mechanism were not present, the remote device would send a Quick
   Mode message, or a Mode-Cfg message before authentication was
   complete, and the state machines would get pretty complicated.

   We present here two methods of accomplishing this.  The first is the
   simplest, and most intuitive.  However it is not possible to achieve
   this within the [IKE] protocol as it stands today, and is therefore
   not recommended.  It has been added to this document for
   completeness, and may be used in future versions of this document.

7.1 Notification payloads within a phase 1 exchange

   The following method is used to notify the remote device that an
   XAUTH exchange will follow the phase 1 exchange.  Once the edge
   device does a policy lookup for the peer, the edge device appends a
   notify payload to any phase 1 exchange packet, indicating that an
   XAUTH exchange will follow.  Note, that this notify payload is
   unauthenticated unless both devices support the mechanisms described
   in [KIV].  Therefore, implementations MUST NOT use this method
   unless they are also using the mechanisms described in [KIV].


Beaulieu, Pereira                                                   11

       Extended Authentication with ISAKMP/Oakley October 2001


   Once again, this method is not part of the XAUTH protocol in its
   present form.  It has only been added here for completeness, and may
   be used in future versions of this document.

   No payload definitions, assigned numbers, or vendor ID payloads will
   be provided for this method, as it is currently not part of the
   XAUTH protocol.  These may be defined in the future if enough
   interest is shown, and if [KIV] becomes a standardized within the
   IPsec working group.

7.2 Notification via Authentication Method Types

   The following method is used to negotiate the use of XAUTH via the
   SA payload.  New authentication methods are defined which allow the
   edge device to choose an authentication method which mandates XAUTH.
   This allows the edge device to notify the remote device that an
   XAUTH exchange will follow the phase 1 exchange.  Edge devices which
   conform to this document MUST support this method.


   The following values relate to the ISAKMP authentication method
   attribute used in proposals.  They optionally allow an XAUTH
   implementation to propose use of extended authentication after the
   initial phase 1 authentication.  Values are taken from the private
   use range defined in [IKE] and should be used among mutually
   consenting parties.  To ensure interoperability and avoid
   collisions, a Vendor ID is provided in the "Vendor ID" section of
   this document.

    Method                                            Value
   ------------------------------                     -----
    XAUTHInitPreShared                                65001
    XAUTHRespPreShared                                65002
    XAUTHInitDSS                                      65003
    XAUTHRespDSS                                      65004
    XAUTHInitRSA                                      65005
    XAUTHRespRSA                                      65006
    XAUTHInitRSAEncryption                            65007
    XAUTHRespRSAEncryption                            65008
    XAUTHInitRSARevisedEncryption                     65009
    XAUTHRespRSARevisedEncryption                     65010


   An Extended Authentication proposal has two characteristics.

   The first is the direction of the authentication.  Each type
   identifies whether the Initiator or the Responder is the device
   which should be authenticated using XAUTH.  For example
   XAUTHInitPreShared is a type which demands that the Initiator be
   authenticated.

   Note that an edge device would typically initiate with one of the
   following:

Beaulieu, Pereira                                                   12

       Extended Authentication with ISAKMP/Oakley October 2001


   o XAUTHRespPreShared
   o XAUTHRespDSS
   o XAUTHRespRSA
   o XAUTHRespRSAEncryption
   o XAUTHRespRSARevisedEncryption

   and would typically only accept proposals with the following
   authentication methods:
   o XAUTHInitPreShared
   o XAUTHInitDSS
   o XAUTHInitRSA
   o XAUTHInitRSAEncryption
   o XAUTHInitRSARevisedEncryption

   The second characteristic is the IKE Authentication method to be
   used.  The following table illustrates which keywords in the methods
   described above relate to which Authentication Methods described in
   [IKE] Appendix A.



   "PreShared"            -> pre-shared key
   "DSS"                  -> DSS signatures
   "RSA"                  -> RSA signatures
   "RSAEncryption"        -> Encryption with RSA
   "RSARevisedEncryption" -> Revised encryption with RSA


8. Other Scenarios for Extended Authentication

   Although this document described a scenario where an IPsec host (eg.
   mobile user) was being authenticated by an edge device (eg.
   firewall/gateway), the methods described can also be used for edge
   device to edge device authentication as well as IPsec host to IPsec
   host authentication.

9. Extensibility

   Although this protocol was initially developed for the corporate
   "Road Warrior" with a dynamic IP address to connect to a corporate
   Net, there may be certain applications where static IP addresses are
   used by the "Road Warrior" or where this protocol is used in a non
   remote-user environment where the IP address is static.  There are
   Security Considerations for certain applications of this protocol in
   certain deployment scenarios.  Please consult the "Security
   Considerations" section below for more detail.

   [IKE] defines many different ways to authenticate a user and
   generate keying material.  There are two basic phase 1 modes
   defined: Main Mode and Aggressive Mode.  There are also at least 5
   different authentication schemes which can be used with each mode.




Beaulieu, Pereira                                                   13

       Extended Authentication with ISAKMP/Oakley October 2001


   New authentication schemes are being developed and surely more will
   be standardized in the future.  Similarly new phase 1 modes are
   being proposed to address weaknesses or missing functionality in
   Main Mode and/or Aggressive mode.

   It is for this reason that XAUTH was designed to be fully
   extensible.  Since XAUTH extends the phase 1 authentication provided
   by [IKE], it is an important design goal that a legacy user
   authentication scheme in IPsec be able to use the strengths of
   current and future authentication and key generation schemes.

   XAUTH accomplishes this by working with all modes which allow the
   negotiation of a phase 1 authentication method in ISAKMP.  Any new
   authentication methods defined in the future which are not addressed
   by this document need simply to take values from the "consenting
   parties" ranges of [IKE].  Such an example would be the introduction
   of Encryption with El-Gamal and Revised Encryption with El-Gamal,
   and [HYBRID].  Furthermore, any new modes defined such as Base Mode,
   will automatically be able to use the functionality of XAUTH as no
   new numbers are needed.

   Finally, any new or forgotten Legacy User Authentication Schemes
   which are not part of XAUTH can be easily incorporated by taking
   numbers from the "consenting parties" ranges of XAUTH, or by
   requesting reserved numbers from IANA.



10. Security Considerations

   Care should be taken when sending sensitive information over public
   networks such as the Internet.  A user's password should never be
   sent in the clear and when sent encrypted, the destination MUST have
   been previously authenticated.  The use of ISAKMP-Config [IKECFG]
   addresses these issues.

   The protocol described in this memo strictly extends the
   authentication methods described in [IKE].  It does not in any way
   affect the authenticated nature of the phase 1 security association.
   In fact, this protocol heavily relies on the authenticated nature of
   the phase 1 SA.  Without complete phase 1 authentication, this
   protocol does not provide protection against man-in-the-middle
   attacks.  Therefore it MUST NOT be used without normal phase 1
   authentication.  This protocol was designed to be extensible, and
   can be used in many possible combinations of phase 1 Modes and
   authentication methods.  However, certain combinations of scenarios
   could lead to weaker than desired security, and are therefore
   discouraged.

   When using XAUTH with Pre-Shared keys, where the peer's IP address
   is dynamic, Main Mode SHOULD NOT be used, and is     STRONGLY
   DISCOURAGED. In this particular scenario, the phase 1 authentication
   becomes suspect as the administrator has little choice but to use

Beaulieu, Pereira                                                   14

       Extended Authentication with ISAKMP/Oakley October 2001


   one single Shared-Key for all users, and group-shared keys are
   susceptible to "social engineering attacks".

   However, the choice of implementation of this functionality is left
   up to the implementers of this protocol.  There may be some
   applications where this functionality is desired.  Some examples
   are: proof of concept deployments and small deployments where the
   proper management of a group shared-key is less difficult.

   If at some point restrictions are introduced in one of the IPsec
   Standard RFC documents which prohibit the use of group pre-shared
   keys, then this protocol will, by default, conform, and these
   Security Considerations will no longer be of concern.




11. References


   [1]  Bradner, S., "The Internet Standards Process -- Revision 3",
        BCP 9, RFC 2026, October 1996.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997


   [CHAP]  W. Simpson, "PPP Challenge Handshake Authentication Protocol
           (CHAP)", RFC1994

   [DIAMETER]  P. Calhoun, A. Rubens, "DIAMETER - Base Protocol",
               draft-calhoun-diameter-02.txt

   [HYBRID]  M. Litvin, R. Shamir, T. Zegman, "A Hybrid Authentication
             Mode for IKE", draft-ietf-ipsec-isakmp-hybrid-auth-05

   [IKE]  D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
          RFC2409

   [IKECFG]  D. Dukes, R. Pereira, "The ISAKMP Configuration Method",
             draft-dukes-ike-mode-cfg-01.txt

   [KIV]  Kivinen, T., "Fixing IKE Phase 1 & 2 Authentication HASHs",
          "draft-ietf-ipsec-ike-hash-revised-01.txt", work in progress.

   [OTP]  N. Haller, C. Metz, P. Nesser, M. Straw, "A One-Time Password
          System", RFC2289

   [OTPEXT]  C. Metz, "OTP Extended Responses", RFC 2243

   [RADIUS]  C. Rigney, A. Rubens, W. Simpson, S. Willens,  "Remote
             Authentication Dial In User Service (RADIUS)", RFC2138


Beaulieu, Pereira                                                   15

       Extended Authentication with ISAKMP/Oakley October 2001


   [SKEY]  N. Haller,   "The S/KEY One-Time Password System", RFC1760

   [TACACS]  C. Finseth, "An Access Control Protocol, Sometimes Called
             TACACS", RFC1492

   [TACACS+]  D. Carrel, L. Grant, "The TACACS+ Protocol Version 1.77",
              draft-grant-tacacs-01.txt


12.     Acknowledgments

   The authors would like to thank Tamir Zegmen, Moshe Litvin, Dan
   Harkins and all those from the IPsec community who have helped
   improve the XAUTH protocol.  We would also like to thank Tim
   Jenkins, Ajai Puri, Laurie Shields, Andrew Krywaniuk, Gabriela
   Dinescu, Paul Kierstead and Scott Fanning for their continued
   support, and many sanity checks along the way.


13. Author's Addresses

   Stephane Beaulieu
   <[e-mail]>
   Cisco Systems Co.
   [phone]

   Roy Pereira
   <[e-mail]>
   Cisco Systems
   [phone]


14. Expiration

    This draft expires April, 2002


Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it