Network Working Group J. O'Hara, M. Rosselli Expires May 1997 New Oak, Axent Internet Draft November 1997 Token Card Extensions for ISAKMP/OAKLEY Status of this Memo 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 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.'' 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). Abstract The application of IPsec within corporations requires that it integrate existing authentication systems. This internet draft describes how 2 such systems from Axent Technologies, Inc. and Security Dynamics, Inc. can be integrated into ISAKMP. 1. Introduction This Internet Draft describes a mechanism which will allow token card authentication to be used in conjunction with ISAKMP pre-shared key mechanisms [Mamr97] for creation of IPsec Security Associations (SA). This scheme works "in band" with the ISAKMP protocol itself, requiring no additional protocols to be used between the initiator and responder. The ISAKMP/Oakley resolution draft defines four "standard" methods for authentication: digital signatures using either the Digital Signature Standard (DSS) or RSA algorithms, RSA public key encryption, and pre-shared secret keys. Token card vendors such as Security Dynamics and AXENT Technologies, however, rely on other methods, such as time-variant passwords or challenge-response systems for authentication of users, both methods use external servers for authentication. Neither scheme fits well within the four supported ISAKMP authentication methods, since all four rely on cryptographic techniques in which some secret key (either the private half of a public-private key pair, or a shared O'Hara [Page 1] Internet Draft Token Card Extensions for ISAKMP/OAKLEY Page 2 secret key) is always kept closely guarded and never transmitted across the network, even in encrypted form. The token card schemes also do not provide a key which can be used for the protection of the ISAKMP Phase 1 exchange. However, ISAKMP/Oakley provides for up to (2^16 - 1) potential authentication methods. A portion of that range is reserved for "private use among mutually consenting parties". To enable token card authentication between client and server, we defined 2 new values within this range to specify the new authentication methods. It is envisioned that if this document becomes working group chartered IANA will assign non-private numbers. The standard authentication mechanisms all provide some form of protection against what is known as a "man-in-the-middle" attack, where a malicious party located between the client and the server swaps in her own Diffie-Hellman public value(s) in place of the client's and server's, thus allowing her to intercept and decrypt all traffic intended to be encrypted between the two parties. This attack can only be prevented by the use of either shared secret or public-private pair cryptographic mechanisms. One simple approach to prevent such attacks is the use of a pre-shared user/group key, which would not authenticate the user but which would stop any man-in-the-middle attacks from anyone who does not possess the user/group key. This document assumes that the reader is familiar with the related documents "The resolution of ISAKMP with Oakley" [Hark97], and the technical specifics of the token card authentication schemes, that provide important background for this specification. In this document, the key words "MAY", "MUST", "recommended", "required", and "SHOULD", are to be interpreted as described in [RFC-2119]. 2. ISAKMP Extensions. We will define two private authentication types as follows: time-variant w/ Security Dynamics 65001 challange-repsonse w/ AXENT Technologies 65003 These authentication types will be used by the initiator in the SA payload first sent from client to server as part of the first message of an ISAKMP Phase 1 exchange. The token card authentication methods rely on a pre-shared user/group key to help protect against man-in-the-middle attacks. This user/group key is used in the exactly same manner as [Hark97] uses the key for pre-shared key authentication. Because a O'Hara [Page 2] Internet Draft Token Card Extensions for ISAKMP/OAKLEY Page 3 identifier is needed to identify the proper key, Main Mode cannot be used, since Main Mode is restricted to select it's pre-shared key on the basis of IP address alone. Therefore, Aggressive Mode MUST be used. Using the notation of [Hark97], Aggressive Mode using the token card authentication types is described as follows: Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, HASH_I, Np --> This scheme is nearly identical to that of Aggressive Mode using pre-shared key authentication. The only additional payload is Np, a Nonce payload containing additional token card specific data which is required to complete the authentication process. For all token card authentication mechanisms, the Initiator SHOULD encrypt the final message of the Aggressive Mode exchange, using the key derived from SKEYID_e as described in [Hark97]. The following two sections describe in further detail the data necessary for the two specific token card types supported by this draft. 2.1 AXENT TECHNOLOGIES Token Cards. AXENT Technologies token cards utilize a challenge-response system for authentication. In this mechanism, IDii must identify both the user/group key and the token card user. To do so, IDii should be of type ID_KEY_ID as defined in {Pip97], and the data should be the group ID concatenated with the tokenholder's user ID. (It is recommended that user/group IDs be of fixed length in order to allow the user/group ID and token card user ID to be clearly delineated.) The data in Nr should contain the challenge string, followed by a zero octet, followed by zero or more additional octets of random data to add entropy to the nonce. The Initiator should extract the challenge string from Nr and present it to the user. The data in Np must contain the user's response to the challenge. The Responder MUST make use of both HASH_I and the response in Np in order to authenticate the Initiator. For generating keying material and hashes, SKEYID is derived as follows, using the notation of [Hark97]: SKEYID = prf(group-key, Ni_b | Nr_b) O'Hara [Page 3] Internet Draft Token Card Extensions for ISAKMP/OAKLEY Page 4 2.2 SECURITY DYNAMICS Token Cards. Security Dynamics utilizes a time variant password mechanism for authentication. With this mechanism, IDii only needs to identify the group whose key will be used. The data in Np MUST be the token card user ID, followed by a zero octet, followed by the time variant password. The Responder MUST make use of both HASH_I and Np in order to authenticate the initiator. SKEYID is derived using the same algorithm as is used for AXENT Technologies token cards, described in section 2.1. Security Dynamics token authentication has two modes, Next Code, and New PIN which are not supported by this extension. Next Code mode occurs when a token is out of time synchronization with the authentication server, or has exceeded a server-defined threshold of incorrect codes. The user is required to enter a second code from her token in order to successfully authenticate. New PIN mode is used to manage the memorized PIN value associated with each token. If a user's token is in Next Code mode, the ISAKMP authentication will fail, and the user will need to perform an out-of-band exchange with the authentication server to resynchronize her token. Likewise, if a token is in New PIN mode, the user will need to perform an out-of-band exchange with the server, to establish her PIN, before authenticating via ISAKMP. 3. SECURITY Considerations. The security of this solution depends on the secrecy of the group password [Mamr97], used to secure the SA creation during ISAKMP Phase 1 and on the strength of the underlying token mechanisms. Care should be taken to protect group password (pre-shared key), including regular changes, and use of passwords that will not fall to common dictionary attacks. In addition, PIN's and other secrets must be protected to keep the underlying tokens secure. 4. References [Hark97] Harkins, D., Carrel, D., "The resolution of ISAKMP with Oakley", draft-ietf-ipsec-isakmp-oakley-04.txt. [Mamr97] Mamros, S., "Pre-shared key extensions for ISAKMP/OAKLEY", draft-mamros-pskeyext-00.txt, November 1997. [MSST96] Maughhan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)", version 8, draft-ietf-ipsec-isakmp-08.{ps,txt}. O'Hara [Page 4] Internet Draft Token Card Extensions for ISAKMP/OAKLEY Page 5 [Orm96] Orman, H., "The Oakley Key Determination Protocol", version 1, TR97-92, Department of Computer Science Technical Report, University of Arizona. [Pip97] Piper, D., "The Internet IP Security Domain Of Interpretation for ISAKMP", version 5, draft-ietf-ipsec-ipsec-doi-05.txt. [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", RFC2119, March 1997. 5. Acknowledgments The authors are indebted to John Linn and John Brainard, both of RSA Labs, for their contributions, analysis, and review. 6. Authors' Addresses John O'Hara New Oak Communications, Inc. 125 Nagog Park +1 978 266 1011 Acton, Massachusetts, 01720 johara@newoak.com Michael Rosselli AXENT Technologies Defender Business Unit 201 Ravendale Drive +1 650-526-2245 Mountain View, CA. 94043 mrosselli@axent.com O'Hara [Page 5]