Internet Engineering Task Force R. Pereira IP Security Working Group TimeStep Corporation Internet Draft Expires in six months November 21, 1997 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 utilizing authentication mechanisms that are either unidirectional in nature or that work with the base ISAKMP authentication mechanisms. R. Pereira [Page 1] Internet Draft Nov-97 Table of Contents 1. Introduction...................................................2 1.1 Specification of Requirements...............................2 2. Extended Authentication........................................2 3. Interaction with ISAKMP........................................3 3.1 ISAKMP Main Mode............................................3 3.2 ISAKMP NOTIFY Types.........................................4 3.3 ISAKMP Extended Authentication Attributes...................4 4. RADIUS Extended Authentication.................................5 5. SecureID Extended Authentication...............................5 6. Security Considerations........................................5 7. References.....................................................5 8. Editor's Address...............................................6 1. Introduction The following technique allows IPSec's ISAKMP/Oakley protocol to support extended authentication mechanisms like SDI's SecureID and RADIUS [RADIUS]. 1.1 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 Secure-ID smart cards and RADIUS are forms of authentication that allow a gateway, firewall, or network access server to offload the user administration to a central server. IPSec's ISAKMP/Oakley protocol supports certificates (RSA & DSS), shared-secret, and Kerberos as authentication methods, but since Secure-ID and RADIUS are only unidirectional authentication methods (client to a gateway/firewall), they must be used inconjunction 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 an encrypted message during the authentication exchange in phase 1. The gateway/firewall would then use either the RADIUS or SecureID transport protocol to authenticate the user. This allows a RADIUS or SecureID ACE server to be within the network (Red Side) that the gateway/firewall is protecting. R. Pereira [Page 2] Internet Draft Nov-97 While this document specifies both SecureID and RADIUS, it does not preclude any other extended authentication mechanism from being used (eg. TACACS [Finseth93]). 3. Interaction with ISAKMP By utilizing a NOTIFY payload, the gateway (responder) can request extended authentication from the client (initiator). The client then must respond with its extended authentication credentials in the next exchange. The gateway will then respond with a failure or passed message. Initiator Responder -------------- ----------------- <-- NOTIFY(XAUTH_SECUREID | XAUTH_RADIUS ) NOTIFY(XAUTH_AUTH) --> <-- NOTIFY(XAUTH_OK | XAUTH_BAD) SecureID might also return a "get next" error code, where the user must enter the next passcode. An example of such is as follows: Initiator Responder -------------- ----------------- <-- NOTIFY(XAUTH_SECUREID) NOTIFY(XAUTH_AUTH) --> <-- NOTIFY(XAUTH_OK | XAUTH_BAD |XAUTH_SECUREID) NOTIFY(XAUTH_AUTH) --> <-- NOTIFY(XAUTH_OK | XAUTH_BAD) 3.1 ISAKMP Main Mode The following is an example of Main Mode with an authentication method of RSA signatures plus an extended authentication of RADIUS. Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, [CERT,] SIG_I --> <-- HDR*, IDir, [CERT,] SIG_R, NOTIFY(1) HDR*, NOTIFY(2) --> <-- HDR*, NOTIFY(3) NOTIFY(1) = NOTIFY(XAUTH_RADIUS) NOTIFY(2) = NOTIFY(XAUTH_AUTH(user, password)) NOTIFY(3) = NOTIFY(XAUTH_OK | XAUTH_BAD('bad password')) R. Pereira [Page 3] Internet Draft Nov-97 While the extended authentication exchange MAY happen anywhere in a ISAKMP exchange, the user’s password MUST be sent over securely. Thus Aggressive Mode MUST NOT be used. The stipulation above only allows us two choices of placement in Main Mode. One as in the above example, and the other, one exchange previous, where the gateway requests extended authentication when sending over its DH key and nonce. The method shown in the example is preferable, since it allows a lookup on the ID payload for a cross-reference. The extended authentication exchange MAY also be used in Quick Mode, but for interpretability's sake, the method displayed in the example above MUST be supported. 3.2 ISAKMP NOTIFY Types NOTIFY Type Value ------------------ ---------- XAUTH_AUTH 8200 XAUTH_OK 8201 XAUTH_BAD 8202 XAUTH_SECUREID 8203 XAUTH_RADIUS 8204 XAUTH_SECUREID and XAUTH_RADIUS contains no data, while XAUTH_OK and XAUTH_BAD MAY contain a text message in the data. This text message SHOULD be displayed to the user. XAUTH_AUTH contains the user's credential attributes in the data. For RADIUS, it MUST include the user's name and password attributes (in any order). For SecureID, it MUST include the user's name, PIN and passcode attributes (in any order). 3.3 ISAKMP Extended Authentication Attributes Attribute Value Type --------------------- ------ --------- User Name 65051 Variable User Password/P.I.N. 65052 Variable Secure ID password 65052 Variable All of the above attributes are ASCII text strings. The User Name MAY be any unique identifier of the user such as a login name, an email address, or a X.500 DN. R. Pereira [Page 4] Internet Draft Nov-97 4. RADIUS Extended Authentication RADIUS [RADIUS] uses a user id and password to authenticate a client. A RADIUS server requires a shared-secret between it and any host authenticating with so as to encrypt the user's password. This shared-secret is the responsibility of the gateway. Usually the RADIUS server will require the user name and password. But it might also require optional information about the client such as its IP address (NAS-IP-ADDRESS) or its identifier (NAS- IDENTIFIER) and the port that the user is coming in on (NAS-PORT). Again, this is the responsibility of the gateway since it is authenticating on behalf of the client. Access-Challenge messages are NOT supported. 5. SecureID Extended Authentication SecureID uses smart cards to generate a 'passcode' to authenticate the user. This passcode combined with the user's password provides stronger authentication than just passwords. 6. Security Considerations Care should be taken when sending sensitive information over public networks such as the Internet. Thus the user's password should never be sent in the clear. 7. References [Bradner97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [Finseth93] Finseth, C., "An Access Control Protocol, Sometimes Called TACACS", RFC1492, 1993. [RADIUS] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote Authentication Dial In User Service (RADIUS) ", RFC2138, 1997. R. Pereira [Page 5] Internet Draft Nov-97 8. 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@chrysler.com Chrysler Corporation Theodore Y. Ts’o tytso@MIT.EDU Massachusetts Institute of Technology R. Pereira [Page 6]