idnits 2.17.1 draft-ietf-ipsec-isakmp-xauth-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-19) 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 (November 21, 1997) is 9646 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) ** Downref: Normative reference to an Informational RFC: RFC 1492 (ref. 'Finseth93') ** Obsolete normative reference: RFC 2138 (ref. 'RADIUS') (Obsoleted by RFC 2865) Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Pereira 3 IP Security Working Group TimeStep Corporation 4 Internet Draft 5 Expires in six months 6 November 21, 1997 8 Extended Authentication Within ISAKMP/Oakley 9 11 Status of this Memo 13 This document is a submission to the IETF Internet Protocol 14 Security (IPSECond) Working Group. Comments are solicited and 15 should be addressed to the working group mailing list 16 (ipsec@tis.com) or to the editor. 18 This document is an Internet-Draft. Internet Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working Groups. Note that other groups may also distribute 21 working documents as Internet Drafts. 23 Internet-Drafts draft documents are valid for a maximum of six 24 months and may be updated, replaced, or obsolete by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in 27 progress." 29 To learn the current status of any Internet-Draft, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 32 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 33 ftp.isi.edu (US West Coast). 35 Distribution of this memo is unlimited. 37 Abstract 39 This document describes a method for utilizing authentication 40 mechanisms that are either unidirectional in nature or that work 41 with the base ISAKMP authentication mechanisms. 43 Internet Draft Nov-97 45 Table of Contents 47 1. Introduction...................................................2 48 1.1 Specification of Requirements...............................2 49 2. Extended Authentication........................................2 50 3. Interaction with ISAKMP........................................3 51 3.1 ISAKMP Main Mode............................................3 52 3.2 ISAKMP NOTIFY Types.........................................4 53 3.3 ISAKMP Extended Authentication Attributes...................4 54 4. RADIUS Extended Authentication.................................5 55 5. SecureID Extended Authentication...............................5 56 6. Security Considerations........................................5 57 7. References.....................................................5 58 8. Editor's Address...............................................6 60 1. Introduction 62 The following technique allows IPSec's ISAKMP/Oakley protocol to 63 support extended authentication mechanisms like SDI's SecureID and 64 RADIUS [RADIUS]. 66 1.1 Specification of Requirements 68 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 69 NOT", and "MAY" that appear in this document are to be interpreted 70 as described in [Bradner97]. 72 2. Extended Authentication 74 Secure-ID smart cards and RADIUS are forms of authentication that 75 allow a gateway, firewall, or network access server to offload the 76 user administration to a central server. IPSec's ISAKMP/Oakley 77 protocol supports certificates (RSA & DSS), shared-secret, and 78 Kerberos as authentication methods, but since Secure-ID and RADIUS 79 are only unidirectional authentication methods (client to a 80 gateway/firewall), they must be used inconjunction with the other 81 standard authentication methods. 83 The technique described within this document utilizes ISAKMP to 84 transfer the user's authentication information (name, password) to 85 the gateway/firewall in an encrypted message during the 86 authentication exchange in phase 1. The gateway/firewall would 87 then use either the RADIUS or SecureID transport protocol to 88 authenticate the user. This allows a RADIUS or SecureID ACE server 89 to be within the network (Red Side) that the gateway/firewall is 90 protecting. 92 Internet Draft Nov-97 94 While this document specifies both SecureID and RADIUS, it does not 95 preclude any other extended authentication mechanism from being 96 used (eg. TACACS [Finseth93]). 98 3. Interaction with ISAKMP 100 By utilizing a NOTIFY payload, the gateway (responder) can request 101 extended authentication from the client (initiator). The client 102 then must respond with its extended authentication credentials in 103 the next exchange. The gateway will then respond with a failure or 104 passed message. 106 Initiator Responder 107 -------------- ----------------- 108 <-- NOTIFY(XAUTH_SECUREID | XAUTH_RADIUS ) 109 NOTIFY(XAUTH_AUTH) --> 110 <-- NOTIFY(XAUTH_OK | XAUTH_BAD) 112 SecureID might also return a "get next" error code, where the user 113 must enter the next passcode. An example of such is as follows: 115 Initiator Responder 116 -------------- ----------------- 117 <-- NOTIFY(XAUTH_SECUREID) 118 NOTIFY(XAUTH_AUTH) --> 119 <-- NOTIFY(XAUTH_OK | XAUTH_BAD |XAUTH_SECUREID) 120 NOTIFY(XAUTH_AUTH) --> 121 <-- NOTIFY(XAUTH_OK | XAUTH_BAD) 123 3.1 ISAKMP Main Mode 125 The following is an example of Main Mode with an authentication 126 method of RSA signatures plus an extended authentication of RADIUS. 128 Initiator Responder 129 ---------- ----------- 130 HDR, SA --> 131 <-- HDR, SA 132 HDR, KE, Ni --> 133 <-- HDR, KE, Nr 134 HDR*, IDii, [CERT,] SIG_I --> 135 <-- HDR*, IDir, [CERT,] SIG_R, NOTIFY(1) 136 HDR*, NOTIFY(2) --> 137 <-- HDR*, NOTIFY(3) 139 NOTIFY(1) = NOTIFY(XAUTH_RADIUS) 140 NOTIFY(2) = NOTIFY(XAUTH_AUTH(user, password)) 141 NOTIFY(3) = NOTIFY(XAUTH_OK | XAUTH_BAD('bad password')) 143 Internet Draft Nov-97 145 While the extended authentication exchange MAY happen anywhere in a 146 ISAKMP exchange, the user�s password MUST be sent over securely. 147 Thus Aggressive Mode MUST NOT be used. 149 The stipulation above only allows us two choices of placement in 150 Main Mode. One as in the above example, and the other, one 151 exchange previous, where the gateway requests extended 152 authentication when sending over its DH key and nonce. The method 153 shown in the example is preferable, since it allows a lookup on the 154 ID payload for a cross-reference. 156 The extended authentication exchange MAY also be used in Quick 157 Mode, but for interpretability's sake, the method displayed in the 158 example above MUST be supported. 160 3.2 ISAKMP NOTIFY Types 162 NOTIFY Type Value 163 ------------------ ---------- 164 XAUTH_AUTH 8200 165 XAUTH_OK 8201 166 XAUTH_BAD 8202 167 XAUTH_SECUREID 8203 168 XAUTH_RADIUS 8204 170 XAUTH_SECUREID and XAUTH_RADIUS contains no data, while XAUTH_OK 171 and XAUTH_BAD MAY contain a text message in the data. This text 172 message SHOULD be displayed to the user. 174 XAUTH_AUTH contains the user's credential attributes in the data. 175 For RADIUS, it MUST include the user's name and password attributes 176 (in any order). For SecureID, it MUST include the user's name, PIN 177 and passcode attributes (in any order). 179 3.3 ISAKMP Extended Authentication Attributes 181 Attribute Value Type 182 --------------------- ------ --------- 183 User Name 65051 Variable 184 User Password/P.I.N. 65052 Variable 185 Secure ID password 65052 Variable 187 All of the above attributes are ASCII text strings. The User Name 188 MAY be any unique identifier of the user such as a login name, an 189 email address, or a X.500 DN. 191 Internet Draft Nov-97 193 4. RADIUS Extended Authentication 195 RADIUS [RADIUS] uses a user id and password to authenticate a 196 client. 198 A RADIUS server requires a shared-secret between it and any host 199 authenticating with so as to encrypt the user's password. This 200 shared-secret is the responsibility of the gateway. 202 Usually the RADIUS server will require the user name and password. 203 But it might also require optional information about the client 204 such as its IP address (NAS-IP-ADDRESS) or its identifier (NAS- 205 IDENTIFIER) and the port that the user is coming in on (NAS-PORT). 206 Again, this is the responsibility of the gateway since it is 207 authenticating on behalf of the client. 209 Access-Challenge messages are NOT supported. 211 5. SecureID Extended Authentication 213 SecureID uses smart cards to generate a 'passcode' to authenticate 214 the user. This passcode combined with the user's password provides 215 stronger authentication than just passwords. 217 6. Security Considerations 219 Care should be taken when sending sensitive information over public 220 networks such as the Internet. Thus the user's password should 221 never be sent in the clear. 223 7. References 225 [Bradner97] Bradner, S., "Key words for use in RFCs to Indicate 226 Requirement Levels", RFC 2119, March 1997. 228 [Finseth93] Finseth, C., "An Access Control Protocol, Sometimes 229 Called TACACS", RFC1492, 1993. 231 [RADIUS] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote 232 Authentication Dial In User Service (RADIUS) ", RFC2138, 1997. 234 Internet Draft Nov-97 236 8. Editor's Address 238 Roy Pereira 239 240 TimeStep Corporation 241 +1 (613) 599-3610 x 4808 243 The IPSec working group can be contacted via the IPSec working 244 group's mailing list (ipsec@tis.com) or through its chairs: 246 Robert Moskowitz 247 rgm@chrysler.com 248 Chrysler Corporation 250 Theodore Y. Ts�o 251 tytso@MIT.EDU 252 Massachusetts Institute of Technology