idnits 2.17.1 draft-ietf-ipsec-isakmp-xauth-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 is 1 instance 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 copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (May 13, 1998) is 9480 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: 'ArchSec' is mentioned on line 109, but not defined == Missing Reference: 'Thayer97' is mentioned on line 109, but not defined == Missing Reference: 'ISAKMP' is mentioned on line 112, but not defined == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-02 -- Possible downref: Normative reference to a draft: ref. 'DIAMETER' ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp-oakley (ref. 'IKE') -- No information found for draft-ietf-ipsec-isakmp-cfg - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IKECFG' ** Obsolete normative reference: RFC 2138 (ref. 'RADIUS') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 1938 (ref. 'OTP') (Obsoleted by RFC 2289) ** Downref: Normative reference to an Informational RFC: RFC 1760 (ref. 'SKEY') ** Downref: Normative reference to an Informational RFC: RFC 1492 (ref. 'TACACS') Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 5 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 May 13, 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 made obsolete by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 To view the entire list of current Internet-Drafts, please check 29 the "1id-abstracts.txt" listing contained in the Internet-Drafts 30 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 31 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 32 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 33 (US West Coast). 35 Distribution of this memo is unlimited. 37 Copyright Notice 39 Copyright (C) The Internet Society (1998). All Rights Reserved. 41 Abstract 43 This document describes a method for using existing unidirectional 44 authentication mechanisms such as RADIUS, SecurID, and OTP within 45 IPSec's ISAKMP protocol. 47 Internet Draft May-98 49 Table of Contents 51 1. Introduction...................................................2 52 1.1 Extended Authentication.....................................2 53 1.2 Reader Prerequisites........................................3 54 1.3 Specification of Requirements...............................3 55 2. Extended Authentication Method.................................3 56 2.1 Simple Authentication.......................................4 57 2.2 Challenge/Response..........................................4 58 2.3 Two-Factor Authentication...................................4 59 2.4 One-Time-Password...........................................5 60 3. Extensions to ISAKMP-Config....................................5 61 3.1 Message Types...............................................5 62 3.2 Attributes..................................................6 63 3.3 Authentication Types........................................7 64 4. Security Considerations........................................8 65 5. References.....................................................8 66 6. Editor's Address...............................................9 67 7. Full Copyright Statement......................................10 69 1. Introduction 71 The following technique allows IPSec's ISAKMP/Oakley [IKE] protocol 72 to support extended authentication mechanisms like two-factor 73 authentication, challenge/response and other remote access 74 unidirectional authentication methods. 76 These authentication mechanisms have a large deployment in remote 77 access applications and many IT departments have requirements for 78 these unidirectional authentication mechanisms. 80 1.1 Extended Authentication 82 Two-factor authentication and challenge/response schemes like SDI's 83 SecurID and RADIUS are forms of authentication that allow a 84 gateway, firewall, or network access server to offload the user 85 administration and authentication to a central management server. 86 IPSec's ISAKMP/Oakley protocol supports certificates (RSA & DSS), 87 shared-secret, and Kerberos as authentication methods, but since 88 the authentication methods described within this document are only 89 unidirectional authentication methods (client to a 90 gateway/firewall), they cannot be used by themselves, but must be 91 used in conjunction with the other standard ISAKMP authentication 92 methods. 94 The technique described within this document utilizes ISAKMP to 95 transfer the user's authentication information (name, password) to 96 the gateway/firewall (edge device) in a secured ISAKMP message. The 98 Internet Draft May-98 100 edge device would then use either the appropriate protocol (RADIUS, 101 SecurID, OTP) to authenticate the user. This allows the 102 authentication server to be within the private network that the 103 edge device is protecting. 105 1.2 Reader Prerequisites 107 It is assumed that the reader is familiar with the terms and 108 concepts described in the "Security Architecture for the Internet 109 Protocol" [ArchSec] and "IP Security Document Roadmap" [Thayer97] 110 documents. 112 Readers are advised to be familiar with both [IKE] and [ISAKMP] as 113 well as [IKECFG] since this document is an extension of it. 115 1.3 Specification of Requirements 117 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 118 NOT", and "MAY" that appear in this document are to be interpreted 119 as described in [Bradner97]. 121 2. Extended Authentication Method 123 This specification allows for extended authentication by allowing 124 an edge device to request extended authentication from an IPSec 125 host (end-node), thus forcing the host to respond with its extended 126 authentication credentials. The edge device will then respond with 127 a failed or passed message. 129 When the edge device requests extended authentication, it will 130 specify the type of extra authentication and any parameters 131 required for it. These parameters MAY be the attributes that it 132 requires for authentication and they MAY be information required 133 for the IPSec host's reply (e.g. challenge string). 135 The last message is simply a reply back from the edge device 136 denoting failure or success. The reply MAY have some textual 137 information describing the reason for the failure or success. The 138 edge device MAY also request another authentication, like SecurID's 139 next PIN request, where the user is required to enter the next 140 passcode to further verify the user. 142 As with CHAP [CHAP], this protocol can also be used to periodically 143 authenticate the user during the lifetime of a security 144 association. 146 If the client does not have support for the authentication method 147 requested by the edge device, then it would send back a reply with 149 Internet Draft May-98 151 empty attributes, thus failing the authentication but completing 152 the transaction. 154 Here are some types of extended authentication that this 155 specification supports; 157 2.1 Simple Authentication 159 Where a user name and password are required for authentication. 161 IPSec Host Edge Device 162 -------------- ----------------- 163 <-- REQUEST(RADIUS NAME PASSWORD) 164 REPLY(RADIUS NAME PASSWORD) --> 165 <-- AUTH-OK() 167 2.2 Challenge/Response 169 Where a challenge from the edge device must be incorporated with 170 the reply. This makes each reply different. 172 IPSec Host Edge Device 173 -------------- ----------------- 174 <-- REQUEST(RADIUS CHALLENGE NAME PASSWORD) 175 REPLY(RADIUS NAME PASSWORD) --> 176 <-- AUTH-OK() 178 2.3 Two-Factor Authentication 180 This authentication method combines something the user knows (their 181 password) and something that the user has (a token card). 183 IPSec Host Edge Device 184 -------------- ----------------- 185 <-- REQUEST(SECURID NAME PASSWORD PASSCODE) 186 REPLY(SECURID NAME PASSWORD PASSCODE) --> 187 <-- AUTH-OK() 189 Some mechanisms allow for another request of the passcode. 191 IPSec Host Edge Device 192 -------------- ----------------- 193 <-- REQUEST(SECURID NAME PASSWORD PASSCODE) 194 REPLY(SECURID NAME PASSWORD PASSCODE) --> 195 <-- REQUEST(SECURID NAME PASSWORD PASSCODE) 196 REPLY(SECURID NAME PASSWORD PASSCODE) --> 197 <-- AUTH-OK() 199 Internet Draft May-98 201 2.4 One-Time-Password 203 Similar to the Challenge/Response method, this method allows 204 authentication that is secure against passive attacks based on 205 replaying captured passwords. 207 IPSec Host Edge Device 208 -------------- ----------------- 209 <-- REQUEST(OTP CHALLENGE NAME PASSWORD) 210 REPLY(OTP NAME PASSWORD) --> 211 <-- AUTH-OK() 213 3. Extensions to ISAKMP-Config 215 This protocol uses the mechanisms described in ISAKMP-Config 216 [IKECFG] to accomplish its request/reply transaction through 217 ISAKMP. 219 This protocol can therefore be used in conjunction with any 220 existing basic ISAKMP authentication method as defined in [IKE]. 221 If mutual authentication is not required, then the phase 1 222 negotiation SHOULD use an authentication method of shared-secret 223 and have that shared-secret be null. This, is however, NOT 224 suggested since the edge-device is NOT authenticated. 226 This authentication MUST be used after a phase 1 exchange has 227 completed and before a phase 2 exchange. The Transaction exchange 228 is therefore attached (appended) to the phase 1 exchanges 229 (MainMode, AggressiveMode). If the extended authentication fails, 230 then the phase 1 SA MUST be deleted. 232 The following are extensions to the ISAKMP-Config [IKECFG] 233 specification to support Extended Authentication. 235 3.1 Message Types 237 Type Value 238 -------------------------- ----------------------------- 239 ISAKMP_CFG_REQUEST ( as defined in [IKECFG] ) 240 ISAKMP_CFG_REPLY ( as defined in [IKECFG] ) 241 ISAKMP_CFG_AUTH_OK 5 242 ISAKMP_CFG_AUTH_FAILED 6 244 o ISAKMP_CFG_REQUEST - This message is sent from an edge device to 245 an IPSec host trying to request extended authentication. 246 Attributes that it requires sent back in the reply MUST be 247 included with a length of zero (0). Attributes required for the 248 authentication reply, such as a challenge string MUST be 250 Internet Draft May-98 252 included with the proper values filled in. 254 o ISAKMP_CFG_REPLY - This message MUST contain the filled in 255 authentication attributes that were requested by the edge 256 device. 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 3.2 Attributes 266 Attribute Value Type 267 --------------------- ------ --------------------- 268 XAUTH_TYPE 13 Basic 269 XAUTH_USER_NAME 14 Variable ASCII string 270 XAUTH_USER_PASSWORD 15 Variable ASCII string 271 XAUTH_PASSCODE 16 Variable ASCII string 272 XAUTH_MESSAGE 17 Variable ASCII string 273 XAUTH_CHALLENGE 18 Variable ASCII string 274 XAUTH_DOMAIN 19 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 o XAUTH_PASSCODE - A token card's passcode. This SHOULD only be 288 used when the password attribute is also used. 290 o XAUTH_MESSAGE - A textual message from an edge device to an 291 IPSec host. This message MAY be displayed to the user to notify 292 them of the reason why authentication failed or succeed. 294 o XAUTH_CHALLENGE - A challenge string sent from the edge device 295 to the IPSec host for it to include in its calculation of a 296 password or passcode. This attribute SHOULD only be sent in an 297 ISAKMP_CFG_REQUEST message. 299 Internet Draft May-98 301 o XAUTH_DOMAIN - The domain to be authenticated in. This value 302 will have different meaning depending on the authentication 303 type. 305 3.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 SecurID 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) 323 14 DIAMETER 324 15-32767 Reserved for future use 325 32768-65535 Reserved for private use 327 o Generic - A catch-all type that allows for future extensibility 328 and a generic mechanism to request authentication information. 329 This method allows for any type of extended authentication. 331 o RADIUS - A RADIUS [RADIUS] server requires a user name and a 332 password, but since RADIUS may be proxying for another type of 333 authentication method, both the request and the reply MAY be 334 like any of the other extended authentication types. 336 o OTP - One-Time-Passwords as defined in [OTP] uses a challenge 337 string to request a certain generated password. The request 338 SHOULD contain a user name, password and a challenge string 339 while the reply MUST contain the user name and the generated 340 password. The challenge string is formatted as defined in 341 [OTPEXT]. 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, 349 Internet Draft May-98 351 and SHOULD NOT be included in the reply if it isn�t included in 352 the request. 354 o Unix Login - Much like the NT Domain authentication type, but 355 this will authenticate the user to a Unix(r) workstation. 357 o SDI SecurID, AXENT Defender, LeeMah InfoCard, ActiceCard, 358 Enigma/DES Gold - All of these (and others) use smart cards to 359 generate a 'passcode' to authenticate the user. This passcode 360 combined with the user's password provides stronger 361 authentication than just passwords. The response MUST include 362 the user name, user password and the token card's passcode. 363 This authentication type MIGHT also include a challenge string 364 in the request. 366 o TACACS - Defined in [TACACS], this authentication protocol was 367 the precursor to RADIUS, thus the same rules apply. 369 o TACACS+ - Defined in [TACACS+], this authentication protocol is 370 an updated version of the original TACACS protocol, thus the 371 same rules apply. 373 o S/KEY - This one-time-password scheme defined in [SKEY] was the 374 precursor to OTP, thus the same rules apply. 376 o NDS - Much like the NT Domain authentication type, but this will 377 authenticate the user to a NetWare Directory server. 379 o DIAMETER - The next generation RADIUS protocol that is defined 380 in [DIAMETER]. The same rules as RADIUS apply. 382 4. Security Considerations 384 Care should be taken when sending sensitive information over public 385 networks such as the Internet. A user's password should never be 386 sent in the clear and when sent encrypted, the destination MUST 387 have been previously authenticated. The use of ISAKMP-Config 388 [IKECFG] addresses these issues. 390 5. References 392 [Bradner97] S. Bradner, "Key words for use in RFCs to Indicate 393 Requirement Levels", RFC2119 395 [CHAP] W. Simpson, "PPP Challenge Handshake Authentication 396 Protocol (CHAP)", RFC1994 398 Internet Draft May-98 400 [DIAMETER] P. Calhoun, A. Rubens, "DIAMETER - Base Protocol", 401 draft-calhoun-diameter-02.txt 403 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange 404 (IKE)", draft-ietf-ipsec-isakmp-oakley-07 406 [IKECFG] R. Pereira, "The ISAKMP Configuration Method", 407 draft-ietf-ipsec-isakmp-cfg-03 409 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, 410 "Remote Authentication Dial In User Service 411 (RADIUS)", RFC2138 413 [OTP] N. Haller, C. Metz, "A One-Time Password System", 414 RFC1938 416 [SKEY] N. Haller, "The S/KEY One-Time Password System", 417 RFC1760 419 [TACACS] C. Finseth, "An Access Control Protocol, Sometimes 420 Called TACACS", RFC1492 422 [TACACS+] D. Carrel, L. Grant, "The TACACS+ Protocol Version 423 1.77", draft-grant-tacacs-01.txt 425 [OTPEXT] C. Metz, "OTP Extended Responses", RFC 2243 427 6. Editor's Address 429 Roy Pereira 430 431 TimeStep Corporation 432 +1 (613) 599-3610 x 4808 434 The IPSec working group can be contacted via the IPSec working 435 group's mailing list (ipsec@tis.com) or through its chairs: 437 Robert Moskowitz 438 rgm@icsa.net 439 Internal Computer Security Association 441 Theodore Y. Ts'o 442 tytso@MIT.EDU 443 Massachusetts Institute of Technology 445 Internet Draft May-98 447 7. Full Copyright Statement 449 Copyright (C) The Internet Society (1998). All Rights Reserved. 451 This document and translations of it may be copied and furnished to 452 others, and derivative works that comment on or otherwise explain 453 it or assist in its implementation may be prepared, copied, 454 published and distributed, in whole or in part, without restriction 455 of any kind, provided that the above copyright notice and this 456 paragraph are included on all such copies and derivative works. 457 However, this document itself may not be modified in any way, such 458 as by removing the copyright notice or references to the Internet 459 Society or other Internet organizations, except as needed for the 460 purpose of developing Internet standards in which case the 461 procedures for copyrights defined in the Internet Standards process 462 must be followed, or as required to translate it into languages 463 other than English. 465 The limited permissions granted above are perpetual and will not be 466 revoked by the Internet Society or its successors or assigns. 468 This document and the information contained herein is provided on 469 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 470 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 471 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 472 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 473 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.