idnits 2.17.1 draft-ietf-ipsec-isakmp-xauth-03.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 (November 6, 1998) is 9275 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 108, but not defined == Missing Reference: 'Thayer97' is mentioned on line 108, but not defined == Missing Reference: 'ISAKMP' is mentioned on line 111, 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 November 6, 1998 6 Extended Authentication Within ISAKMP/Oakley 7 9 Status of this Memo 11 This document is a submission to the IETF Internet Protocol 12 Security (IPSECond) Working Group. Comments are solicited and 13 should be addressed to the working group mailing list 14 (ipsec@tis.com) or to the editor. 16 This document is an Internet-Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet-Drafts draft documents are valid for a maximum of six 22 months and may be updated, replaced, or made obsolete by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 To learn the current status of any Internet-Draft, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Distribution of this memo is unlimited. 35 Copyright Notice 37 Copyright (C) The Internet Society (1998). All Rights Reserved. 39 Abstract 41 This document describes a method for using existing unidirectional 42 authentication mechanisms such as RADIUS, SecurID, and OTP within 43 IPSec's ISAKMP protocol. 45 Internet Draft Nov-98 47 Table of Contents 49 1. Introduction...................................................2 50 1.1 Extended Authentication.....................................2 51 1.2 Reader Prerequisites........................................3 52 1.3 Specification of Requirements...............................3 53 2. Extended Authentication Method.................................3 54 2.1 Simple Authentication.......................................4 55 2.2 Challenge/Response..........................................4 56 2.3 Two-Factor Authentication...................................5 57 2.4 One-Time-Password...........................................5 58 3. Extensions to ISAKMP-Config....................................5 59 3.1 Message Types...............................................6 60 3.2 Attributes..................................................7 61 3.3 Authentication Types........................................8 62 4. Other Scenarios for Extended Authentication....................9 63 5. Security Considerations.......................................10 64 6. References....................................................10 65 7. Editor's Address..............................................11 66 8. Full Copyright Statement......................................11 68 1. Introduction 70 The following technique allows IPSec's ISAKMP/Oakley [IKE] protocol 71 to support extended authentication mechanisms like two-factor 72 authentication, challenge/response and other remote access 73 unidirectional authentication methods. 75 These authentication mechanisms have a large deployment in remote 76 access applications and many IT departments have requirements for 77 these unidirectional authentication mechanisms. 79 1.1 Extended Authentication 81 Two-factor authentication and challenge/response schemes like SDI's 82 SecurID and RADIUS are forms of authentication that allow a 83 gateway, firewall, or network access server to offload the user 84 administration and authentication to a central management server. 85 IPSec's ISAKMP/Oakley protocol supports certificates (RSA & DSS), 86 shared-secret, and Kerberos as authentication methods, but since 87 the authentication methods described within this document are only 88 unidirectional authentication methods (client to a 89 gateway/firewall), they cannot be used by themselves, but must be 90 used in conjunction with the other standard ISAKMP authentication 91 methods. 93 The technique described within this document utilizes ISAKMP to 94 transfer the user's authentication information (name, password) to 96 Internet Draft Nov-98 98 the gateway/firewall (edge device) in a secured ISAKMP message. The 99 edge device would then use either the appropriate protocol (RADIUS, 100 SecurID, OTP) to authenticate the user. This allows the 101 authentication server to be within the private network that the 102 edge device is protecting. 104 1.2 Reader Prerequisites 106 It is assumed that the reader is familiar with the terms and 107 concepts described in the "Security Architecture for the Internet 108 Protocol" [ArchSec] and "IP Security Document Roadmap" [Thayer97] 109 documents. 111 Readers are advised to be familiar with both [IKE] and [ISAKMP] as 112 well as [IKECFG] since this document is an extension to that 113 document. 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 itself. 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 Internet Draft Nov-98 148 If the IPSec host does not have support for the authentication 149 method requested by the edge device, then it would send back a 150 reply with empty attributes, thus failing the authentication but 151 completing the transaction. The last exchange (SET/ACK) MUST also 152 be completed. 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(TYPE=RADIUS NAME="" PASSWORD="") 164 REPLY(TYPE=RADIUS NAME="joe" PASSWORD="foobar") --> 165 <-- SET(STATUS=OK) 166 ACK() --> 168 2.2 Challenge/Response 170 Where a challenge from the edge device must be incorporated with 171 the reply. This makes each reply different. 173 IPSec Host Edge Device 174 -------------- ----------------- 175 <-- REQUEST(TYPE=RADIUS NAME="" PASSWORD="") 176 REPLY(TYPE=RADIUS NAME="joe" PASSWORD="foobar") --> 177 <-- REQUEST(TYPE=RADIUS CHALLENGE="123456" 178 NAME="" PASSWORD="" REQ_NUM=2) 179 REPLY(TYPE=RADIUS NAME="joe" PASSWORD="0985124") --> 180 <-- SET(STATUS=OK) 181 ACK() --> 183 If, however, the edge device knows that a challenge will be 184 required it may skip the first exchange as follows: 186 IPSec Host Edge Device 187 -------------- ----------------- 188 <-- REQUEST(TYPE=RADIUS CHALLENGE="123456" 189 NAME="" PASSWORD="") 190 REPLY(TYPE=RADIUS NAME="joe" PASSWORD="0985124") --> 191 <-- SET(STATUS=OK) 192 ACK() --> 194 Internet Draft Nov-98 196 2.3 Two-Factor Authentication 198 This authentication method combines something the user knows (their 199 password) and something that the user has (a token card). 201 IPSec Host Edge Device 202 -------------- ----------------- 203 <-- REQUEST(TYPE=AXENT NAME="" 204 PASSWORD="" PASSCODE="") 205 REPLY(TYPE=AXENT NAME="joe" 206 PASSWORD="foobar" PASSCODE="3412") --> 207 <-- SET(STATUS=OK) 208 ACK() --> 210 Some mechanisms allow for another optional request of the passcode. 212 IPSec Host Edge Device 213 -------------- ----------------- 214 <-- REQUEST(TYPE=SECURID NAME="" 215 PASSWORD="" PASSCODE="") 216 REPLY(TYPE=SECURID NAME="joe" 217 PASSWORD="foobar" PASSCODE="323415") --> 218 <-- REQUEST(TYPE=SECURID NAME="" PASSWORD="" 219 PASSCODE="" REQ_NUM=2) 220 REPLY(TYPE=SECURID NAME="joe" 221 PASSWORD="foobar" PASSCODE="513212") --> 222 <-- SET(STATUS=OK) 223 ACK() --> 225 2.4 One-Time-Password 227 Similar to the Challenge/Response method, this method allows 228 authentication that is secure against passive attacks based on 229 replaying captured passwords. 231 IPSec Host Edge Device 232 -------------- ----------------- 233 <-- REQUEST(TYPE=OTP CHALLENGE="otp-md5 499 ke1234" 234 NAME="" PASSWORD="") 235 REPLY(TYPE=OTP NAME="joe" 236 PASSWORD="5bf0 75d9 959d 036f") --> 237 <-- SET(STATUS=OK) 238 ACK() --> 240 3. Extensions to ISAKMP-Config 242 This protocol uses the mechanisms described in ISAKMP-Config 243 [IKECFG] to accomplish its authentication transaction. 245 Internet Draft Nov-98 247 All ISAKMP-Config messages in an extended authentication 248 transaction MUST contain the same ISAKMP-Config message ID. 250 This protocol can therefore be used in conjunction with any 251 existing basic ISAKMP authentication method as defined in [IKE]. 252 If mutual authentication is not required, then the phase 1 253 negotiation SHOULD use an authentication method of shared-secret 254 and have that shared-secret be null. This, is however, NOT 255 suggested since the edge-device is NOT authenticated. 257 This authentication MUST be used after a phase 1 exchange has 258 completed and before a phase 2 exchange. The Transaction exchange 259 is therefore attached (appended) to the phase 1 exchanges 260 (MainMode, AggressiveMode). If the extended authentication fails, 261 then the phase 1 SA MUST be deleted. 263 The following are extensions and/or clarifications to the ISAKMP- 264 Config [IKECFG] specification to support Extended Authentication. 266 3.1 Message Types 268 Type Value 269 -------------------------- ----------------------------- 270 ISAKMP_CFG_REQUEST ( as defined in [IKECFG] ) 271 ISAKMP_CFG_REPLY ( as defined in [IKECFG] ) 272 ISAKMP_CFG_SET ( as defined in [IKECFG] ) 273 ISAKMP_CFG_ACK ( as defined in [IKECFG] ) 275 o ISAKMP_CFG_REQUEST - This message is sent from an edge device to 276 an IPSec host trying to request extended authentication. 277 Attributes that it requires sent back in the reply MUST be 278 included with a length of zero (0). Attributes required for the 279 authentication reply, such as a challenge string MUST be 280 included with the proper values filled in. 282 o ISAKMP_CFG_REPLY - This message MUST contain the filled in 283 authentication attributes that were requested by the edge 284 device. 286 o ISAKMP_CFG_SET - This message is sent from an edge device and is 287 only used, within the scope of this document, to state the 288 success of the authentication. This message MUST only include 289 the success of failure of the authentication and MAY contain 290 some clarification text. 292 o ISAKMP_CFG_ACK - This message is sent from the IPSec host 293 acknowledging receipt of the authentication result. Its 295 Internet Draft Nov-98 297 attributes are not relevant and MAY be skipped entirely, thus 298 not attributes SHOULD be included. This last message in the 299 authentication transaction is used solely as an acknowledgement 300 of the previous message and to eliminate problems with 301 unacknowledged messages over UDP. 303 3.2 Attributes 305 Attribute Value Type 306 --------------------- ------ --------------------- 307 XAUTH_TYPE 13 Basic 308 XAUTH_USER_NAME 14 Variable ASCII string 309 XAUTH_USER_PASSWORD 15 Variable ASCII string 310 XAUTH_PASSCODE 16 Variable ASCII string 311 XAUTH_MESSAGE 17 Variable ASCII string 312 XAUTH_CHALLENGE 18 Variable ASCII string 313 XAUTH_DOMAIN 19 Variable ASCII string 314 XAUTH_STATUS 20 Basic 315 XAUTH_REQ_NUMBER 21 Basic 317 o XAUTH_TYPE - The type of extended authentication requested whose 318 values are described in the next section. This is a mandatory 319 attribute for the ISAKMP_CFG_REQUEST and ISAKMP_CFG_REPLY 320 messages. 322 o XAUTH_USER_NAME - The user name MAY be any unique identifier of 323 the user such as a login name, an email address, or a X.500 324 Distinguished Name. 326 o XAUTH_USER_PASSWORD - The user's password. 328 o XAUTH_PASSCODE - A token card's passcode. This SHOULD only be 329 used when the password attribute is also used. 331 o XAUTH_MESSAGE - A textual message from an edge device to an 332 IPSec host. This message MAY be displayed to the user to notify 333 them of the reason why authentication failed or succeed. 335 o XAUTH_CHALLENGE - A challenge string sent from the edge device 336 to the IPSec host for it to include in its calculation of a 337 password. This attribute SHOULD only be sent in an 338 ISAKMP_CFG_REQUEST message. 340 o XAUTH_DOMAIN - The domain to be authenticated in. This value 341 will have different meaning depending on the authentication 342 type. 344 Internet Draft Nov-98 346 o XAUTH_STATUS - A variable that is used to denote authentication 347 success (OK=1) or failure (FAIL=0). This is a mandatory 348 attribute for the ISAKMP_CFG_SET message. 350 o XAUTH_REQ_NUMBER - The number of times that a request has been 351 made, including the current request. The default value is one 352 (1) and thus does not have to be included. This attribute is 353 used to denote that an authentication transaction has had to 354 have another authentication request. The IPSec host should 355 notice that this is not a retransmit of the original request, 356 but that this is yet another request. This attribute MUST only 357 be included in the ISAKMP_CFG_REQUEST message. 359 3.3 Authentication Types 361 Value Authentication Required 362 ----- --------------------------------- 363 0 Generic 364 1 RADIUS 365 2 OTP 366 3 NT Domain 367 4 Unix Login 368 5 SDI SecurID 369 6 AXENT Defender 370 7 LeeMah InfoCard 371 8 ActiveCard 372 9 Secure Computing Enigma (DES Gold) 373 10 TACACS 374 11 TACACS+ 375 12 S/KEY 376 13 NDS (Netware Directory Services) 377 14 DIAMETER 378 15 LDAP 379 16-32767 Reserved for future use 380 32768-65535 Reserved for private use 382 o Generic - A catch-all type that allows for future extensibility 383 and a generic mechanism to request authentication information. 384 This method allows for any type of extended authentication. 386 o RADIUS - A RADIUS [RADIUS] server requires at least a user name 387 and a password, but since RADIUS may be proxying for another 388 type of authentication method, both the request and the reply 389 MAY be like any of the other extended authentication types. 391 Internet Draft Nov-98 393 o OTP - One-Time-Passwords as defined in [OTP] uses a challenge 394 string to request a certain generated password. The request 395 SHOULD contain a user name, password and a challenge string 396 while the reply MUST contain the user name and the generated 397 password. The challenge string is formatted as defined in 398 [OTPEXT]. 400 o NT Domain - This authentication type provides for user 401 authentication by login into a Windows NT(r) domain. The 402 request SHOULD contain empty user name, password and domain 403 attributes. The reply MUST contain all of these attributes 404 filled in. The domain attribute is optional for both messages, 405 and SHOULD NOT be included in the reply if it isn�t included in 406 the request. 408 o Unix Login - Much like the NT Domain authentication type, but 409 this will authenticate the user to a Unix(r) workstation. 411 o SDI SecurID, AXENT Defender, LeeMah InfoCard, ActiceCard, 412 Enigma/DES Gold - All of these (and others) use smart cards to 413 generate a 'passcode' to authenticate the user. This passcode 414 combined with the user's password provides stronger 415 authentication than just passwords. The response MUST include 416 the user name, password and the token card's passcode. This 417 authentication type MIGHT also include a challenge string in the 418 request. 420 o TACACS - Defined in [TACACS], this authentication protocol was 421 the precursor to RADIUS, thus the same rules apply. 423 o TACACS+ - Defined in [TACACS+], this authentication protocol is 424 an updated version of the original TACACS protocol, thus the 425 same rules apply. 427 o S/KEY - This one-time-password scheme defined in [SKEY] was the 428 precursor to OTP, thus the same rules apply. 430 o NDS - Much like the NT Domain authentication type, but this will 431 authenticate the user to a NetWare Directory server. 433 o DIAMETER - The next generation RADIUS protocol that is defined 434 in [DIAMETER]. The same rules as RADIUS apply. 436 4. Other Scenarios for Extended Authentication 438 Although this document described a scenario where an IPSec host 439 (eg. mobile user) was being authenticated by an edge device (eg. 441 Internet Draft Nov-98 443 firewall/gateway), the methods described can also be used for edge 444 device to edge device authentication as well as IPSec host to IPSec 445 host authentication. 447 5. Security Considerations 449 Care should be taken when sending sensitive information over public 450 networks such as the Internet. A user's password should never be 451 sent in the clear and when sent encrypted, the destination MUST 452 have been previously authenticated. The use of ISAKMP-Config 453 [IKECFG] addresses these issues. 455 6. References 457 [Bradner97] S. Bradner, "Key words for use in RFCs to Indicate 458 Requirement Levels", RFC2119 460 [CHAP] W. Simpson, "PPP Challenge Handshake Authentication 461 Protocol (CHAP)", RFC1994 463 [DIAMETER] P. Calhoun, A. Rubens, "DIAMETER - Base Protocol", 464 draft-calhoun-diameter-02.txt 466 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange 467 (IKE)", draft-ietf-ipsec-isakmp-oakley-07 469 [IKECFG] R. Pereira, "The ISAKMP Configuration Method", 470 draft-ietf-ipsec-isakmp-cfg-03 472 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, 473 "Remote Authentication Dial In User Service 474 (RADIUS)", RFC2138 476 [OTP] N. Haller, C. Metz, "A One-Time Password System", 477 RFC1938 479 [SKEY] N. Haller, "The S/KEY One-Time Password System", 480 RFC1760 482 [TACACS] C. Finseth, "An Access Control Protocol, Sometimes 483 Called TACACS", RFC1492 485 [TACACS+] D. Carrel, L. Grant, "The TACACS+ Protocol Version 486 1.77", draft-grant-tacacs-01.txt 488 [OTPEXT] C. Metz, "OTP Extended Responses", RFC 2243 490 Internet Draft Nov-98 492 7. Editor's Address 494 Roy Pereira 495 496 TimeStep Corporation 497 +1 (613) 599-3610 x 4808 499 The IPSec working group can be contacted via the IPSec working 500 group's mailing list (ipsec@tis.com) or through its chairs: 502 Robert Moskowitz 503 rgm@icsa.net 504 Internal Computer Security Association 506 Theodore Y. Ts'o 507 tytso@MIT.EDU 508 Massachusetts Institute of Technology 510 8. Full Copyright Statement 512 Copyright (C) The Internet Society (1998). All Rights Reserved. 514 This document and translations of it may be copied and furnished to 515 others, and derivative works that comment on or otherwise explain 516 it or assist in its implementation may be prepared, copied, 517 published and distributed, in whole or in part, without restriction 518 of any kind, provided that the above copyright notice and this 519 paragraph are included on all such copies and derivative works. 520 However, this document itself may not be modified in any way, such 521 as by removing the copyright notice or references to the Internet 522 Society or other Internet organizations, except as needed for the 523 purpose of developing Internet standards in which case the 524 procedures for copyrights defined in the Internet Standards process 525 must be followed, or as required to translate it into languages 526 other than English. 528 The limited permissions granted above are perpetual and will not be 529 revoked by the Internet Society or its successors or assigns. 531 This document and the information contained herein is provided on 532 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 533 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 534 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 535 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 536 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.