idnits 2.17.1 draft-ietf-ipsec-isakmp-xauth-01.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-25) 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 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. ** 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. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 11, 1998) is 9570 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) -- Looks like a reference, but probably isn't: '1' on line 208 -- Looks like a reference, but probably isn't: '2' on line 212 -- Looks like a reference, but probably isn't: '3' on line 216 == Unused Reference: 'Finseth93' is defined on line 392, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1492 (ref. 'Finseth93') ** Obsolete normative reference: RFC 2138 (ref. 'Radius97') (Obsoleted by RFC 2865) -- No information found for draft-ietf-ipsec-isakmp-cfg - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Pereira97' ** Obsolete normative reference: RFC 1938 (ref. 'Opt96') (Obsoleted by RFC 2289) ** Downref: Normative reference to an Informational RFC: RFC 1760 (ref. 'Skey95') -- Duplicate reference: RFC1492, mentioned in 'Tacacs93', was also mentioned in 'Finseth93'. ** Downref: Normative reference to an Informational RFC: RFC 1492 (ref. 'Tacacs93') Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force R. Pereira 2 IP Security Working Group TimeStep Corporation 3 Internet Draft 4 Expires in six months 5 February 11, 1998 7 Extended Authentication Within ISAKMP/Oakley 8 10 Status of this Memo 12 This document is a submission to the IETF Internet Protocol 13 Security (IPSECond) Working Group. Comments are solicited and 14 should be addressed to the working group mailing list 15 (ipsec@tis.com) or to the editor. 17 This document is an Internet-Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts. 22 Internet-Drafts draft documents are valid for a maximum of six 23 months and may be updated, replaced, or obsolete by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in 26 progress." 28 To learn the current status of any Internet-Draft, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Distribution of this memo is unlimited. 36 Abstract 38 This document describes a method for using existing unidirectional 39 authentication mechanisms such as RADIUS, SecureID, and OTP with 40 ISAKMP. 42 Internet Draft Feb-98 44 Table of Contents 46 1. Introduction...................................................2 47 1.1 Extended Authentication.....................................2 48 1.2 Specification of Requirements...............................3 49 2. Authentication Types...........................................3 50 2.1 Simple Authentication.......................................3 51 2.2 Challenge/Response..........................................3 52 2.3 Two-Factor Authentication...................................3 53 2.4 One-Time-Password...........................................4 54 3. Interaction with ISAKMP........................................4 55 3.1 Exchanges...................................................5 56 4. Extensions to ISAKMP-Config....................................5 57 4.1 NOTIFY Types................................................6 58 4.2 Attributes..................................................6 59 4.3 Authentication Types........................................7 60 5. Security Considerations........................................8 61 6. References.....................................................9 62 7. Editor's Address...............................................9 64 1. Introduction 66 The following technique allows IPSec's ISAKMP/Oakley protocol to 67 support extended authentication mechanisms like two-factor 68 authentication, challenge/response and other remote access 69 unidirectional authentication methods. 71 These authentication mechanisms have a large deployment in remote 72 access applications and many IT departments have requirements for 73 these unidirectional authentication mechanisms. 75 1.1 Extended Authentication 77 Two-factor authentication and challenge/response schemes like SDI's 78 SecureID and RADIUS are forms of authentication that allow a 79 gateway, firewall, or network access server to offload the user 80 administration and authentication to a central management server. 81 IPSec's ISAKMP/Oakley protocol supports certificates (RSA & DSS), 82 shared-secret, and Kerberos as authentication methods, but since 83 the authentication methods described within this document are only 84 unidirectional authentication methods (client to a 85 gateway/firewall), they cannot be used by themselves, but must be 86 used in-conjunction with the other standard authentication methods. 88 The technique described within this document utilizes ISAKMP to 89 transfer the user's authentication information (name, password) to 90 the gateway/firewall in a secured ISAKMP message. The 91 gateway/firewall would then use either the appropriate protocol 93 Internet Draft Feb-98 95 (RADIUS, SecureID, OTP) to authenticate the user. This allows the 96 authentication server to be within the private network that the 97 gateway/firewall is protecting. 99 1.2 Specification of Requirements 101 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 102 NOT", and "MAY" that appear in this document are to be interpreted 103 as described in [Bradner97]. 105 2. Authentication Types 107 2.1 Simple Authentication 109 Where a user name and password are required for authentication. 111 IPSec Host Edge Device 112 -------------- ----------------- 113 <-- CFG-REQUEST(RADIUS NAME PASSWORD) 114 CFG-REPLY(RADIUS NAME PASSWORD) --> 115 <-- CFG-AUTH-OK() 117 2.2 Challenge/Response 119 Where a challenge from the gateway/firewall must be incorporated 120 with the reply. This makes each reply different. 122 IPSec Host Edge Device 123 -------------- ----------------- 124 <-- CFG-REQUEST(RADIUS CHALLENGE NAME PASSWORD) 125 CFG-REPLY(RADIUS NAME PASSWORD) --> 126 <-- CFG-AUTH-OK() 128 2.3 Two-Factor Authentication 130 This authentication method combines something the user knows (their 131 password) and something that the user has (a token card). 133 IPSec Host Edge Device 134 -------------- ----------------- 135 <-- CFG-REQUEST(SECUREID NAME PASSWORD PASSCODE) 136 CFG-REPLY(SECUREID NAME PASSWORD PASSCODE) --> 137 <-- CFG-AUTH-OK() 139 Some mechanisms allow for another request of the passcode; 141 Internet Draft Feb-98 143 IPSec Host Edge Device 144 -------------- ----------------- 145 <-- CFG-REQUEST(SECUREID NAME PASSWORD PASSCODE) 146 CFG-REPLY(SECUREID NAME PASSWORD PASSCODE) --> 147 <-- CFG-REQUEST(SECUREID NAME PASSWORD PASSCODE) 148 CFG-REPLY(SECUREID NAME PASSWORD PASSCODE) --> 149 <-- CFG-AUTH-OK() 151 2.4 One-Time-Password 153 Similar to the Challenge/Response method, this method allows 154 authentication that is secure against passive attacks based on 155 replaying captured passwords. 157 IPSec Host Edge Device 158 -------------- ----------------- 159 <-- CFG-REQUEST(OTP CHALLENGE NAME PASSWORD) 160 CFG-REPLY(TOP NAME PASSWORD) --> 161 <-- CFG-AUTH-OK() 163 3. Interaction with ISAKMP 165 This protocol utilizes the mechanisms described in ISAKMP-Config 166 [Pereira97] to accomplish its request/reply transaction through 167 ISAKMP. 169 An edge device (gateway or firewall) may request extended 170 authentication from a IPSec host (end-node), thus forcing the host 171 to respond with its extended authentication credentials. The edge 172 device will then respond with a failed or passed message. 174 Example: 176 IPSec Host Edge Device 177 -------------- ----------------- 178 <-- CFG-REQUEST(SECUREID NAME PASSWORD PASSCODE) 179 CFG-REPLY(SECUREID NAME PASSWORD PASSCODE) --> 180 <-- CFG-AUTH-FAILED() 182 When the edge device requests extended authentication, it will 183 specify the type of extra authentication and any parameters 184 required for it. These parameters MAY be the attributes that it 185 requires for authentication or they MAY be information required for 186 the IPSec host's reply (eg. challenge string). 188 The last message, is simply a reply back from the gateway/firewall 189 denoting failure or passing. The replay MAY have some textual 190 information describing the reason for the failure or success. The 192 Internet Draft Feb-98 194 gateway/firewall may also request another authentication, like 195 Secure ID's next PIN request, where the user is required to enter 196 the next passcode to further verify the user. 198 3.1 Exchanges 200 ISAKMP-Config sets forth some guidelines on where these exchanges 201 may take place. This document will add on to those guidelines in 202 relation to extended authentication exchanges. 204 As described in the last section, the edge device requests extended 205 authentication. This MUST be supported at least in these three 206 places: 208 [1] ISAKMP Main Mode in the responder's second message - if the 209 client's ID is not relevant to decide whether or not to request 210 extended authentication. 212 [2] ISAKMP Main Mode in the responder's third message - if the 213 client's ID is relevant in deciding whether or not to request 214 extended authentication. 216 [3] ISAKMP Aggressive mode in the responder's first message - if 217 identity protection is not required for ISAKMP. 219 The main reason that only the above three places are valid are 220 because the client's reply MUST be secured since it will carry 221 sensitive information like passwords. 223 In the case of Aggressive Mode, ISAKMP-Config [Pereira97] denotes 224 that the response be sent in an encrypted InfoMode ISAKMP message 225 after the Aggressive Mode is done and an ISAKMP SA exists between 226 the two peers. 228 The extended authentication exchange MAY also be used in Quick 229 Mode, but for inter-operability's sake, the methods listed above 230 MUST be supported. 232 4. Extensions to ISAKMP-Config 234 The following are extensions to the ISAKMP-Config [Pereira97] 235 specification to support Extended Authentication. 237 Internet Draft Feb-98 239 4.1 NOTIFY Types 241 Type Value 242 -------------------------- ----------------------------- 243 ISAKMP_CFG_REQUEST ( as defined in [Pereira97] ) 244 ISAKMP_CFG_REPLY ( as defined in [Pereira97] ) 245 ISAKMP_CFG_AUTH_OK 105 246 ISAKMP_CFG_AUTH_FAILED 106 248 o ISAKMP_CFG_REQUEST - This message is sent from an edge device to 249 an IPSec host trying to request extended authentication. 250 Attributes that it requires sent back in the reply MUST be 251 included with a length of zero (0). Attributes required for the 252 authentication reply, such as a challenge string MUST be 253 included with the proper values filled in. 255 o ISAKMP_CFG_REPLY - This message MUST contain the authentication 256 attributes that were requested by the edge device filled in. 258 o ISAKMP_CFG_AUTH_OK - This message MAY contain a textual message 259 in the XAUTH_MESSAGE attribute. 261 o ISAKMP_CFG_AUTH_FAILED - This message MAY contain a textual 262 message in the XAUTH_MESSAGE attribute. 264 4.2 Attributes 266 Attribute Value Type 267 --------------------- ------ --------------------- 268 XAUTH_TYPE 101 Basic 269 XUATH_USER_NAME 102 Variable ASCII string 270 XAUTH_USER_PASSWORD 103 Variable ASCII string 271 XAUTH_PASSCODE 104 Variable ASCII string 272 XAUTH_MESSAGE 105 Variable ASCII string 273 XAUTH_CHALLENGE 106 Variable ASCII string 274 XAUTH_DOMAIN 107 Variable ASCII string 276 o XAUTH_TYPE - The type of extended authentication requested whose 277 values are described in the next section. This is a mandatory 278 attribute for the ISAKMP_CFG_REQUEST and ISAKMP_CFG_REPLY 279 messages. 281 o XAUTH_USER_NAME - The user name MAY be any unique identifier of 282 the user such as a login name, an email address, or a X.500 283 Distinguished Name. 285 o XAUTH_USER_PASSWORD - The user's password. 287 Internet Draft Feb-98 289 o XAUTH_PASSCODE - A token card's passcode. This SHOULD only be 290 used when the password attribute is also used. 292 o XAUTH_MESSAGE - A textual message from an edge device to an 293 IPSec host. This message SHOULD be displayed to the user to 294 notify them of the reason why authentication failed or succeed. 296 o XAUTH_CHALLENGE - A challenge string sent from the edge device 297 to the IPSec host for it to include in its calculation of a 298 password or passcode. This attribute SHOULD only be sent in a 299 ISAKMP_CFG_REQUEST message. 301 o XAUTH_DOMAIN - The domain to be authenticated in. This value 302 will have different meaning depending on the authentication 303 type. 305 4.3 Authentication Types 307 Value Authentication Required 308 ----- --------------------------------- 309 0 Generic 310 1 RADIUS 311 2 OTP 312 3 NT Domain 313 4 Unix Login 314 5 SDI SecureID 315 6 AXENT Defender 316 7 LeeMah InfoCard 317 8 ActiveCard 318 9 Secure Computing Enigma (DES Gold) 319 10 TACACS 320 11 TACACS+ 321 12 S/KEY 322 13 NDS (Netware Directory Services) 324 o Generic - A catch-all type that allows for future extensibility 325 and a generic mechanism to request authentication information. 326 This method allows for any type of extended authentication. 328 o RADIUS - A RADIUS [Radius97] server requires a user name and a 329 password, but since RADIUS may be proxying for another type of 330 authentication method, both the request and the reply MAY be 331 like any of the other extended authentication types. 333 o OTP - One-Time-Passwords as defined in [Opt96] uses a challenge 334 string to request a certain generated password. The request 335 SHOULD contain a user name, password and a challenge string 337 Internet Draft Feb-98 339 while the reply MUST contain the user name and the generated 340 password. The challenge string is formatted as defined in 341 [Metz97]. 343 o NT Domain - This authentication type provides for user 344 authentication by login into a Windows NT(r) domain. The 345 request SHOULD contain empty user name, password and domain 346 attributes. The reply MUST contain all of these attributes 347 filled in. The domain attribute is optional for both messages, 348 and SHOULD NOT be included in the reply if it isn�t included in 349 the request. 351 o Unix Login - Much like the NT Domain authentication type, but 352 this will authenticate the user to a Unix(r) workstation. 354 o SDI SecureID, AXENT Defender, LeeMah InfoCard, ActiceCard, 355 Enigma/DES Gold - All of these (and others) use smart cards to 356 generate a 'passcode' to authenticate the user. This passcode 357 combined with the user's password provides stronger 358 authentication than just passwords. The response MUST include 359 the user name, user password and the token card's passcode. 360 This authentication type MIGHT also include a challenge string 361 in the request. 363 o TACACS - Defined in [Tacacs93], this authentication protocol was 364 the precursor to RADIUS, thus the same rules apply. 366 o TACACS+ - Defined in [Tacacs+97], this authentication protocol 367 is an updated version of the original TACACS protocol, thus the 368 same rules apply. 370 o S/KEY - This one-time-password scheme defined in [Skey95] was 371 the precursor to OTP, thus the same rules apply. 373 o NDS - Much like the NT Domain authentication type, but this will 374 authenticate the user to a NetWare Directory server. 376 5. Security Considerations 378 Care should be taken when sending sensitive information over public 379 networks such as the Internet. A user's password should never be 380 sent in the clear and when sent encrypted, the destination MUST 381 have been previously authenticated. The use of ISAKMP-Config 382 [Pereira97] plus further guidelines outlined in this document 383 address these issues. 385 Internet Draft Feb-98 387 6. References 389 [Bradner97] S. Bradner, "Key words for use in RFCs to Indicate 390 Requirement Levels", RFC2119 392 [Finseth93] C. Finseth, "An Access Control Protocol, Sometimes 393 Called TACACS", RFC1492 395 [Radius97] C. Rigney, A. Rubens, W. Simpson, S. Willens, 396 "Remote Authentication Dial In User Service 397 (RADIUS)", RFC2138 399 [Pereira97] R. Pereira, "The ISAKMP Configuration Method", 400 draft-ietf-ipsec-isakmp-cfg-02 402 [Opt96] N. Haller, C. Metz, "A One-Time Password System", 403 RFC1938 405 [Skey95] N. Haller, "The S/KEY One-Time Password System", 406 RFC1760 408 [Tacacs93] C. Finseth, "An Access Control Protocol, Sometimes 409 Called TACACS", RFC1492 411 [Tacacs+97] D. Carrel, L. Grant, "The TACACS+ Protocol Version 412 1.77", draft-grant-tacacs-01.txt 414 [Metz97] C. Metz, "OTP Extended Responses", RFC 2243 416 7. Editor's Address 418 Roy Pereira 419 420 TimeStep Corporation 421 +1 (613) 599-3610 x 4808 423 The IPSec working group can be contacted via the IPSec working 424 group's mailing list (ipsec@tis.com) or through its chairs: 426 Robert Moskowitz 427 rgm3@icsa.net 428 ICSA 430 Theodore Y. Ts�o 431 tytso@MIT.EDU 432 Massachusetts Institute of Technology