Internet Engineering Task Force R. Pereira IP Security Working Group TimeStep Corporation Internet Draft Expires in six months February 11, 1998 Extended Authentication Within ISAKMP/Oakley Status of this Memo This document is a submission to the IETF Internet Protocol Security (IPSECond) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@tis.com) or to the editor. This document is an Internet-Draft. 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 draft documents are valid for a maximum of six months and may be updated, replaced, or obsolete 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This document describes a method for using existing unidirectional authentication mechanisms such as RADIUS, SecureID, and OTP with ISAKMP. R. Pereira [Page 1] Internet Draft Feb-98 Table of Contents 1. Introduction...................................................2 1.1 Extended Authentication.....................................2 1.2 Specification of Requirements...............................3 2. Authentication Types...........................................3 2.1 Simple Authentication.......................................3 2.2 Challenge/Response..........................................3 2.3 Two-Factor Authentication...................................3 2.4 One-Time-Password...........................................4 3. Interaction with ISAKMP........................................4 3.1 Exchanges...................................................5 4. Extensions to ISAKMP-Config....................................5 4.1 NOTIFY Types................................................6 4.2 Attributes..................................................6 4.3 Authentication Types........................................7 5. Security Considerations........................................8 6. References.....................................................9 7. Editor's Address...............................................9 1. Introduction The following technique allows IPSec's ISAKMP/Oakley 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. 1.1 Extended Authentication Two-factor authentication and challenge/response schemes like SDI's SecureID 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 authentication methods. The technique described within this document utilizes ISAKMP to transfer the user's authentication information (name, password) to the gateway/firewall in a secured ISAKMP message. The gateway/firewall would then use either the appropriate protocol R. Pereira [Page 2] Internet Draft Feb-98 (RADIUS, SecureID, OTP) to authenticate the user. This allows the authentication server to be within the private network that the gateway/firewall is protecting. 1.2 Specification of Requirements The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [Bradner97]. 2. Authentication Types 2.1 Simple Authentication Where a user name and password are required for authentication. IPSec Host Edge Device -------------- ----------------- <-- CFG-REQUEST(RADIUS NAME PASSWORD) CFG-REPLY(RADIUS NAME PASSWORD) --> <-- CFG-AUTH-OK() 2.2 Challenge/Response Where a challenge from the gateway/firewall must be incorporated with the reply. This makes each reply different. IPSec Host Edge Device -------------- ----------------- <-- CFG-REQUEST(RADIUS CHALLENGE NAME PASSWORD) CFG-REPLY(RADIUS NAME PASSWORD) --> <-- CFG-AUTH-OK() 2.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 -------------- ----------------- <-- CFG-REQUEST(SECUREID NAME PASSWORD PASSCODE) CFG-REPLY(SECUREID NAME PASSWORD PASSCODE) --> <-- CFG-AUTH-OK() Some mechanisms allow for another request of the passcode; R. Pereira [Page 3] Internet Draft Feb-98 IPSec Host Edge Device -------------- ----------------- <-- CFG-REQUEST(SECUREID NAME PASSWORD PASSCODE) CFG-REPLY(SECUREID NAME PASSWORD PASSCODE) --> <-- CFG-REQUEST(SECUREID NAME PASSWORD PASSCODE) CFG-REPLY(SECUREID NAME PASSWORD PASSCODE) --> <-- CFG-AUTH-OK() 2.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. IPSec Host Edge Device -------------- ----------------- <-- CFG-REQUEST(OTP CHALLENGE NAME PASSWORD) CFG-REPLY(TOP NAME PASSWORD) --> <-- CFG-AUTH-OK() 3. Interaction with ISAKMP This protocol utilizes the mechanisms described in ISAKMP-Config [Pereira97] to accomplish its request/reply transaction through ISAKMP. An edge device (gateway or firewall) may request extended authentication from a 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. Example: IPSec Host Edge Device -------------- ----------------- <-- CFG-REQUEST(SECUREID NAME PASSWORD PASSCODE) CFG-REPLY(SECUREID NAME PASSWORD PASSCODE) --> <-- CFG-AUTH-FAILED() 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 or they MAY be information required for the IPSec host's reply (eg. challenge string). The last message, is simply a reply back from the gateway/firewall denoting failure or passing. The replay MAY have some textual information describing the reason for the failure or success. The R. Pereira [Page 4] Internet Draft Feb-98 gateway/firewall may also request another authentication, like Secure ID's next PIN request, where the user is required to enter the next passcode to further verify the user. 3.1 Exchanges ISAKMP-Config sets forth some guidelines on where these exchanges may take place. This document will add on to those guidelines in relation to extended authentication exchanges. As described in the last section, the edge device requests extended authentication. This MUST be supported at least in these three places: [1] ISAKMP Main Mode in the responder's second message - if the client's ID is not relevant to decide whether or not to request extended authentication. [2] ISAKMP Main Mode in the responder's third message - if the client's ID is relevant in deciding whether or not to request extended authentication. [3] ISAKMP Aggressive mode in the responder's first message - if identity protection is not required for ISAKMP. The main reason that only the above three places are valid are because the client's reply MUST be secured since it will carry sensitive information like passwords. In the case of Aggressive Mode, ISAKMP-Config [Pereira97] denotes that the response be sent in an encrypted InfoMode ISAKMP message after the Aggressive Mode is done and an ISAKMP SA exists between the two peers. The extended authentication exchange MAY also be used in Quick Mode, but for inter-operability's sake, the methods listed above MUST be supported. 4. Extensions to ISAKMP-Config The following are extensions to the ISAKMP-Config [Pereira97] specification to support Extended Authentication. R. Pereira [Page 5] Internet Draft Feb-98 4.1 NOTIFY Types Type Value -------------------------- ----------------------------- ISAKMP_CFG_REQUEST ( as defined in [Pereira97] ) ISAKMP_CFG_REPLY ( as defined in [Pereira97] ) ISAKMP_CFG_AUTH_OK 105 ISAKMP_CFG_AUTH_FAILED 106 o 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. o ISAKMP_CFG_REPLY - This message MUST contain the authentication attributes that were requested by the edge device filled in. o ISAKMP_CFG_AUTH_OK - This message MAY contain a textual message in the XAUTH_MESSAGE attribute. o ISAKMP_CFG_AUTH_FAILED - This message MAY contain a textual message in the XAUTH_MESSAGE attribute. 4.2 Attributes Attribute Value Type --------------------- ------ --------------------- XAUTH_TYPE 101 Basic XUATH_USER_NAME 102 Variable ASCII string XAUTH_USER_PASSWORD 103 Variable ASCII string XAUTH_PASSCODE 104 Variable ASCII string XAUTH_MESSAGE 105 Variable ASCII string XAUTH_CHALLENGE 106 Variable ASCII string XAUTH_DOMAIN 107 Variable ASCII string o XAUTH_TYPE - The type of extended authentication requested whose values are described in the next section. This is a mandatory attribute for the ISAKMP_CFG_REQUEST and ISAKMP_CFG_REPLY messages. o 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. o XAUTH_USER_PASSWORD - The user's password. R. Pereira [Page 6] Internet Draft Feb-98 o XAUTH_PASSCODE - A token card's passcode. This SHOULD only be used when the password attribute is also used. o XAUTH_MESSAGE - A textual message from an edge device to an IPSec host. This message SHOULD be displayed to the user to notify them of the reason why authentication failed or succeed. o XAUTH_CHALLENGE - A challenge string sent from the edge device to the IPSec host for it to include in its calculation of a password or passcode. This attribute SHOULD only be sent in a ISAKMP_CFG_REQUEST message. o XAUTH_DOMAIN - The domain to be authenticated in. This value will have different meaning depending on the authentication type. 4.3 Authentication Types Value Authentication Required ----- --------------------------------- 0 Generic 1 RADIUS 2 OTP 3 NT Domain 4 Unix Login 5 SDI SecureID 6 AXENT Defender 7 LeeMah InfoCard 8 ActiveCard 9 Secure Computing Enigma (DES Gold) 10 TACACS 11 TACACS+ 12 S/KEY 13 NDS (Netware Directory Services) o 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. o RADIUS - A RADIUS [Radius97] server requires a user name and a password, but since RADIUS may be proxying for another type of authentication method, both the request and the reply MAY be like any of the other extended authentication types. o OTP - One-Time-Passwords as defined in [Opt96] uses a challenge string to request a certain generated password. The request SHOULD contain a user name, password and a challenge string R. Pereira [Page 7] Internet Draft Feb-98 while the reply MUST contain the user name and the generated password. The challenge string is formatted as defined in [Metz97]. o NT Domain - This authentication type provides for user authentication by login into a Windows NT(r) domain. The request SHOULD contain empty user name, password and domain attributes. The reply MUST contain all of these attributes filled in. The domain attribute is optional for both messages, and SHOULD NOT be included in the reply if it isn’t included in the request. o Unix Login - Much like the NT Domain authentication type, but this will authenticate the user to a Unix(r) workstation. o SDI SecureID, AXENT Defender, LeeMah InfoCard, ActiceCard, Enigma/DES Gold - All of these (and others) use smart cards to generate a 'passcode' to authenticate the user. This passcode combined with the user's password provides stronger authentication than just passwords. The response MUST include the user name, user password and the token card's passcode. This authentication type MIGHT also include a challenge string in the request. o TACACS - Defined in [Tacacs93], this authentication protocol was the precursor to RADIUS, thus the same rules apply. o TACACS+ - Defined in [Tacacs+97], this authentication protocol is an updated version of the original TACACS protocol, thus the same rules apply. o S/KEY - This one-time-password scheme defined in [Skey95] was the precursor to OTP, thus the same rules apply. o NDS - Much like the NT Domain authentication type, but this will authenticate the user to a NetWare Directory server. 5. 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 [Pereira97] plus further guidelines outlined in this document address these issues. R. Pereira [Page 8] Internet Draft Feb-98 6. References [Bradner97] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC2119 [Finseth93] C. Finseth, "An Access Control Protocol, Sometimes Called TACACS", RFC1492 [Radius97] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC2138 [Pereira97] R. Pereira, "The ISAKMP Configuration Method", draft-ietf-ipsec-isakmp-cfg-02 [Opt96] N. Haller, C. Metz, "A One-Time Password System", RFC1938 [Skey95] N. Haller, "The S/KEY One-Time Password System", RFC1760 [Tacacs93] C. Finseth, "An Access Control Protocol, Sometimes Called TACACS", RFC1492 [Tacacs+97] D. Carrel, L. Grant, "The TACACS+ Protocol Version 1.77", draft-grant-tacacs-01.txt [Metz97] C. Metz, "OTP Extended Responses", RFC 2243 7. Editor's Address Roy Pereira TimeStep Corporation +1 (613) 599-3610 x 4808 The IPSec working group can be contacted via the IPSec working group's mailing list (ipsec@tis.com) or through its chairs: Robert Moskowitz rgm3@icsa.net ICSA Theodore Y. Ts’o tytso@MIT.EDU Massachusetts Institute of Technology R. Pereira [Page 9]