S. Beaulieu Internet Draft R. Pereira Document: <draft-beaulieu-ike-xauth-02.txt> Cisco Systems Expires April 2002 October 2001 Extended Authentication within IKE (XAUTH) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract [IKE] allows a device to set up a secure session by using a bidirectional authentication method using either pre-shared keys or digital certificates. However [IKE] does not provide a method to leverage legacy authentication methods which are widely deployed today. This document describes a method for using existing unidirectional authentication mechanisms such as RADIUS, SecurID, and OTP within IPsec's ISAKMP protocol. The purpose of this draft is not to replace or enhance the existing authentication mechanisms described in [IKE], but rather to allow them to be extended using legacy authentication mechanisms. This protocol is designed in such a way that extended authentication may be accomplished using any mode of operation for phase 1 (i.e. Main Mode or Aggressive Mode) as well as any authentication method supported by [IKE]. This protocol may also be easily extended to support new modes or authentication methods. This protocol does however require that the phase 1 authentication method be fully secure. Beaulieu, Pereira 1 Extended Authentication with ISAKMP/Oakley October 2001 The authors currently intend this document to be published as an Informational RFC, not a standards-track document, so that the many IPsec implementations that have implemented to earlier drafts of this protocol can have a single stable reference. Comments regarding this draft should be sent to ietf-xauth@vpnc.org or to the authors. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. Introduction The following technique allows IPsec's ISAKMP/Oakley [IKE] protocol to support extended authentication mechanisms like two-factor authentication, challenge/response and other remote access unidirectional authentication methods. These authentication mechanisms have a large deployment in remote access applications and many IT departments have requirements for these unidirectional authentication mechanisms. This draft defines packet formats for a protocol which allows you to carry legacy authentication information from one peer to another. It does so by extending the [IKECFG] protocol. This protocol requires a sufficient level of security from the phase 1 SA authentication. This protocol may be used in conjunction with a multitude of combinations of modes (i.e. Main Mode, Aggressive Mode, etc) and authentication methods (i.e. Pre-Shared keys, RSA Signatures, DSS Signatures, etc). This protocol has also been designed to work with any new modes and authentication methods. This draft also specifies how to accomplish legacy authentication when used with the existing modes and authentication methods defined in IKE (the assumption here being that they offer "sufficient" level of security to protect the XAUTH exchange). This is accomplished by extending the [IKE] protocol. The document has been published as informational as the IPSRA working group will not accept any protocol which extends ISAKMP or IKE. Furthermore, the IPsec working group refuses to accept any protocols that deal with remote access. At the time of the writing of this draft, the IPSRA working group has still not defined a protocol to solve the issue of legacy Beaulieu, Pereira 2 Extended Authentication with ISAKMP/Oakley October 2001 authentication. XAUTH has been in existance for several years, and has successfully proven interoperability. Several vendors have implemented and deployed the protocol. Several vendors wish to implement the protocol but have had problems finding the protocol specification. For this reason, the draft is being republished as informational to give new vendors an opportunity to interoperate with the many existing vendors who implement this protocol today. 3.1. Changes since last revision. The last revision of this document was published as "draft-beaulieu- ike-xauth-01.txt" o clarified text regarding CHALLENGE attribute o clarified text regarding NEXT-PIN attribute 3.2. Extended Authentication Two-factor authentication and challenge/response schemes like SDI's SecurID and RADIUS are forms of authentication that allow a gateway, firewall, or network access server to offload the user administration and authentication to a central management server. IPsec's ISAKMP/Oakley protocol supports certificates (RSA & DSS), shared-secret, and Kerberos as authentication methods, but since the authentication methods described within this document are only unidirectional authentication methods (client to a gateway/firewall), they cannot be used by themselves, but must be used in conjunction with the other standard ISAKMP authentication methods. The technique described within this document utilizes ISAKMP to transfer the user's authentication information (name, password) to the gateway/firewall (edge device) in a secured ISAKMP message. The edge device would then use the appropriate protocol (RADIUS, SecurID, OTP) to authenticate the user. This allows the authentication server to be within the private network that the edge device is protecting. 3.3. Reader Prerequisites It is assumed that the reader is familiar with the terms and concepts described in the "Security Architecture for the Internet Protocol" [ArchSec] and "IP Security Document Roadmap" [Thayer97] documents. Readers are advised to be familiar with both [IKE] and [ISAKMP] as well as [IKECFG] since this document is an extension to that document. Beaulieu, Pereira 3 Extended Authentication with ISAKMP/Oakley October 2001 4. Vendor ID XAUTH currently uses attribute numbers from the private ranges of both [IKE] and [IKECFG]. In order to ensure interoperability with future and past implementations of XAUTH a Vendor ID has been added. The Vendor ID payload is sent during the phase 1 exchange as per [ISAKMP]. The vendor id payload SHOULD be authenticated whenever possible. Two IKE implementations which support the [KIV] document will be capable of doing this. The Vendor ID for this revision of XAUTH is the following 8 bytes. Vendor ID = 0x09002689DFD6B712 If an implementation receives the aforementioned Vendor ID, it can assume that the peer also has implemented this protocol and therefore is a "mutually consenting party". If this document ever advances to the standard-track, then new numbers will be assigned by IANA from the appropriate number spaces of [IKE] and [IKECFG], thus eliminating the need for a Vendor ID payload. 5. Extended Authentication Method This specification allows for extended authentication by allowing an edge device to request extended authentication from an IPsec host (end-node), thus forcing the host to respond with its extended authentication credentials. The edge device will then respond with a failed or passed message. When the edge device requests extended authentication, it will specify the type of extra authentication and any parameters required for it. These parameters MAY be the attributes that it requires for authentication and they MAY be information required for the IPsec host's reply (e.g. challenge string). The Extended Authentication transaction is terminated either when the edge device starts a SET/ACK exchange which includes an XAUTH_STATUS attribute or when the remote device sends a XAUTH_STATUS attribute in a REPLY message. Please note that a remote device can not set XAUTH_STATUS to anything but FAIL. The edge device MAY request multiple different authentication transactions within one Extended Authentication transaction. This is done by having multiple REQUEST/REPLY pairs, initiated by the edge device, before the transaction is terminated as described above. Each REQUEST/REPLY pair MAY have a different value for XAUTH_TYPE. Beaulieu, Pereira 4 Extended Authentication with ISAKMP/Oakley October 2001 As with CHAP [CHAP], this protocol can also be used to periodically authenticate the user during the lifetime of a security association. If the IPsec host does not have support for the authentication method requested by the edge device, then it would send back a REPLY with the XAUTH_STATUS attribute set to FAIL, thus failing the authentication but completing the transaction. The Extended Authentication mechanism does not effect the nature of the phase 1 authentication mechanism in any way. Both peers MUST authenticate each other via the authentication methods described in [IKE] or some other authentication method in the ISAKMP framework. There are Security Considerations involved in at least one of the authentication methods in [IKE] and this is described in "Security Considerations" below. This method provides unidirectional authentication only, meaning that only one device is authenticated using both IKE authentication methods and Extended Authentication. Here are some types of extended authentication that this specification supports: 5.1 Simple Authentication Where a user name and password are required for authentication. IPsec Host Edge Device -------------- ----------------- <-- REQUEST(NAME="" PASSWORD="") REPLY(NAME="joe" PASSWORD="foobar") --> <-- SET(STATUS=OK) ACK(STATUS) --> Some authentication mechanisms hide the user password by some type of encryption mechanism. IPsec Host Edge Device -------------- ----------------- <-- REQUEST(TYPE=RADIUS-CHAP CHALLENGE="123456" NAME="" PASSWORD="") REPLY(TYPE=RADIUS-CHAP NAME="joe" PASSWORD="E4901AB7") --> <-- SET(STATUS=OK) ACK(STATUS) --> NOTE: This is a conceptual example of RADIUS-CHAP, for a more detailed example, see Appendix A. 5.2 Challenge/Response Beaulieu, Pereira 5 Extended Authentication with ISAKMP/Oakley October 2001 Where a challenge from the edge device must be incorporated with the reply. This makes each reply different. IPsec Host Edge Device -------------- ----------------- <-- REQUEST(NAME="" PASSWORD="") REPLY(NAME="joe" PASSWORD="foobar") --> <-- REQUEST(MESSAGE="Enter your password followed by your pin number" NAME="" PASSWORD="") REPLY(NAME="joe" PASSWORD="foobar0985124") --> <-- SET(STATUS=OK) ACK(STATUS) --> If, however, the edge device knows that a challenge will be required it may skip the first exchange as follows: IPsec Host Edge Device -------------- ----------------- <-- REQUEST(MESSAGE="Enter your password followed by your pin number" NAME="" PASSWORD="") REPLY(NAME="joe" PASSWORD="foobar0985124") --> <-- SET(STATUS=OK) ACK(STATUS) --> 5.3 Two-Factor Authentication This authentication method combines something the user knows (their password) and something that the user has (a token card). IPsec Host Edge Device -------------- ----------------- <-- REQUEST(NAME="" PASSWORD="" PASSCODE="") REPLY(NAME="joe" PASSWORD="foobar" PASSCODE="3412") --> <-- SET(STATUS=OK) ACK(STATUS) --> Some mechanisms allow for another optional request of the passcode. IPsec Host Edge Device -------------- ----------------- <-- REQUEST(NAME="" PASSWORD="" PASSCODE="") REPLY(NAME="joe" PASSWORD="foobar" PASSCODE="323415") --> <-- REQUEST(NAME="" PASSWORD="" PASSCODE="") REPLY(NAME="joe" PASSWORD="foobar" PASSCODE="513212") --> <-- SET(STATUS=OK) ACK(STATUS) --> 5.4 One-Time-Password Similar to the Challenge/Response method, this method allows authentication that is secure against passive attacks based on replaying captured passwords. Beaulieu, Pereira 6 Extended Authentication with ISAKMP/Oakley October 2001 IPsec Host Edge Device -------------- ----------------- <-- REQUEST(TYPE=OTP CHALLENGE, NAME="") REPLY(TYPE=OTP_CHALLENGE, NAME="joe")--> <-- REQUEST(TYPE=OTP CHALLENGE="otp-md5 499 ke1234" NAME="" PASSWORD="") REPLY(TYPE=OTP NAME="joe" PASSWORD="5bf0 75d9 959d 036f") --> <-- SET(STATUS=OK) ACK(STATUS) --> 5.5 User Previously Authenticated Some situations may occur where the edge device has already authenticated the host and no new authentication is required. This may happen when either the host or the edge device must rekey an existing phase 1 SA. It is important that this method not be used, unless the implementation can be sure that the current phase 1 SA was created with the same peer as the initial phase 1 SA, which was previously authenticated using XAUTH. There is currently no way defined to ensure that two separate phase 1 SAs actually belong to the same peer. One method suggested is to use the ID from the phase 1 negotiation (available in Main Mode and Aggressive Mode) but only if the ID is unique to the user and cannot not be forged. This concept is herein referred to as "ID-Checking". Implementation hint: o In order to accomplish ID-Checking for Phase 1 Authenticated With a Pre-Shared Key (as defined in [IKE]), the pre-shared key lookup must be based on the phase 1 ID. Please note that this method only currently works for Aggressive Mode, and may work with modes defined in the future. A static IP address could also be used for shared secret lookup, however, the binding of the user to XAUTH session would have to use the IP address instead of the ID. o In order to accomplish ID-Checking for IKE Phase 1 Authenticated With Signatures (as defined in [IKE]), the implementation must ensure that the ID provided in the phase 1 exchange matches the ID in the peer's certificate which must be signed by a trusted third party. In the situation where the peer does not require additional authentication, the following method is used. IPsec Host Edge Device ------------- ---------------- <-- SET(STATUS=OK) ACK(STATUS) --> Beaulieu, Pereira 7 Extended Authentication with ISAKMP/Oakley October 2001 5.6 Other Useful Examples More useful examples are found in Appendix A. 6 Extensions to ISAKMP-Config This protocol uses the mechanisms described in ISAKMP-Config [IKECFG] to accomplish its authentication transaction. This protocol uses Configuration Attributes from the private range of Isakmp-Config [IKECFG]. To ensure interoperability with past and future versions of Extended Authentication, a Vendor ID is provided in section 2. All ISAKMP-Config messages in an extended authentication transaction MUST contain the same ISAKMP-Config transaction identifier. The Message ID in the ISAKMP header follows the rules defined by the ISAKMP-Config protocol. This protocol can therefore be used in conjunction with any existing basic ISAKMP authentication method as defined in [IKE]. This authentication MUST be used after a phase 1 exchange has completed and before any other exchange with the exception of Info mode exchanges. If the extended authentication fails, then the phase 1 SA MUST be immediately deleted. The edge device MAY choose to retry an extended authentication request if the user failed to be authenticated, but must do so in the same ISAKMP-Config transaction, and MUST NOT send the SET message until the user is authenticated, or until the edge device wishes to stop retrying and fail the user. Extended Authentication MAY be initiated by the edge device at any time after the initial authentication exchange. For example, RADIUS servers may specify that a user only be authenticated for a certain time period. Once that time period has elapsed (minus a possible jitter), the edge device may request a new Extended Authentication exchange. If the Extended Authentication exchange fails, the edge device MUST tear down all phase 1 and phase 2 SAs associated with the user. The following are extensions to the ISAKMP-Config [IKECFG] specification to support Extended Authentication. 6.1 Message Types Type Value -------------------------- ----------------------------- ISAKMP-CFG-REQUEST ( as defined in [IKECFG] ) ISAKMP-CFG-REPLY ( as defined in [IKECFG] ) ISAKMP-CFG-SET ( as defined in [IKECFG] ) ISAKMP-CFG-ACK ( as defined in [IKECFG] ) Beaulieu, Pereira 8 Extended Authentication with ISAKMP/Oakley October 2001 ISAKMP-CFG-REQUEST - This message is sent from an edge device to an IPsec host trying to request extended authentication. Attributes that it requires sent back in the reply MUST be included with a length of zero (0). Attributes required for the authentication reply, such as a challenge string MUST be included with the proper values filled in. ISAKMP-CFG-REPLY - This message MUST contain the filled in authentication attributes that were requested by the edge device or if the proper authentication attributes can not be retrieved, then this message MUST contain the XAUTH-STATUS attribute with a value of FAIL. ISAKMP-CFG-SET - This message is sent from an edge device and is only used, within the scope of this document, to state the success of the authentication. This message MUST only include the success of failure of the authentication and MAY contain some clarification text. ISAKMP-CFG-ACK - This message is sent from the IPsec host acknowledging receipt of the authentication result. Its attributes are not relevant and MAY be skipped entirely, thus no attributes SHOULD be included. This last message in the authentication transaction is used solely as an acknowledgement of the previous message and to eliminate problems with unacknowledged messages over UDP. 6.2 Attributes Attribute Value Type --------------------- ------ --------------------- XAUTH-TYPE 16520 Basic XAUTH-USER-NAME 16521 Variable ASCII string XAUTH-USER-PASSWORD 16522 Variable ASCII string XAUTH-PASSCODE 16523 Variable ASCII string XAUTH-MESSAGE 16524 Variable ASCII string XAUTH-CHALLENGE 16525 Variable ASCII string XAUTH-DOMAIN 16526 Variable ASCII string XAUTH-STATUS 16527 Basic XAUTH-NEXT-PIN 16528 Variable ASCII string XAUTH-ANSWER 16529 Variable ASCII string NOTE: Variable ASCII strings need not be NULL-terminated, as the length field in the attribute header is sufficient to properly format the strings. XAUTH-TYPE - The type of extended authentication requested whose values are described in the next section. This is an optional attribute for the ISAKMP_CFG_REQUEST and ISAKMP_CFG_REPLY messages. If the XAUTH-TYPE is not present, then it is assumed to be Generic. The XAUTH-TYPE in a REPLY MUST be identical to the XAUTH-TYPE in the REQUEST. If the XAUTH-TYPE was not present in the REQUEST, then it MUST NOT be present in the REPLY. However, an XAUTH transaction MAY Beaulieu, Pereira 9 Extended Authentication with ISAKMP/Oakley October 2001 have multiple REQUEST/REPLY pairs with different XAUTH-TYPE values in each pair. XAUTH-USER-NAME - The user name MAY be any unique identifier of the user such as a login name, an email address, or a X.500 Distinguished Name. XAUTH-USER-PASSWORD - The user's password. XAUTH-PASSCODE - A token card's passcode. XAUTH-MESSAGE - A textual message from an edge device to an IPsec host. The message may contain a textual challenge or instruction. An example of this would be "Enter your password followed by your pin number". The message may also contain a reason why authentication failed or succeeded. This message SHOULD be displayed to the user. XAUTH-CHALLENGE - A challenge string sent from the edge device to the IPsec host for it to include in its calculation of a password. This attribute SHOULD only be sent in an ISAKMP-CFG-REQUEST message. Typically, the XAUTH-TYPE attribute dictates how the receiving device should handle the challenge. For example, RADIUS-CHAP uses the challenge to hide the password. The XAUTH-CHALLENGE attribute MUST NOT be used when XAUTH-TYPE is set to generic. XAUTH-DOMAIN - The domain to be authenticated in. This value will have different meaning depending on the authentication type. XAUTH-STATUS - A variable that is used to denote authentication success (OK=1) or failure (FAIL=0). This attribute MUST be sent in the ISAKMP-CFG-SET message, in which case it may be set to either OK or FAIL, and MAY be sent in a REPLY message by a remote peer, in which case it MUST be set to FAIL. XAUTH-NEXT-PIN - A variable which is used when the edge device is requesting that the user choose a new pin number. This attribute MUST NOT be used in conjunction with any attributes other than XAUTH-MESSAGE and / or XAUTH-TYPE. XAUTH-ANSWER - A variable length ASCII string used to send input to the edge device. An edge device MAY include this attribute in a REQUEST message in order to prompt an answer from the user, though it MUST be accompanied by an XAUTH-MESSAGE attribute. This attribute MUST NOT be used in conjunction with any attributes other than XAUTH-TYPE or XAUTH-MESSAGE. 6.3 Authentication Types Value Authentication Required ----- --------------------------------- Beaulieu, Pereira 10 Extended Authentication with ISAKMP/Oakley October 2001 0 Generic 1 RADIUS-CHAP 2 OTP 3 S/KEY 4-32767 Reserved for future use 32768-65535 Reserved for private use Generic - A catch-all type that allows for future extensibility and a generic mechanism to request authentication information. This method allows for any type of extended authentication which does not require specific processing, and should be used whenever possible. This is the default setting if no XAUTH_TYPE is present. RADIUS-CHAP - RADIUS-CHAP is one method of authentication defined in [RADIUS] which uses a challenge to hide the password. In order to use the CHAP functionality defined in [RADIUS], the XAUTH_TYPE MUST be set to RADIUS-CHAP. For all other methods defined in [RADIUS] (i.e. PAP), the XAUTH_TYPE MUST be set to Generic. OTP - One-Time-Passwords as defined in [OTP] uses a challenge string to request a certain generated password. The request SHOULD contain a user name, password and a challenge string while the reply MUST contain the user name and the generated password. The challenge string is formatted as defined in [OTPEXT]. S/KEY - This one-time-password scheme defined in [SKEY] was the precursor to OTP, thus the same rules applies. 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 <stephane@cisco.com> Cisco Systems Co. +1 (613) 721-3678 Roy Pereira <royp@cisco.com> Cisco Systems +1 (408) 526-6793 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 or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Beaulieu, Pereira 16 Extended Authentication with ISAKMP/Oakley October 2001 Beaulieu, Pereira 17 Extended Authentication with ISAKMP/Oakley October 2001 Appendix A This appendix gives more useful examples of Extended Authentication. SDI through RADIUS ================== The following 3 examples show examples of SDI running through RADIUS. Since the edge device does not necessarily know that we are indeed doing SDI, the edge device will typically send everything in terms of Username and Password. This of course results in the user being prompted with a password dialog when it isn't really a password which is required. This tends to be a little confusing, but it is really a limitation of RADIUS. NOTE: The edge device may choose to try and detect these situations and send better suited XAUTH attributes (such as XAUTH ANSWER or XAUTH NEXT PIN). The Client is typically protocol agnostic and will prompt the user for whatever attributes the edge device requests. Example A-1: ============ Secure ID Next PIN mode via RADIUS (Scenario 1 - SDI generated next pin) IPsec Client IPsec Gateway ------------ ------------- <-- REQUEST(Username = '', Password = '') REPLY(Username = 'joe', Password = '1637364856') --> <-- REQUEST(Username = '', Password = '', XAUTH_MESSAGE = 'The system has assigned you a new PIN of '1234', please re-enter your username and password') REPLY(Username = 'joe', Password = '1234764456') --> <-- SET(XAUTH_STATUS = OK) ACK(XAUTH_STATUS) --> Example A-2: ============ Secure ID Next PIN mode via RADIUS (Scenario 2 - User generated next pin) IPsec Client IPsec Gateway ------------ ------------- <-- REQUEST(Username = '', Password = '') REPLY(Username = 'joe', Password = '1637364856') --> <-- REQUEST(Username = '', Password = '', XAUTH_MESSAGE = 'Enter your new PIN containing 4-6 digits') REPLY(Username = 'joe', Password = '1234') --> Beaulieu, Pereira 18 Extended Authentication with ISAKMP/Oakley October 2001 <-- REQUEST(Username = '', Password = '') REPLY(Username = 'joe', Password = '1234764456') --> <-- SET(XAUTH_STATUS = OK) ACK(XAUTH_STATUS) --> Example A-3: ============ Secure ID Next PIN mode via RADIUS (Scenario 3 - RADIUS server offers choice of generating new PIN) IPsec Client IPsec Gateway ------------ ------------- <-- REQUEST(Username = '', Password = '') REPLY(Username = 'joe', Password = '1637364856') --> <-- REQUEST(Username = '', Password = '', XAUTH_MESSAGE = 'You must start using a new PIN. Would you like to generate your own PIN (y/n)?) REPLY(Username = 'joe', Password = 'y') --> <-- REQUEST(Username = '', Password = '', XAUTH MESSAGE = 'Enter your new PIN containing 4-6 digits') REPLY(Username = 'joe', Password = '1234') --> <-- REQUEST(Username = '', Password = '') REPLY(Username = 'joe', Password = '1234764456' <-- SET(XAUTH_STATUS = OK) ACK(XAUTH_STATUS) --> Native SDI ========== When doing native SDI between the edge device and the SDI server, the edge device has more information about what type of information is required from the user. The edge device can therefore use more intuitive attributes in certain situations as compared with the RADIUS examples above. Example A-4: ============ Secure ID Next PIN mode(Scenario 1 - SDI generated next pin) IPsec Client IPsec Gateway ------------ ------------- <-- REQUEST(Username = '', Passcode = '') REPLY(Username = 'joe', Passcode = '1637364856') --> <-- REQUEST(Username = '', Passcode = '', XAUTH_MESSAGE = 'The system has assigned you a Beaulieu, Pereira 19 Extended Authentication with ISAKMP/Oakley October 2001 new PIN of '1234', please re-enter your username and passcode') REPLY(Username = 'joe', Passcode = '1234764456') --> <-- SET(STATUS = OK) ACK(STATUS) --> Example A-5: ============ Secure ID Next PIN mode(Scenario 2 - User generated next pin) IPsec Client IPsec Gateway ------------ ------------- <-- REQUEST(Username = '', Passcode = '') REPLY(Username = 'joe', Passcode = '1637364856') --> <-- REQUEST(NEXT PIN = '', XAUTH_MESSAGE = 'Enter your new PIN containing 4-6 digits') REPLY(NEXT_PIN = '1234') --> <-- REQUEST(Username = '', Passcode = '') REPLY(Username = 'joe', Passcode = '1234764456') --> <-- SET(STATUS = OK) ACK(STATUS) --> Example A-6: ============ Secure ID Next PIN mode(Scenario 3 - SDI server offers choice of generating new PIN) IPsec Client IPsec Gateway ------------ ------------- <-- REQUEST(Username = '', Passcode = '') REPLY(Username = 'joe', Passcode = '1637364856') --> <-- REQUEST(ANSWER = '', XAUTH_MESSAGE = 'You must start using a new PIN. Would you like to generate your own PIN (y/n)?) REPLY(ANSWER = 'y') --> <-- REQUEST(NEXT_PIN = '', XAUTH MESSAGE = 'Enter your new PIN containing 4-6 digits') REPLY(NEXT PIN = '1234') --> <-- REQUEST(Username = '', Passcode = '') REPLY(Username = 'joe', Passcode = '1234764456' <-- SET(STATUS = OK) ACK(STATUS) --> Example A-7: ============ SDI next cardcode IPsec Client IPsec Gateway Beaulieu, Pereira 20 Extended Authentication with ISAKMP/Oakley October 2001 ------------ ------------- <-- REQUEST(Username = '', Passcode = '') REPLY(Username = 'joe', Passcode = '1637364856') --> <-- REQUEST(Username = '', Passcode = '', XAUTH_MESSAGE = 'Your token is out of sync with the server, please enter a new passcode.') REPLY(Username = 'joe', Passcode = '1637904324') --> <-- SET(STATUS = OK) ACK(STATUS) --> RADIUS Chap Challenge ===================== Example A-8: ============ IPsec Client IPsec Gateway ------------ ------------- <-- REQUEST(TYPE = RADIUS-CHAP, Username = '', Password = '', Challenge = 0x01020304050607080910111213141516) REPLY(TYPE = RADIUS-CHAP, Username = 'joe', Password = '0xaa11121314151617181920212223242526') --> <-- SET(STATUS = OK) ACK(STATUS) --> where the Challenge in the REQUEST is the random number generated by the edge device, and the Password in the reply contains the ID used to calculate the hash 'aa' concatenated with the hash of the (ID+secret+challenge). Beaulieu, Pereira 21