idnits 2.17.1 draft-aboba-ppp-01.txt: ** The Abstract section seems to be numbered 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-27) 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 -- 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 == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages 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. ** There are 110 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 203 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** 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 239: '... responseName [0] LDAPOID OPTIONAL,...' RFC 2119 keyword, line 240: '... response [1] OCTET STRING OPTIONAL...' RFC 2119 keyword, line 245: '... MUST set the resultCode of the ...' RFC 2119 keyword, line 286: '... MUST seek to ensure confidentiali...' RFC 2119 keyword, line 288: '... services in place MUST return an...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '...), its areas...' == Line 14 has weird spacing: '... its worki...' == Line 18 has weird spacing: '... and may ...' == Line 19 has weird spacing: '...afts as refer...' == Line 22 has weird spacing: '... To learn...' == (105 more instances...) -- 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 (19 November 1997) is 9656 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: 'APPLICATION 23' on line 175 == Missing Reference: '0' is mentioned on line 239, but not defined -- Looks like a reference, but probably isn't: 'APPLICATION 24' on line 238 == Unused Reference: '6' is defined on line 319, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 323, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 326, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 329, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 333, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 345, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 367, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 372, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1777 (ref. '1') (Obsoleted by RFC 3494) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Unexpected draft version: The latest known version of draft-ietf-asid-ldapv3-attributes is -07, but you're referring to -08. == Outdated reference: A later version (-08) exists of draft-ietf-asid-ldapv3-dynamic-06 ** Obsolete normative reference: RFC 2138 (ref. '6') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '7') (Obsoleted by RFC 2866) == Outdated reference: A later version (-06) exists of draft-ietf-radius-ext-01 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-ext (ref. '8') ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '9') == Outdated reference: A later version (-05) exists of draft-ietf-radius-eap-02 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-02) exists of draft-grant-tacacs-01 -- Possible downref: Normative reference to a draft: ref. '12' ** Obsolete normative reference: RFC 1334 (ref. '15') (Obsoleted by RFC 1994) == Outdated reference: A later version (-05) exists of draft-aboba-radius-01 -- Possible downref: Normative reference to a draft: ref. '16' -- Possible downref: Normative reference to a draft: ref. '17' -- No information found for draft-ietf-asid-proto-col - is the name correct? -- Possible downref: Normative reference to a draft: ref. '18' -- No information found for draft-ietf-asid-ldapv3-tls - is the name correct? -- Possible downref: Normative reference to a draft: ref. '19' -- No information found for draft-ietf-asid-dynatt - is the name correct? -- Possible downref: Normative reference to a draft: ref. '20' Summary: 18 errors (**), 0 flaws (~~), 23 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft 4 5 19 November 1997 7 Lightweight Directory Access Protocol (v3): 8 Extension for PPP Authentication 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute work- 15 ing documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference mate- 20 rial or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 The distribution of this memo is unlimited. It is filed as , and expires May 1, 1998. Please send comments to 29 the authors. 31 2. Abstract 33 This document defines the ''PPP Authentication Operation'' for LDAP. 34 This operation provides for PPP authentication in an LDAP association 35 and is defined in terms of an LDAP extended operation. 37 It is expected that this extended operation will be useful in inte- 38 grating authentication protocols such as RADIUS and TACACS+ with LDAP- 39 based directory services. Consolidation of information stores is 40 desirable since it results in lessened administrative workload and a 41 consistent view of user information throughout the enterprise. 43 3. Introduction 45 Currently RADIUS (described in [6]-[8]) and TACACS+ (described in 46 [12]) authentication servers typically include their own stores of 47 user data. In order to simplify user administration, it is desirable 48 to be able to integrate these services with an LDAP-based directory 49 service. 51 This document is one of three related specifications which describe 52 how a RADIUS server may be integrated with an LDAP-based directory 53 service. Reference [16] specifies how user data utilized by a RADIUS 54 server may be stored in an LDAP-based directory service. Reference 55 [17] describes a schema designed for tracking sessions in progress. 56 Such information can be useful for a variety of purposes including 57 security incident response; simultaneous usage control; or monitoring 58 of connection quality, login time, packet size or bandwidth usage. Due 59 to the frequency of changes to this data, dynamic attributes must be 60 employed, as described in [5]. 62 PPP authentication protocols are described in [11],[14] and [15]. 63 This document describes an LDAP extension supporting validation of 64 user credentials submitted during PPP authentication. This makes it 65 possible for the RADIUS server to validate user credentials received 66 in the Access-Request packet. 68 3.1. Alternatives for integration of PPP authentication methods 70 In order for a RADIUS server to be able to respond to an Access- 71 Request, a means must be available for validating user credentials. 72 However, current LDAP security mechanisms do not support PPP authenti- 73 cation methods so that extensions or protocol modifications are 74 required. 76 Several alternatives present themselves. One alternative is to add 77 support for PPP authentication methods to SASL, and utilize the secure 78 BIND mechanisms described in [18]. In this alternative, the RADIUS 79 server will impersonate the user and bind using the credentials sub- 80 mitted in the Access-Request. In this scenario, only the user would 81 need to have the access rights to retrieve RADIUS attributes from the 82 directory. There would not be a need to make these attributes accessi- 83 ble to a privileged account used by the RADIUS server, or to any net- 84 work devices. This is desirable from a security point of view. 86 Using this alternative, support for PPP authentication methods would 87 be added to SASL. The RADIUS server would set up an SSL/TLS connection 88 on startup, and would execute a BIND operation for each authentica- 89 tion; the server would only UNBIND on shutdown. This avoids the over- 90 head of an UNBIND and SSL/TLS connection setup for each authentica- 91 tion. 93 However, it should be noted that merely adding CHAP support to SASL 94 will not solve the problem posed here. This is because an LDAP-server 95 utilizing a CHAP extension to SASL would generate its own challenge, 96 rather than accepting a CHAP challenge and response submitted to it by 97 the RADIUS server. While such an approach would be compatible with 98 EAP-MD5, where the RADIUS server generates its own challenge, it would 99 not be compatible with CHAP, where the NAS generates the challenge and 100 passes both the CHAP challenge and the response to the RADIUS server 101 for evaluation. 103 Thus to solve the problem, it must be possible to submit both the CHAP 104 challenge and response to SASL. However, making it possible to authen- 105 ticate to an LDAP server using such a mechanism is not desirable since 106 it would make LDAP authentication susceptible to a replay attack. 108 Another alternative is to provide support for PPP authentication 109 within an LDAP extended operation. In this alternative, the RADIUS 110 server binds to the directory on startup using a special account, and 111 unbinds on shutdown. In between the bind and unbind, the RADIUS server 112 may submit as many PPP authentication requests as necessary. In this 113 scenario, the account used by the RADIUS server needs to have the 114 access rights to retrieve RADIUS attributes for any user. 116 Since the LDAP extension only returns a yes or no, but does not gain 117 the requester any privileges, it does not have the security problem 118 inherent in the SASL-based scheme described above. It is also believed 119 that this approach will utilize fewer resources on most implementa- 120 tions, since the continual execution of BIND operations, without cor- 121 responding UNBINDs, is likely to result in steady memory consumption 122 on the RADIUS server. 124 3.2. Overview 126 PPP Authentication is an extended operation initiated by an LDAP 127 client (RADIUS server) in order to request authentication of a user by 128 the LDAP-based directory. The LDAP client sends a PPP Authentication 129 request to the LDAP server, indicating the PPP authentication method, 130 and including the user's credentials, and the server then responds 131 with a message indicating the success or failure of the authentica- 132 tion. 134 When the RADIUS server receives an Access-Request packet from a NAS or 135 VPN server, it examines the User-Name attribute to determine the user 136 that is being authenticated. Based on the User-Name, the server may 137 also retrieve the authenticationType attribute for the user, and will 138 then check the authentication method specified in the Access-Request 139 against the permitted types. If there is a mis-match, then the server 140 will formulate and send an Access-Reject packet. 142 If the authentication indicated in the Access-Request is one of the 143 permitted types, and PAP or CHAP authentication is being used, the 144 RADIUS server utilizes the LDAP extension for PPP authentication spec- 145 ified in this document in order to verify the user's identity. Alter- 146 natively, the PPP authentication operation may be carried out syn- 147 chronously with retrieval of the RADIUS attributes described in [16], 148 and an Access-Reject can be sent if an authentication type mismatch is 149 detected after the retrieval (and possibly the PPP authentication 150 operation) is complete. 152 If the user authentication is unsuccessful, then the RADIUS server 153 will formulate and send an Access-Reject packet. If the user is suc- 154 cessfully authenticated, then the RADIUS server will formulate an 155 Access-Accept based on the attributes retreived from the LDAP-based 156 directory service, specified in [16]. 158 If the Access-Request contains an EAP-Message attribute with a speci- 159 fied identity, then the RADIUS server will retrieve the user's RADIUS- 160 related information from the LDAP-based directory service in order to 161 determine the type of EAP authentication for this user. Depending on 162 the eapType, the RADIUS server will then either handle the authentica- 163 tion internally (such as for MD5), or may forward the request to a 164 security server. As a result, the PPP authentication operation 165 described in this document does not need to support EAP. 167 4. Protocol Additions 169 4.1. The Start PPP Authentication Operation 171 A client may perform a PPP authentication operation by transmitting an 172 LDAP PDU containing an ExtendedRequest. An LDAP ExtendedREquest is 173 defined as follows: 175 ExtendedRequest ::= [APPLICATION 23] SEQUENCE { 176 requestName [0] LDAPOID, 177 requestValue [1] OCTET STRING } 179 The requestName field must be set to the string "". 182 This request is permitted to be invoked when LDAP is carried by a con- 183 nectionless transport. 185 When using a connection-oriented transport, there is no requirement 186 that this operation be on the same particular connection as any other. 187 A client may open multiple connections, or close and then reopen a 188 connection. 190 4.1.1. CHAP Authentication 192 When Challenge-Handshake Authentication Protocol (CHAP) authentication 193 is desired, the requestValue field will contain as a value the DER- 194 encoding of the following ASN.1 data type: 196 SEQUENCE { 197 authenticationProtocol [0] INTEGER, 198 algorithm [1] INTEGER, 199 name [2] OCTET STRING, 200 challenge [3] OCTET STRING, 201 chapIdent [4] OCTET STRING, 202 response [5] OCTET STRING 203 } 205 The authenticationProtocol field is an integer containing the Authen- 206 tication-Protocol number for CHAP, c223 (hex). The algorithm is an 207 integer indicating the one-way hash method to be used. Values include 208 MD5 (5). The name is an octet string identifying the user to be 209 authenticated. The challenge is a 16 octet string containing the CHAP 210 challenge sent by the NAS to a PPP CHAP user. The chapIdent is a sin- 211 gle octet containing the CHAP Identifer from the user's CHAP Response. 212 The response is a 16 octet field containing the CHAP Response from the 213 user. 215 4.1.2. PAP Authentication 217 When Password Authentication Protocol (PAP) authentication is desired, 218 the requestValue field will contain as a value the DER-encoding of the 219 following ASN.1 data type: 221 SEQUENCE { 222 authenticationProtocol [0] INTEGER, 223 name [1] OCTET STRING, 224 password [2] OCTET STRING 225 } 227 The authenticationProtocol field is an integer containing the Authen- 228 tication-Protocol number for PAP, c023 (hex). The name is an octet 229 string identifying the user to be authenticated. The password is an 230 octet string providing the user's password. 232 4.2. PPP Authentication Response 234 If a server implements this extension, then when the request is made 235 it will return an LDAP PDU containing an ExtendedResponse. An LDAP 236 ExtendedResponse is defined as follows: 238 ExtendedResponse ::= [APPLICATION 24] SEQUENCE { 239 responseName [0] LDAPOID OPTIONAL, 240 response [1] OCTET STRING OPTIONAL 241 standardResponse [2] LDAPResult } 243 The responseName field contains the same string as that present in the 244 PPP Authentication request. The response field is absent. The server 245 MUST set the resultCode of the standardResponse to either success or 246 one of the other values outlined below. 248 4.3. Error Messages 250 If the operation was successful, the errorCode field in the standard- 251 Response part of an ExtendedResponse will be set to success. 253 In case of an error, the errorCode field will contain an appropriate 254 value. If the authentication is not successful (due either to invalid 255 credentials or an invalid userName), the errorCode field will contain 256 the invalidCredentials result code. If the authentication protocol 257 given by authenticationProtocol could not be located, the errorCode 258 field will contain the protocolError result code. If the authentica- 259 tion protocol is not permitted, the errorCode field will contain 260 strongAuthRequired. If the requester does not have permission to per- 261 form the PPP authentication, the errorCode field will contain insuffi- 262 cientAccessRights. If the server does not do PPP authentication, but 263 knows another server that does, the errorCode field will contain 264 referral. If There is a major problem with PPP authentication, or the 265 server is shutting down the errorCode field will contain unavailable. 266 If the server is overloaded, the errorCode field will contain busy. 268 If a server does not implement this extension, it will return an LDAP 269 PDU containing an ExtendedResponse, which contains only the standard- 270 Response element (the responseName and response elements will be 271 absent). The LDAPResult element will indicate the protocolError 272 result code. 274 5. Security considerations 276 Enabling an LDAP-based directory service to perform PPP authentication 277 operations in an efficient manner may result in a number of security 278 threats, including password guessing attacks and sniffing attacks. 280 In order to prevent a rogue RADIUS server from initiating password 281 guessing attacks, it is desirable for an implementation to close a 282 connection after a number of consecutive authentication failures. 284 In order to prevent sniffing of passwords, where PAP authentication is 285 being used for transmission of cleartext passwords, the RADIUS server 286 MUST seek to ensure confidentiality by using SSL/TLS or IPSEC. An LDAP 287 server receiving a PAP authentication request representing a cleartext 288 password without confidentiality services in place MUST return an 289 error message. 291 6. Acknowledgments 293 Thanks to Gurdeep Singh Pall and Narendra Gidwani of Microsoft for 294 useful discussions of this problem space. 296 7. References 298 [1] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access Pro- 299 tocol." RFC 1777, March 1995. 301 [2] "Information Processing Systems - Open Systems Interconnection - 302 The Directory: Overview of Concepts, Models and Service." ISO/IEC JTC 303 1/SC21, International Standard 9594-1, 1988. 305 [3] "Information Processing Systems - Open Systems Interconnection - 306 The Directory: Selected Object Classes." Recommendation X.521 ISO/IEC 307 JTC 1/SC21, International Standard 9594-7, 1993. 309 [4] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory 310 Access Protocol (v3): Attribute Syntax Definitions. " Internet Draft 311 (work in progress), draft-ietf-asid-ldapv3-attributes-08.txt, Critical 312 Angle, Isode, Netscape, October 1997. 314 [5] Y. Yaacovi, M. Wahl, T. Genovese, "Lightweight Directory Access 315 Protocol (v3): Extensions for Dynamic Directory Services. " Internet 316 Draft (work in progress), draft-ietf-asid-ldapv3-dynamic-06.txt, 317 Microsoft, Critical Angle, September 1997. 319 [6] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authentica- 320 tion Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit, Day- 321 dreamer, April 1997. 323 [7] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April 324 1997. 326 [8] C. Rigney, W. Willats. "RADIUS Extensions." Work in progress, 327 draft-ietf-radius-ext-01.txt, Livingston, June 1997. 329 [9] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC 330 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., 331 April 1992. 333 [10] P. Calhoun, A. C. Rubens, B. Aboba. "Extensible Authentication 334 Protocol Support in RADIUS." Internet Draft (work in progress), 335 April, 1997, draft-ietf-radius-eap-02.txt, 3Com, Merit Network, 336 Microsoft. 338 [11] L. J. Blunk, J. R. Vollbrecht. "PPP Extensible Authentica- 339 tion Protocol (EAP)." Work in progress, draft-ietf-pppext-eap- 340 auth-02.txt, Merit Network, Inc., June, 1996. 342 [12] D. Carrel, L. Grant. "The TACACS+ Protocol Version 1.77." Work 343 in progress, draft-grant-tacacs-01.txt, Cisco Systems, October, 1996. 345 [13] Simpson, W., Editor. "The Point-to-Point Protocol (PPP)", STD 51, 346 RFC 1661, DayDreamer, July 1994. 348 [14] Simpson, W. "PPP Challenge Handshake Authentication Protocol 349 (CHAP)", RFC 1994, DayDreamer, August 1996. 351 [15] B. Lloyd, Simpson, W. "PPP Authentication Protocols", RFC 1334, 352 L&A, DayDreamer, October 1992. 354 [16] B. Aboba, "Lightweight Directory Access Protocol (v3): Schema for 355 the Remote Access Dialin User Service (RADIUS) " Internet Draft (work 356 in progress), draft-aboba-radius-01.txt, Microsoft, November 1997. 358 [17] B. Aboba, "Lightweight Directory Access Protocol (v3): Dynamic 359 Attributes for the Remote Access Dialin User Service (RADIUS)" Inter- 360 net Draft (work in progress), draft-aboba-dynradius-01.txt, Microsoft, 361 November 1997. 363 [18] M. Wahl, T. Hoews, S. Kille, "Lightweight Directory Access Proto- 364 col (v3)." Internet Draft (work in progress), draft-ietf-asid-proto- 365 col-08.txt, Critical Angle, Netscape, Isode, October 1997. 367 [19] J. Hodges, R.L. Morgan, M. Wahl, "Lightweight Directory Access 368 Protocol (v3): Extension for Transport Layer Security." Internet Draft 369 (work in progress), draft-ietf-asid-ldapv3-tls-01.txt, Stanford, Crit- 370 ical Angle, June 1997. 372 [20] Y. Yaacovi, M. Wahl, T. Genovese, "Lightweight Directory Access 373 Protocol: Dynamic Attributes." Internet Draft (work in progress), 374 draft-ietf-asid-dynatt-00.txt, Microsoft, Critical Angle, July 1997. 376 8. Authors' Addresses 378 Bernard Aboba 379 Microsoft Corporation 380 One Microsoft Way 381 Redmond, WA 98052 383 Phone: 425-936-6605 384 EMail: bernarda@microsoft.com