Internet Engineering Task Force R. Pereira IP Security Working Group TimeStep Corporation Internet Draft Expires in six months November 6, 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 made 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), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document describes a method for using existing unidirectional authentication mechanisms such as RADIUS, SecurID, and OTP within IPSec's ISAKMP protocol. R. Pereira [Page 1] Internet Draft Nov-98 Table of Contents 1. Introduction...................................................2 1.1 Extended Authentication.....................................2 1.2 Reader Prerequisites........................................3 1.3 Specification of Requirements...............................3 2. Extended Authentication Method.................................3 2.1 Simple Authentication.......................................4 2.2 Challenge/Response..........................................4 2.3 Two-Factor Authentication...................................5 2.4 One-Time-Password...........................................5 3. Extensions to ISAKMP-Config....................................5 3.1 Message Types...............................................6 3.2 Attributes..................................................7 3.3 Authentication Types........................................8 4. Other Scenarios for Extended Authentication....................9 5. Security Considerations.......................................10 6. References....................................................10 7. Editor's Address..............................................11 8. Full Copyright Statement......................................11 1. 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. 1.1 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 R. Pereira [Page 2] Internet Draft Nov-98 the gateway/firewall (edge device) in a secured ISAKMP message. The edge device would then use either 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. 1.2 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. 1.3 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. 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 last message is simply a reply back from the edge device denoting failure or success. The reply MAY have some textual information describing the reason for the failure or success. The edge device MAY also request another authentication, like SecurID's next PIN request, where the user is required to enter the next passcode to further verify itself. As with CHAP [CHAP], this protocol can also be used to periodically authenticate the user during the lifetime of a security association. R. Pereira [Page 3] Internet Draft Nov-98 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 empty attributes, thus failing the authentication but completing the transaction. The last exchange (SET/ACK) MUST also be completed. Here are some types of extended authentication that this specification supports; 2.1 Simple Authentication Where a user name and password are required for authentication. IPSec Host Edge Device -------------- ----------------- <-- REQUEST(TYPE=RADIUS NAME="" PASSWORD="") REPLY(TYPE=RADIUS NAME="joe" PASSWORD="foobar") --> <-- SET(STATUS=OK) ACK() --> 2.2 Challenge/Response Where a challenge from the edge device must be incorporated with the reply. This makes each reply different. IPSec Host Edge Device -------------- ----------------- <-- REQUEST(TYPE=RADIUS NAME="" PASSWORD="") REPLY(TYPE=RADIUS NAME="joe" PASSWORD="foobar") --> <-- REQUEST(TYPE=RADIUS CHALLENGE="123456" NAME="" PASSWORD="" REQ_NUM=2) REPLY(TYPE=RADIUS NAME="joe" PASSWORD="0985124") --> <-- SET(STATUS=OK) ACK() --> 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(TYPE=RADIUS CHALLENGE="123456" NAME="" PASSWORD="") REPLY(TYPE=RADIUS NAME="joe" PASSWORD="0985124") --> <-- SET(STATUS=OK) ACK() --> R. Pereira [Page 4] Internet Draft Nov-98 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 -------------- ----------------- <-- REQUEST(TYPE=AXENT NAME="" PASSWORD="" PASSCODE="") REPLY(TYPE=AXENT NAME="joe" PASSWORD="foobar" PASSCODE="3412") --> <-- SET(STATUS=OK) ACK() --> Some mechanisms allow for another optional request of the passcode. IPSec Host Edge Device -------------- ----------------- <-- REQUEST(TYPE=SECURID NAME="" PASSWORD="" PASSCODE="") REPLY(TYPE=SECURID NAME="joe" PASSWORD="foobar" PASSCODE="323415") --> <-- REQUEST(TYPE=SECURID NAME="" PASSWORD="" PASSCODE="" REQ_NUM=2) REPLY(TYPE=SECURID NAME="joe" PASSWORD="foobar" PASSCODE="513212") --> <-- SET(STATUS=OK) ACK() --> 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 -------------- ----------------- <-- REQUEST(TYPE=OTP CHALLENGE="otp-md5 499 ke1234" NAME="" PASSWORD="") REPLY(TYPE=OTP NAME="joe" PASSWORD="5bf0 75d9 959d 036f") --> <-- SET(STATUS=OK) ACK() --> 3. Extensions to ISAKMP-Config This protocol uses the mechanisms described in ISAKMP-Config [IKECFG] to accomplish its authentication transaction. R. Pereira [Page 5] Internet Draft Nov-98 All ISAKMP-Config messages in an extended authentication transaction MUST contain the same ISAKMP-Config message ID. This protocol can therefore be used in conjunction with any existing basic ISAKMP authentication method as defined in [IKE]. If mutual authentication is not required, then the phase 1 negotiation SHOULD use an authentication method of shared-secret and have that shared-secret be null. This, is however, NOT suggested since the edge-device is NOT authenticated. This authentication MUST be used after a phase 1 exchange has completed and before a phase 2 exchange. The Transaction exchange is therefore attached (appended) to the phase 1 exchanges (MainMode, AggressiveMode). If the extended authentication fails, then the phase 1 SA MUST be deleted. The following are extensions and/or clarifications to the ISAKMP- Config [IKECFG] specification to support Extended Authentication. 3.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] ) 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 filled in authentication attributes that were requested by the edge device. o 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. o ISAKMP_CFG_ACK - This message is sent from the IPSec host acknowledging receipt of the authentication result. Its R. Pereira [Page 6] Internet Draft Nov-98 attributes are not relevant and MAY be skipped entirely, thus not 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. 3.2 Attributes Attribute Value Type --------------------- ------ --------------------- XAUTH_TYPE 13 Basic XAUTH_USER_NAME 14 Variable ASCII string XAUTH_USER_PASSWORD 15 Variable ASCII string XAUTH_PASSCODE 16 Variable ASCII string XAUTH_MESSAGE 17 Variable ASCII string XAUTH_CHALLENGE 18 Variable ASCII string XAUTH_DOMAIN 19 Variable ASCII string XAUTH_STATUS 20 Basic XAUTH_REQ_NUMBER 21 Basic 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. 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 MAY 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. This attribute SHOULD only be sent in an ISAKMP_CFG_REQUEST message. o XAUTH_DOMAIN - The domain to be authenticated in. This value will have different meaning depending on the authentication type. R. Pereira [Page 7] Internet Draft Nov-98 o XAUTH_STATUS - A variable that is used to denote authentication success (OK=1) or failure (FAIL=0). This is a mandatory attribute for the ISAKMP_CFG_SET message. o XAUTH_REQ_NUMBER - The number of times that a request has been made, including the current request. The default value is one (1) and thus does not have to be included. This attribute is used to denote that an authentication transaction has had to have another authentication request. The IPSec host should notice that this is not a retransmit of the original request, but that this is yet another request. This attribute MUST only be included in the ISAKMP_CFG_REQUEST message. 3.3 Authentication Types Value Authentication Required ----- --------------------------------- 0 Generic 1 RADIUS 2 OTP 3 NT Domain 4 Unix Login 5 SDI SecurID 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) 14 DIAMETER 15 LDAP 16-32767 Reserved for future use 32768-65535 Reserved for private use 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 [RADIUS] server requires at least 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. R. Pereira [Page 8] Internet Draft Nov-98 o 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]. 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 SecurID, 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, password and the token card's passcode. This authentication type MIGHT also include a challenge string in the request. o TACACS - Defined in [TACACS], this authentication protocol was the precursor to RADIUS, thus the same rules apply. o TACACS+ - Defined in [TACACS+], 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 [SKEY] 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. o DIAMETER - The next generation RADIUS protocol that is defined in [DIAMETER]. The same rules as RADIUS apply. 4. 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. R. Pereira [Page 9] Internet Draft Nov-98 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. 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 [IKECFG] addresses these issues. 6. References [Bradner97] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC2119 [CHAP] W. Simpson, "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC1994 [DIAMETER] P. Calhoun, A. Rubens, "DIAMETER - Base Protocol", draft-calhoun-diameter-02.txt [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", draft-ietf-ipsec-isakmp-oakley-07 [IKECFG] R. Pereira, "The ISAKMP Configuration Method", draft-ietf-ipsec-isakmp-cfg-03 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC2138 [OTP] N. Haller, C. Metz, "A One-Time Password System", RFC1938 [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 [OTPEXT] C. Metz, "OTP Extended Responses", RFC 2243 R. Pereira [Page 10] Internet Draft Nov-98 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 rgm@icsa.net Internal Computer Security Association Theodore Y. Ts'o tytso@MIT.EDU Massachusetts Institute of Technology 8. Full Copyright Statement Copyright (C) The Internet Society (1998). 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 implementation 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 languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. R. Pereira [Page 11]