idnits 2.17.1 draft-ohara-tokencard-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 4 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3. SECURITY Considerations.' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 85 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([Pip97], [RFC2119], [Orm96], [Hark97], [RFC-2119], [Mamr97], [MSST96]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 107: '... MUST be used....' RFC 2119 keyword, line 124: '... SHOULD encrypt the final mes...' RFC 2119 keyword, line 148: '... The Responder MUST make use of both...' RFC 2119 keyword, line 159: '...l be used. The data in Np MUST be the...' RFC 2119 keyword, line 161: '.... The Responder MUST make use of both...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1997) is 9659 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Mamr97' on line 197 looks like a reference -- Missing reference section? 'Hark97' on line 194 looks like a reference -- Missing reference section? 'RFC-2119' on line 88 looks like a reference -- Missing reference section? 'MSST96' on line 200 looks like a reference -- Missing reference section? 'Orm96' on line 204 looks like a reference -- Missing reference section? 'Pip97' on line 208 looks like a reference -- Missing reference section? 'RFC2119' on line 211 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. O'Hara, M. Rosselli 2 Expires May 1997 New Oak, Axent 3 Internet Draft November 1997 5 Token Card Extensions for ISAKMP/OAKLEY 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as ``work 19 in progress.'' 21 To learn the current status of any Internet-Draft, please check 22 the ``1id-abstracts.txt'' listing contained in the Internet- 23 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 24 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 25 Coast), or ftp.isi.edu (US West Coast). 27 Abstract 29 The application of IPsec within corporations requires that it 30 integrate existing authentication systems. This internet draft 31 describes how 2 such systems from Axent Technologies, Inc. and 32 Security Dynamics, Inc. can be integrated into ISAKMP. 34 1. Introduction 36 This Internet Draft describes a mechanism which will allow token 37 card authentication to be used in conjunction with ISAKMP 38 pre-shared key mechanisms [Mamr97] for creation of IPsec Security 39 Associations (SA). This scheme works "in band" with the ISAKMP 40 protocol itself, requiring no additional protocols to be used 41 between the initiator and responder. 43 The ISAKMP/Oakley resolution draft defines four "standard" methods 44 for authentication: digital signatures using either the Digital 45 Signature Standard (DSS) or RSA algorithms, RSA public key 46 encryption, and pre-shared secret keys. Token card vendors such 47 as Security Dynamics and AXENT Technologies, however, rely on other 48 methods, such as time-variant passwords or challenge-response 49 systems for authentication of users, both methods use external 50 servers for authentication. Neither scheme fits well within the 51 four supported ISAKMP authentication methods, since all four 52 rely on cryptographic techniques in which some secret key (either 53 the private half of a public-private key pair, or a shared 54 secret key) is always kept closely guarded and never transmitted 55 across the network, even in encrypted form. The token card 56 schemes also do not provide a key which can be used for the 57 protection of the ISAKMP Phase 1 exchange. 59 However, ISAKMP/Oakley provides for up to (2^16 - 1) potential 60 authentication methods. A portion of that range is reserved for 61 "private use among mutually consenting parties". To enable token 62 card authentication between client and server, we defined 2 new 63 values within this range to specify the new authentication methods. 64 It is envisioned that if this document becomes working group 65 chartered IANA will assign non-private numbers. 67 The standard authentication mechanisms all provide some form of 68 protection against what is known as a "man-in-the-middle" attack, 69 where a malicious party located between the client and the server 70 swaps in her own Diffie-Hellman public value(s) in place of the 71 client's and server's, thus allowing her to intercept and decrypt 72 all traffic intended to be encrypted between the two parties. 73 This attack can only be prevented by the use of either shared 74 secret or public-private pair cryptographic mechanisms. One 75 simple approach to prevent such attacks is the use of a 76 pre-shared user/group key, which would not authenticate the user 77 but which would stop any man-in-the-middle attacks from anyone who 78 does not possess the user/group key. 80 This document assumes that the reader is familiar with the related 81 documents "The resolution of ISAKMP with Oakley" [Hark97], and 82 the technical specifics of the token card authentication schemes, 83 that provide important background for this specification. 85 In this document, the key words "MAY", "MUST", "recommended", 86 "required", and "SHOULD", are to be interpreted as described in 87 [RFC-2119]. 89 2. ISAKMP Extensions. 91 We will define two private authentication types as follows: 93 time-variant w/ Security Dynamics 65001 94 challange-repsonse w/ AXENT Technologies 65003 96 These authentication types will be used by the initiator in the 97 SA payload first sent from client to server as part of the first 98 message of an ISAKMP Phase 1 exchange. 100 The token card authentication methods rely on a pre-shared 101 user/group key to help protect against man-in-the-middle attacks. 102 This user/group key is used in the exactly same manner as [Hark97] 103 uses the key for pre-shared key authentication. Because a 104 identifier is needed to identify the proper key, Main Mode cannot 105 be used, since Main Mode is restricted to select it's pre-shared 106 key on the basis of IP address alone. Therefore, Aggressive Mode 107 MUST be used. 109 Using the notation of [Hark97], Aggressive Mode using the token 110 card authentication types is described as follows: 112 Initiator Responder 113 ----------- ----------- 114 HDR, SA, KE, Ni, IDii --> 115 <-- HDR, SA, KE, Nr, IDir, HASH_R 116 HDR, HASH_I, Np --> 118 This scheme is nearly identical to that of Aggressive Mode using 119 pre-shared key authentication. The only additional payload is 120 Np, a Nonce payload containing additional token card specific 121 data which is required to complete the authentication process. 123 For all token card authentication mechanisms, the Initiator 124 SHOULD encrypt the final message of the Aggressive Mode exchange, 125 using the key derived from SKEYID_e as described in [Hark97]. 127 The following two sections describe in further detail the data 128 necessary for the two specific token card types supported by 129 this draft. 131 2.1 AXENT TECHNOLOGIES Token Cards. 133 AXENT Technologies token cards utilize a challenge-response system 134 for authentication. In this mechanism, IDii must identify both 135 the user/group key and the token card user. To do so, IDii should 136 be of type ID_KEY_ID as defined in {Pip97], and the data should 137 be the group ID concatenated with the tokenholder's user ID. (It 138 is recommended that user/group IDs be of fixed length in order to 139 allow the user/group ID and token card user ID to be clearly 140 delineated.) 142 The data in Nr should contain the challenge string, followed by 143 a zero octet, followed by zero or more additional octets of random 144 data to add entropy to the nonce. The Initiator should extract 145 the challenge string from Nr and present it to the user. 147 The data in Np must contain the user's response to the challenge. 148 The Responder MUST make use of both HASH_I and the response in 149 Np in order to authenticate the Initiator. 151 For generating keying material and hashes, SKEYID is derived as 152 follows, using the notation of [Hark97]: 154 SKEYID = prf(group-key, Ni_b | Nr_b) 155 2.2 SECURITY DYNAMICS Token Cards. 157 Security Dynamics utilizes a time variant password mechanism for 158 authentication. With this mechanism, IDii only needs to identify 159 the group whose key will be used. The data in Np MUST be the 160 token card user ID, followed by a zero octet, followed by the 161 time variant password. The Responder MUST make use of both HASH_I 162 and Np in order to authenticate the initiator. 164 SKEYID is derived using the same algorithm as is used for AXENT 165 Technologies token cards, described in section 2.1. 167 Security Dynamics token authentication has two modes, Next Code, 168 and New PIN which are not supported by this extension. Next Code 169 mode occurs when a token is out of time synchronization with the 170 authentication server, or has exceeded a server-defined threshold 171 of incorrect codes. The user is required to enter a second code 172 from her token in order to successfully authenticate. New PIN mode 173 is used to manage the memorized PIN value associated with each token. 175 If a user's token is in Next Code mode, the ISAKMP authentication 176 will fail, and the user will need to perform an out-of-band exchange 177 with the authentication server to resynchronize her token. Likewise, 178 if a token is in New PIN mode, the user will need to perform an 179 out-of-band exchange with the server, to establish her PIN, before 180 authenticating via ISAKMP. 182 3. SECURITY Considerations. 184 The security of this solution depends on the secrecy of the group 185 password [Mamr97], used to secure the SA creation during ISAKMP 186 Phase 1 and on the strength of the underlying token mechanisms. 187 Care should be taken to protect group password (pre-shared key), 188 including regular changes, and use of passwords that will not 189 fall to common dictionary attacks. In addition, PIN's and other 190 secrets must be protected to keep the underlying tokens secure. 192 4. References 194 [Hark97] Harkins, D., Carrel, D., "The resolution of ISAKMP with 195 Oakley", draft-ietf-ipsec-isakmp-oakley-04.txt. 197 [Mamr97] Mamros, S., "Pre-shared key extensions for ISAKMP/OAKLEY", 198 draft-mamros-pskeyext-00.txt, November 1997. 200 [MSST96] Maughhan, D., Schertler, M., Schneider, M., and Turner, J., 201 "Internet Security Association and Key Management Protocol (ISAKMP)", 202 version 8, draft-ietf-ipsec-isakmp-08.{ps,txt}. 204 [Orm96] Orman, H., "The Oakley Key Determination Protocol", version 205 1, TR97-92, Department of Computer Science Technical Report, 206 University of Arizona. 208 [Pip97] Piper, D., "The Internet IP Security Domain Of Interpretation 209 for ISAKMP", version 5, draft-ietf-ipsec-ipsec-doi-05.txt. 211 [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate 212 Requirement Levels", RFC2119, March 1997. 214 5. Acknowledgments 216 The authors are indebted to John Linn and John Brainard, both of RSA 217 Labs, for their contributions, analysis, and review. 219 6. Authors' Addresses 221 John O'Hara 222 New Oak Communications, Inc. 223 125 Nagog Park +1 978 266 1011 224 Acton, Massachusetts, 01720 johara@newoak.com 226 Michael Rosselli 227 AXENT Technologies Defender Business Unit 228 201 Ravendale Drive +1 650-526-2245 229 Mountain View, CA. 94043 mrosselli@axent.com