idnits 2.17.1 draft-ietf-ldapbis-authmeth-09.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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([SCHEMA], [Protocol], [AuthMeth], [Roadmap], [Authmeth], [SASL], [DigestAuth]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC2829, but the abstract doesn't seem to directly say this. It does mention RFC2829 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC5, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2251, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2830, but the abstract doesn't seem to directly say this. It does mention RFC2830 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 968 has weird spacing: '... change canno...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (5 December 2003) is 7448 days in the past. Is this intentional? Checking references for intended status: Draft Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCnnnn' is mentioned on line 1703, but not defined == Missing Reference: 'Authmeth' is mentioned on line 2048, but not defined == Missing Reference: 'AuthMeth' is mentioned on line 2552, but not defined == Missing Reference: 'DigestAuth' is mentioned on line 2670, but not defined == Missing Reference: 'SCHEMA' is mentioned on line 2686, but not defined == Unused Reference: 'StringPrep' is defined on line 1183, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- No information found for draft-ietf-sasl-rfc2831bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DIGEST-MD5' -- No information found for draft-ietf-ldapbis-dn-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPDN' -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Models' -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Protocol' -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- No information found for draft-ietf-sasl-rfc2222bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASL' -- No information found for draft-ietf-sasl-saslprep-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASLPrep' -- No information found for draft-hoffman-rfc3454bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'StringPrep' -- No information found for draft-ietf-ldapbis-syntaxes-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Syntaxes' -- No information found for draft-ietf-tls-rfc2246-bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'TLS' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- No information found for draft-zeilenga-sasl-anon-xx - is the name correct? -- No information found for draft-zeilenga-sasl-plain-xx - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2828 (Obsoleted by RFC 4949) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 31 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Editor: R. Harrison 2 draft-ietf-ldapbis-authmeth-09.txt Novell, Inc. 3 Obsoletes: 2251, 2829, 2830 5 December 2003 4 Intended Category: Draft Standard 6 LDAP: Authentication Methods 7 and 8 Connection Level Security Mechanisms 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 This document is intended to be, after appropriate review and 16 revision, submitted to the RFC Editor as a Standard Track document. 17 Distribution of this memo is unlimited. Technical discussion of 18 this document will take place on the IETF LDAP Extension Working 19 Group mailing list . Please send 20 editorial comments directly to the author 21 . 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. Internet-Drafts are draft documents valid for a maximum of 27 six months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet-Drafts 29 as reference material or to cite them other than as "work in 30 progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet- 34 Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Abstract 43 This document describes authentication methods and connection level 44 security mechanisms of the Lightweight Directory Access Protocol 45 (LDAP). 47 This document details the simple Bind authentication method 48 including anonymous, unauthenticated, and plain-text password 49 methods and the SASL (Simple Authentication and Security Layer) Bind 50 authentication method including the use of DIGEST-MD5 and EXTERNAL 51 mechanisms. 53 This document also details establishment of TLS (Transport Layer 54 Security) using the Start TLS operation. 56 This document describes various authentication and authorization 57 states through which a connection to an LDAP server may pass and the 58 actions that trigger these state changes. 60 1. Introduction 62 The Lightweight Directory Access Protocol (LDAP) [Protocol] is a 63 powerful access protocol for directories. It offers means of 64 searching, retrieving and manipulating directory content, and ways 65 to access a rich set of security functions. 67 It is vital that these security functions be interoperable among all 68 LDAP clients and servers on the Internet; therefore there has to be 69 a minimum subset of security functions that is common to all 70 implementations that claim LDAP conformance. 72 Basic threats to an LDAP directory service include: 74 (1) Unauthorized access to directory data via data-retrieval 75 operations, 77 (2) Unauthorized access to reusable client authentication 78 information by monitoring others' access, 80 (3) Unauthorized access to directory data by monitoring others' 81 access, 83 (4) Unauthorized modification of directory data, 85 (5) Unauthorized modification of configuration information, 87 (6) Unauthorized or excessive use of resources (denial of service), 88 and 90 (7) Spoofing of directory: Tricking a client into believing that 91 information came from the directory when in fact it did not, 92 either by modifying data in transit or misdirecting the client's 93 connection. Also, tricking a client into sending privileged 94 information to a hostile entity that appears to be the directory 95 but is not. 97 Threats (1), (4), (5) and (6) are due to hostile clients. Threats 98 (2), (3) and (7) are due to hostile agents on the path between 99 client and server or hostile agents posing as a server. 101 LDAP can be protected with the following security mechanisms: 103 (1) Client authentication by means of the Secure Authentication and 104 Security Layer (SASL) [SASL] mechanism set, possibly backed by 105 the Transport Layer Security (TLS) [TLS] credentials exchange 106 mechanism, 108 (2) Client authorization by means of access control based on the 109 requestor's authenticated identity, 111 (3) Data integrity protection by means of TLS or SASL mechanisms 112 with security layers that provide data integrity services, 114 (4) Data confidentiality protection against snooping by means of the 115 TLS protocol or SASL mechanisms that provide data 116 confidentiality services, 118 (5) Server resource usage limitation by means of administrative 119 service limits configured on the server, and 121 (6) Server authentication by means of the TLS protocol or SASL 122 mechanism. 124 At the moment, imposition of access controls is done by means 125 outside the scope of LDAP. 127 It seems clear that allowing any implementation, faced with the 128 above requirements, to simply pick and choose among the possible 129 alternatives is not a strategy that is likely to lead to 130 interoperability. In the absence of mandates, clients will be 131 written that do not support any security function supported by the 132 server, or worse, they will support only mechanisms like the LDAP 133 simple bind using clear text passwords that provide inadequate 134 security for most circumstances. 136 Given the presence of the Directory, there is a strong desire to see 137 mechanisms where identities take the form of an LDAP distinguished 138 name [LDAPDN] and authentication data can be stored in the 139 directory. This means that this data must be updated outside the 140 protocol or only updated in sessions well protected against 141 snooping. It is also desirable to allow authentication methods to 142 carry identities not represented as LDAP DNs that are familiar to 143 the user or that are used in other systems. 145 The set of security mechanisms provided in LDAP and described in 146 this document is intended to meet the security needs for a wide 147 range of deployment scenarios and still provide a high degree of 148 interoperability among various LDAP implementations and 149 deployments. Appendix A contains example deployment scenarios that 150 list the mechanisms that might be used to achieve a reasonable 151 level of security in various circumstances. 153 1.1. Relationship to Other Documents 155 This document is an integral part of the LDAP Technical 156 Specification [Roadmap]. 158 This document obsoletes RFC 2829. 160 Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The 161 remainder of RFC 2830 is obsoleted by this document. 163 2. Conventions Used in this Document 165 2.1. Glossary of Terms 167 The following terms are used in this document. To aid the reader, 168 these terms are defined here. 170 - "user" represents any human or application entity which is 171 accessing the directory using a directory client. A directory 172 client (or client) is also known as a directory user agent 173 (DUA). 175 - "connection" and "LDAP connection" both refer to the underlying 176 transport protocol connection between two protocol peers. 178 - "TLS connection" refers to a TLS-protected LDAP connection. 180 - "association" and "LDAP association" both refer to the 181 association of the LDAP connection and its current 182 authentication and authorization state. 184 2.2. Security Terms and Concepts 186 In general, security terms in this document are used consistently 187 with the definitions provided in [RFC2828]. In addition, several 188 terms and concepts relating to security, authentication, and 189 authorization are presented in Appendix B of this document. While 190 the formal definition of these terms and concepts is outside the 191 scope of this document, an understanding of them is prerequisite to 192 understanding much of the material in this document. Readers who are 193 unfamiliar with security-related concepts are encouraged to review 194 Appendix B before reading the remainder of this document. 196 2.3. Keywords 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 200 document are to be interpreted as described in RFC 2119 [RFC2119]. 202 3. Bind Operation 204 The Bind operation defined in section 4.2 of [Protocol] allows 205 authentication information to be exchanged between the client and 206 server to establish a new LDAP association. The new LDAP association 207 is established upon successful completion of the authentication 208 exchange. 210 3.1. Implied Anonymous Bind on LDAP Association 212 Prior to the successful completion of a Bind operation and during 213 any subsequent authentication exchange, the session has an anonymous 214 LDAP association. Among other things this implies that the client 215 need not send a Bind Request in the first PDU of the connection. The 216 client may send any operation request prior to binding, and the 217 server MUST treat it as if it had been performed after an anonymous 218 bind operation. This authentication state on an LDAP association is 219 sometimes referred to as an implied anonymous bind. 221 3.2. Simple Authentication 223 The simple authentication choice provides minimal facilities for 224 establishing an anonymous association or for establishing an LDAP 225 association based upon credentials consisting of a name (in the form 226 of an [LDAPDN] and a password. 228 The simple authentication choice provides two different methods 229 for establishing an anonymous association: anonymous bind and 230 unauthenticated bind (see section 5.1). 232 The simple authentication choice provides one method for 233 establishing a non-anonymous association: simple password bind. 235 3.3. SASL Authentication Profile 237 LDAP allows authentication via any SASL mechanism [SASL]. As LDAP 238 includes native anonymous and plaintext authentication methods, the 239 ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] SASL mechanisms are 240 typically not used with LDAP. 242 Each protocol that utilizes SASL services is required to supply 243 certain information profiling the way they are exposed through the 244 protocol ([SASL] section 5). This section explains how each of these 245 profiling requirements are met by LDAP. 247 3.3.1. SASL Service Name for LDAP 249 The SASL service name for LDAP is "ldap", which has been registered 250 with the IANA as a GSSAPI service name. 252 3.3.2. SASL authentication initiation and protocol exchange 254 SASL authentication is initiated via an LDAP bind request 255 ([Protocol] section 4.2) with the following parameters: 257 - The version is 3. 258 - The AuthenticationChoice is sasl. 259 - The mechanism element of the SaslCredentials sequence contains 260 the value of the desired SASL mechanism. 261 - The optional credentials field of the SaslCredentials sequence 262 may be used to provide an initial client response for 263 mechanisms that are defined to have the client send data first 264 (see [SASL] sections 5 and 5.1). 266 In general, a SASL authentication protocol exchange consists of a 267 series of server challenges and client responses, the contents of 268 which are specific to and defined by the SASL mechanism. Thus for 269 some SASL authentication mechanisms, it may be necessary for the 270 client to respond to one or more server challenges by invoking the 271 BindRequest multiple times. A challenge is indicated by the server 272 sending a BindResponse with the resultCode set to 273 saslBindInProgress. This indicates that the server requires the 274 client to send a new bind request, with the same sasl mechanism to 275 continue the authentication process. 277 To the encapsulating protocol, these challenges and responses are 278 opaque binary tokens of arbitrary length. LDAP servers use the 279 serverSaslCreds field, an OCTET STRING, in a bind response message 280 to transmit each challenge. LDAP clients use the credentials field, 281 an OCTET STRING, in the SaslCredentials sequence of a bind request 282 message to transmit each response. Note that unlike some Internet 283 protocols where SASL is used, LDAP is not text-based, thus no Base64 284 transformations are performed on these challenge and response 285 values. 287 Clients sending a bind request with the sasl choice selected SHOULD 288 NOT send a value in the name field. Servers receiving a bind request 289 with the sasl choice selected SHALL ignore any value in the name 290 field. 292 A client may abort a SASL bind negotiation by sending a BindRequest 293 with a different value in the mechanism field of SaslCredentials, or 294 an AuthenticationChoice other than sasl. 296 If the client sends a BindRequest with the sasl mechanism field as 297 an empty string, the server MUST return a BindResponse with 298 authMethodNotSupported as the resultCode. This will allow clients to 299 abort a negotiation if it wishes to try again with the same SASL 300 mechanism. 302 The server indicates completion of the SASL challenge-response 303 exchange by responding with a bind response in which the resultCode 304 is either success, or an error indication. 306 The serverSaslCreds field in the bind response can be used to 307 include an optional challenge with a success notification for 308 mechanisms which are defined to have the server send additional data 309 along with the indication of successful completion. 311 3.3.3. Octet where negotiated security mechanisms take effect 313 When negotiated, SASL security layers take effect following the 314 transmission by the server and reception by the client of the final 315 BindResponse in the exchange. 317 Once a SASL security layer providing integrity or confidentiality 318 services takes effect, the layer remains in effect until a new layer 319 is installed (i.e. at the first octet following the final 320 BindResponse of the bind operation that caused the new layer to take 321 effect). 323 3.3.4. Determination of supported SASL mechanisms 325 An LDAP client may determine the SASL mechanisms a server supports 326 by performing a search request on the root DSE, requesting the 327 supportedSASLMechanisms attribute. The values of this attribute, if 328 any, list the mechanisms the server supports. 330 3.3.5. Rules for using SASL security layers 332 If a SASL security layer is negotiated, the client SHOULD discard 333 information about the server it obtained prior to the initiation of 334 the SASL negotiation and not obtained through secure mechanisms. 336 If a lower level security layer (such as TLS) is negotiated, any 337 SASL security services SHALL be layered on top of such security 338 layers regardless of the order of their negotiation. In all other 339 respects, SASL security services and other security layers act 340 independently, e.g. if both TLS and SASL security service are in 341 effect removing the SASL security service does not affect the 342 continuing service of TLS and vice versa. 344 Because SASL mechanisms provide critical security functions, clients 345 and servers should allow the user to specify what mechanisms are 346 acceptable and allow only those mechanisms to be used. 348 3.3.6. Use of EXTERNAL SASL Mechanism 350 A client can use the EXTERNAL SASL [SASL] mechanism to request the 351 LDAP server to make use of security credentials exchanged by a lower 352 security layer (such as by TLS authentication or IP-level security 353 [RFC2401]). 355 If the client's authentication credentials have not been established 356 at a lower security layer, the SASL EXTERNAL bind MUST fail with a 357 resultCode of inappropriateAuthentication. Any client 358 authentication and authorization state of the LDAP association is 359 lost, so the LDAP association is in an anonymous state after the 360 failure (see [Protocol] section 4.2.1). In such a situation, the 361 state of any established security layer is unaffected. 363 A client may either implicitly request that its LDAP authorization 364 identity be derived from a lower layer or it may explicitly provide 365 an authorization identity and assert that it be used in combination 366 with its authenticated TLS credentials. The former is known as an 367 implicit assertion, and the latter as an explicit assertion. 369 3.3.6.1. Implicit Assertion 371 An implicit authorization identity assertion is performed by 372 invoking a Bind request of the SASL form using the EXTERNAL 373 mechanism name that SHALL NOT include the optional credentials octet 374 string (found within the SaslCredentials sequence in the Bind 375 Request). The server will derive the client's authorization identity 376 from the authentication identity supplied by the security layer 377 (e.g., a public key certificate used during TLS establishment) 378 according to local policy. The underlying mechanics of how this is 379 accomplished are implementation specific. 381 3.3.6.2. Explicit Assertion 383 An explicit authorization identity assertion is performed by 384 invoking a Bind request of the SASL form using the EXTERNAL 385 mechanism name that SHALL include the credentials octet string. This 386 string MUST be constructed as documented in section 3.4.1. 388 The server MUST that the client's authentication identity as 389 supplied in its TLS credentials is permitted to be mapped to the 390 asserted authorization identity. The server MUST reject the Bind 391 operation with an invalidCredentials resultCode in the Bind response 392 if the client is not so authorized. 394 3.3.6.3. SASL Authorization Identity 396 When the EXTERNAL SASL mechanism is being negotiated, if the 397 SaslCredentials credentials field is present, it contains an 398 authorization identity. Other mechanisms define the location of the 399 authorization identity in the credentials field. In either case, the 400 authorization identity is represented in the authzId form described 401 below. 403 3.3.6.4 Authorization Identity Syntax 405 The authorization identity is a string of [UTF-8] encoded [Unicode] 406 characters corresponding to the following [ABNF] grammar: 408 authzId = dnAuthzId / uAuthzId 410 DNCOLON = %x64 %x6e %x3a ; "dn:" 411 UCOLON = %x75 %x3a ; "u:" 413 ; distinguished-name-based authz id. 414 dnAuthzId = DNCOLON distinguishedName 416 ; unspecified authorization id, UTF-8 encoded. 417 uAuthzId = UCOLON userid 418 userid = *UTF8 ; syntax unspecified 420 where the production is defined in section 3 of 421 [LDAPDN] and production is defined in section 1.3 of 422 [Models]. 424 In order to support additional specific authorization identity 425 forms, future updates to this specification may add new choices 426 supporting other forms may be added to the authzId production. 428 The dnAuthzId choice allows clients to assert authorization 429 identities in the form of a distinguished name to be matched in 430 accordance with the distinguishedName matching rule [Syntaxes]. The 431 decision to allow or disallow an authentication identity to have 432 access to the requested authorization identity is a matter of local 433 policy ([SASL] section 4.2). For this reason there is no requirement 434 that the asserted dn be that of an entry in directory. 436 The uAuthzId choice allows for compatibility with clients that wish 437 to assert an authorization identity to a local directory but do not 438 have that identity in distinguished name form. The value contained 439 within a uAuthzId MUST be prepared using [SASLPrep] before being 440 compared octet-wise. The format of utf8string is defined as only a 441 sequence of [UTF-8] encoded [Unicode] characters, and further 442 interpretation is subject to prior agreement between the client and 443 server. 445 For example, the userid could identify a user of a specific 446 directory service or be a login name or the local-part of an RFC 822 447 email address. A uAuthzId SHOULD NOT be assumed to be globally 448 unique. 450 4. Start TLS Operation 452 The Start Transport Layer Security (Start TLS) operation defined in 453 section 4.13 of [Protocol] provides the ability to establish [TLS] 454 on an LDAP association. 456 4.1. Sequencing of the Start TLS Operation 458 This section describes the overall procedures clients and servers 459 must follow for TLS establishment. These procedures take into 460 consideration various aspects of the overall security of the LDAP 461 association including discovery of resultant security level and 462 assertion of the client's authorization identity. 464 Note that the precise effects, on a client's authorization identity, 465 of establishing TLS on an LDAP association are described in detail 466 in section 4.2. 468 4.1.1. Start TLS Request 470 The client MAY send the Start TLS extended request at any time after 471 establishing an LDAP connection, except: 473 - when TLS is currently established on the connection, 474 - when a multi-stage SASL negotiation is in progress on the 475 connection, or 476 - when there are one or more outstanding LDAP operations on the 477 connection. 479 The result of violating any of these requirements is a resultCode of 480 operationsError, as described in [Protocol] section 4.13.2.2. Client 481 implementers should note that it is possible to receive a resultCode 482 of success for a Start TLS operation that is sent on a connection 483 with outstanding LDAP operations and the server has sufficient time 484 to process them prior to its receiving the Start TLS request. 485 Implementors of clients should ensure that they do not inadvertently 486 depend upon this race condition. 488 In particular, there is no requirement that the client have or have 489 not already performed a Bind operation before sending a Start TLS 490 operation request. The client may have already performed a Bind 491 operation when it sends a Start TLS request, or the client might 492 have not yet bound. 494 If the client did not establish a TLS connection before sending any 495 other requests, and the server requires the client to establish a 496 TLS connection before performing a particular request, the server 497 MUST reject that request by sending a resultCode of 498 confidentialityRequired or strongAuthRequired. 500 4.1.2. Start TLS Response 502 The server will return an extended response with the resultCode of 503 success if it is willing and able to negotiate TLS. It will return 504 other resultCode values (documented in [Protocol] section 4.13.2.2) 505 if it is unwilling or unable to do so. 507 In the successful case, the client (which has ceased to transfer 508 LDAP requests on the connection) MUST either begin a TLS negotiation 509 or close the connection. The client will send PDUs in the TLS Record 510 Protocol directly over the underlying transport connection to the 511 server to initiate [TLS] negotiation. 513 4.1.3. TLS Version Negotiation 515 Negotiating the version of TLS or SSL to be used is a part of the 516 [TLS] Handshake Protocol. Please refer to that document for details. 518 4.1.4. Discovery of Resultant Security Level 520 After a TLS connection is established on an LDAP association, both 521 parties must individually decide whether or not to continue based on 522 the security level achieved. Ascertaining the TLS connection's 523 security level is implementation dependent and accomplished by 524 communicating with one's respective local TLS implementation. 526 If the client or server decides that the level of authentication or 527 security is not high enough for it to continue, it SHOULD gracefully 528 close the TLS connection immediately after the TLS negotiation has 529 completed (see [Protocol] section 4.13.3.1 and section 4.2.3 below). 530 If the client decides to continue, it may gracefully close the TLS 531 connection and attempt to Start TLS again, it may send an unbind 532 request, or it may send any other LDAP request. 534 4.1.5. Server Identity Check 535 The client MUST check its understanding of the server's hostname 536 against the server's identity as presented in the server's 537 Certificate message in order to prevent man-in-the-middle attacks. 539 Matching is performed according to these rules: 541 - The client MUST use the server provided by the user (or other 542 trusted entity) as the value to compare against the server name 543 as expressed in the server's certificate. A hostname derived 544 from the user input is to be considered provided by the user 545 only if derived in a secure fashion (e.g., DNSSEC). 547 - If a subjectAltName extension of type dNSName is present in the 548 certificate, it SHOULD be used as the source of the server's 549 identity. 551 - Matching is case-insensitive. 553 - The "*" wildcard character is allowed. If present, it applies 554 only to the left-most name component. 556 For example, *.bar.com would match a.bar.com and b.bar.com, but 557 it would not match a.x.bar.com nor would it match bar.com. If 558 more than one identity of a given type is present in the 559 certificate (e.g. more than one dNSName name), a match in any 560 one of the set is considered acceptable. 562 If the hostname does not match the dNSName-based identity in the 563 certificate per the above check, user-oriented clients SHOULD either 564 notify the user (clients may give the user the opportunity to 565 continue with the connection in any case) or terminate the 566 connection and indicate that the server's identity is suspect. 567 Automated clients SHOULD close the connection, returning and/or 568 logging an error indicating that the server's identity is suspect. 570 Beyond the server identity checks described in this section, clients 571 SHOULD be prepared to do further checking to ensure that the server 572 is authorized to provide the service it is observed to provide. The 573 client may need to make use of local policy information in making 574 this determination. 576 4.1.6. Refresh of Server Capabilities Information 578 Upon TLS session establishment, the client SHOULD discard or refresh 579 all information about the server it obtained prior to the initiation 580 of the TLS negotiation and not obtained through secure mechanisms. 581 This protects against active-intermediary attacks that may have 582 altered any server capabilities information retrieved prior to TLS 583 establishment. 585 The server may advertise different capabilities after TLS 586 establishment. In particular, the value of supportedSASLMechanisms 587 may be different after TLS has been negotiated (specifically, the 588 EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only 589 after a TLS negotiation has been performed). 591 4.2. Effects of TLS on a Client's Authorization Identity 593 This section describes the effects on a client's authorization 594 identity brought about by establishing TLS on an LDAP association. 595 The default effects are described first, and next the facilities for 596 client assertion of authorization identity are discussed including 597 error conditions. Finally, the effects of closing the TLS connection 598 are described. 600 Authorization identities and related concepts are described in 601 Appendix B. 603 4.2.1. TLS Connection Establishment Effects 605 The decision to keep or invalidate the established authentication 606 and authorization identities in place after TLS is negotiated is a 607 matter of local server policy. If a server chooses to invalidate 608 established authentication and authorization identities after TLS is 609 negotiated, it MUST reply to subsequent valid operation requests 610 until the next TLS closure or successful bind request with a 611 resultCode of strongAuthRequired to indicate that the client needs 612 to bind to reestablish its authentication. If the client attempts to 613 bind using a method the server is unwilling to support, it responds 614 to the with a resultCode of authMethodNotSupported (per [Protocol]) 615 to indicate that a different authentication method should be used. 617 4.2.2. Client Assertion of Authorization Identity 619 After successfully establishing a TLS session, a client may request 620 that its credentials exchanged during the TLS establishment be 621 utilized to determine the client's authorization status. The client 622 accomplishes this via an LDAP Bind request specifying a SASL 623 mechanism of EXTERNAL [SASL]. See section 3.3.6 for additional 624 details. 626 4.2.3. TLS Connection Closure Effects 628 The decision to keep or invalidate the established authentication 629 and authorization identities in place after TLS closure is a matter 630 of local server policy. If a server chooses to invalidate 631 established authentication and authorization identities after TLS is 632 negotiated, it MUST reply to subsequent valid operation requests 633 until the next TLS closure or successful bind request with a 634 resultCode of strongAuthRequired to indicate that the client needs 635 to bind to reestablish its authentication. If the client attempts to 636 bind using a method the server is unwilling to support, it responds 637 to the with a resultCode of authMethodNotSupported (per [Protocol]) 638 to indicate that a different authentication method should be used. 640 5. Anonymous Authentication 641 Directory operations that modify entries or access protected 642 attributes or entries generally require client authentication. 643 Clients that do not intend to perform any of these operations 644 typically use anonymous authentication. 646 LDAP implementations MUST support anonymous authentication, as 647 defined in section 5.1. 649 LDAP implementations MAY support anonymous authentication with TLS, 650 as defined in section 5.2. 652 While there may be access control restrictions to prevent access to 653 directory entries, an LDAP server SHOULD allow an anonymously-bound 654 client to retrieve the supportedSASLMechanisms attribute of the root 655 DSE. 657 An LDAP server may use other information about the client provided 658 by the lower layers or external means to grant or deny access even 659 to anonymously authenticated clients. 661 5.1. Anonymous Authentication Procedure 663 Prior to successfully completing a Bind operation, the LDAP 664 association is anonymous. See section 3.1. 666 An LDAP client may also explicitly establish an anonymous 667 association by sending a Bind Request with the simple authentication 668 option and a password of zero length. A bind request where both the 669 name and password are of zero length is said to be an anonymous 670 bind. A bind request where the name, a DN, is of non-zero length, 671 and the password is of zero length is said to be an unauthenticated 672 bind. Both variations produce an anonymous association. 674 Unauthenticated binds can have significant security issues (see 675 section 10). Servers SHOULD by default reject unauthenticated bind 676 requests with a resultCode of invalidCredentials, and clients may 677 need to actively detect situations where they would make an 678 unauthenticated bind request. 680 5.2. Anonymous Authentication and TLS 682 An LDAP client may use the Start TLS operation (section 5) to 683 negotiate the use of [TLS] security. If the client has not bound 684 beforehand, then until the client uses the EXTERNAL SASL mechanism 685 to negotiate the recognition of the client's certificate, the client 686 is anonymously authenticated. 688 Recommendations on TLS ciphersuites are given in section 9. 690 An LDAP server which requests that clients provide their certificate 691 during TLS negotiation MAY use a local security policy to determine 692 whether to successfully complete TLS negotiation if the client did 693 not present a certificate which could be validated. 695 6. Password-based Authentication 697 This section discusses various options for performing password-based 698 authentication to LDAP compliant servers and the environments 699 suitable for their use. 701 The transmission of passwords in the clear--typically for 702 authentication or modification--poses a significant security risk. 703 This risk can be avoided by using SASL bind [SASL] mechanisms that 704 do not transmit passwords in the clear and by negotiating transport 705 or session layer confidentiality services before transmitting 706 password values. 708 To mitigate the security risks associated with the use of passwords, 709 a server implementation MUST implement a configuration that at the 710 time of authentication or password modification, requires: 712 1) A Start TLS encryption layer has been successfully negotiated. 714 OR 716 2) Some other confidentiality mechanism that protects the password 717 value from snooping has been provided. 719 OR 721 3) The server returns a resultCode of confidentialityRequired for 722 the operation (i.e. simple bind with password value, SASL bind 723 transmitting a password value in the clear, add or modify 724 including a userPassword value, etc.), even if the password 725 value is correct. 727 6.1. Simple Authentication 729 The LDAP "simple" authentication choice is not suitable for 730 authentication in environments where there is no network or 731 transport layer confidentiality. LDAP implementations SHOULD support 732 authentication with the "simple" authentication choice when the 733 connection is protected against eavesdropping using TLS, as defined 734 in section 4. LDAP implementations SHOULD NOT support authentication 735 with the "simple" authentication choice unless the data on the 736 connection is protected using TLS or other data confidentiality and 737 data integrity protection. 739 6.2. Digest Authentication 741 LDAP servers that implement any authentication method or mechanism 742 (other than simple anonymous bind) MUST implement the SASL 743 DIGEST-MD5 mechanism [DIGEST-MD5]. This provides client 744 authentication with protection against passive eavesdropping 745 attacks, but does not provide protection against active intermediary 746 attacks. DIGEST-MD5 also provides data integrity and data 747 confidentiality capabilities. 749 Support for subsequent authentication is OPTIONAL in clients and 750 servers. 752 Implementors must take care to ensure that they maintain the 753 semantics of the DIGEST-MD5 specification even when handling data 754 that has different semantics in the LDAP protocol. 755 For example, the SASL DIGEST-MD5 authentication mechanism utilizes 756 realm and username values ([DigestAuth section 2.1) which are 757 syntactically simple strings and semsantically simple realm and 758 username values. These values are not LDAP DNs, and there is no 759 requirement that they be represented or treated as such. Username 760 and realm values that look like LDAP DNs in form, e.g. , are syntactically allowed, however DIGEST-MD5 762 treats them as simple strings for comparison purposes. To illustrate 763 further, the two DNs (upper case "B") and 764 (lower case "b") are equivalent when 765 being compared semantically as LDAP DNs because the cn attribute is 766 defined to be case insensitive, however the two values are not 767 equivalent if they represent username values in DIGEST-MD5 because 768 [SASLPrep] semantics are used by DIGEST-MD5. 770 6.3. simple authentication choice under TLS encryption 772 Following the negotiation of an appropriate TLS ciphersuite 773 providing connection confidentiality, a client MAY authenticate to a 774 directory that supports the simple authentication choice by 775 performing a simple bind operation 777 Simple authentication with TLS encryption protection is performed as 778 follows: 780 1. The client will use the Start TLS operation [Protocol] to 781 negotiate the use of TLS security [TLS] on the connection to 782 the LDAP server. The client need not have bound to the 783 directory beforehand. 785 For the subsequent authentication procedure to be performed 786 securely, the client and server MUST negotiate a ciphersuite 787 which contains a bulk encryption algorithm of appropriate 788 strength. Recommendations on cipher suites are given in 789 section 9. 791 2. Following the successful completion of TLS negotiation, the 792 client MUST send an LDAP bind request with the version number 793 of 3, the name field containing a DN, and the simple 794 authentication choice, containing a password. 796 6.3.1. simple Authentication Choice 798 DSAs that map the DN sent in the bind request to a directory entry 799 with an associated set of one or more passwords will compare the 800 presented password to the set of passwords associated with that 801 entry. If the presented password matches any member of that set, 802 then the server will respond with a success resultCode, otherwise 803 the server will respond with an invalidCredentials resultCode. 805 6.4. Other authentication choices with TLS 807 It is also possible, following the negotiation of TLS, to perform a 808 SASL authentication that does not involve the exchange of plaintext 809 reusable passwords. In this case the client and server need not 810 negotiate a ciphersuite that provides confidentiality if the only 811 service required is data integrity. 813 7. Certificate-based authentication 815 LDAP server implementations SHOULD support authentication via a 816 client certificate in TLS, as defined in section 7.1. 818 7.1. Certificate-based authentication with TLS 820 A user who has a public/private key pair in which the public key has 821 been signed by a Certification Authority may use this key pair to 822 authenticate to the directory server if the user's certificate is 823 requested by the server. The user's certificate subject field SHOULD 824 be the name of the user's directory entry, and the Certification 825 Authority that issued the user's certificate must be sufficiently 826 trusted by the directory server in order for the server to process 827 the certificate. The means by which servers validate certificate 828 paths is outside the scope of this document. 830 A server MAY support mappings for certificates in which the subject 831 field name is different from the name of the user's directory entry. 832 A server which supports mappings of names MUST be capable of being 833 configured to support certificates for which no mapping is required. 835 The client will use the Start TLS operation [Protocol] to negotiate 836 the use of TLS security [TLS] on the connection to the LDAP server. 837 The client need not have bound to the directory beforehand. 839 In the TLS negotiation, the server MUST request a certificate. The 840 client will provide its certificate to the server, and the server 841 MUST perform a private key-based encryption, proving it has the 842 private key associated with the certificate. 844 In deployments that require protection of sensitive data in transit, 845 the client and server MUST negotiate a ciphersuite that contains a 846 bulk encryption algorithm of appropriate strength. Recommendations 847 of cipher suites are given in section 9. 849 The server MUST verify that the client's certificate is valid. The 850 server will normally check that the certificate is issued by a known 851 certification authority (CA), and that none of the certificates on 852 the client's certificate chain are invalid or revoked. There are 853 several procedures by which the server can perform these checks. 855 Following the successful completion of TLS negotiation, the client 856 will send an LDAP bind request with the SASL EXTERNAL mechanism. 858 8. LDAP Association State Transition Tables 860 To comprehensively diagram the various authentication and TLS states 861 through hich an LDAP association may pass, this section provides a 862 state transition table to represent a state diagram for the various 863 states through which an LDAP association may pass during the course 864 of its existence and the actions that cause these changes in state. 866 8.1. LDAP Association States 868 The following table lists the valid LDAP association states and 869 provides a description of each state. The ID for each state is used 870 in the state transition table in section 8.4. 872 ID State Description 873 -- -------------------------------------------------------------- 874 S1 Anonymous 875 no Authentication ID is associated with the LDAP connection 876 no Authorization ID is in force 877 S2 Authenticated 878 Authentication ID = I 879 Authorization ID = X 880 S3 Authenticated SASL EXTERNAL, implicit authorization ID 881 Authentication ID = J 882 Authorization ID = Y 883 S4 Authenticated SASL EXTERNAL, explicit authorization ID 884 Authentication ID = J 885 Authorization ID = Z 887 8.2. Actions that Affect LDAP Association State 889 The following table lists the actions that can affect the 890 authentication and authorization state of an LDAP association. The 891 ID for each action is used in the state transition table in section 892 8.4. 894 ID Action 895 -- -------------------------------------------------------------- 896 A1 Client bind request fails 897 A2 Client successfully performs anonymous simple bind 898 A3 Client successfully performs unauthenticated simple bind 899 A4 Client successfully performs simple bind with name and 900 password OR SASL bind with any mechanism except EXTERNAL using 901 an authentication ID = I that maps to authorization ID X 902 A5 Client Binds SASL EXTERNAL with implicit assertion of 903 authorization ID (section 3.3.6.1)]. The current 904 authentication ID maps to authorization ID = Y. 905 A6 Client Binds SASL EXTERNAL with explicit assertion of 906 authorization ID = Z (section 3.3.6.2)] 908 A7 Client abandons a bind operation, and server processes the 909 abandon 910 A8 Client abandons a bind operation, and server does not process 911 the abandon 912 A9 Client Start TLS request fails 913 A10 Client Start TLS request succeeds 914 A11 Client or Server: graceful TLS closure ([Protocol] section 915 4.13.3.1.) 917 8.3. Decisions Used in Making LDAP Association State Changes 919 Certain changes in the authentication and authorization state of an 920 LDAP association are only allowed if the server can affirmatively 921 answer a question. These questions are applied as part of the 922 criteria for allowing or disallowing a state transition in the state 923 transition table in section 8.4. 925 ID Decision Question 926 -- -------------------------------------------------------------- 927 D1 Are lower-layer credentials available? 928 D2 Can lower-layer credentials for Auth ID "K" be mapped asserted 929 AuthZID "L"? 931 8.4. LDAP Association State Transition Table 933 The LDAP Association table below lists the valid authentication and 934 authorization states for an LDAP association and the actions that 935 could affect them. For any given row in the table, the Current State 936 column gives the state of an LDAP association, the Action column 937 gives an action that could affect the state of an LDAP assocation, 938 and the Next State column gives the resulting state of an LDAP 939 association after the action occurs. 941 S1, the initial state for the state machine described in this table, 942 is the authentication state when an LDAP connection is initially 943 established. 945 Current Next 946 State Action State Comment 947 ------- ------- ----- --------------------------------------- 948 Any A1 S1 [Protocol] section 4.2.1 949 Any A2 S1 Section 6 950 Any A3 S1 Section 6 951 Any A4 S2 Sections 6.1, 6.2 952 Any A5, S1 Failed bind, section 3.3.6 953 D1=no 954 Any A5, S3 955 D1=yes 956 Any A6, S1 failed bind, section 3.3.6 957 D1=no 958 Any A6, S1 failed bind, section 3.3.6.2 959 D1=yes, 960 D2=no 962 Any A6, S4 963 D1=yes, 964 D2=yes 965 Any A7 S1 [Protocol] section 4.2.1. Clients 966 cannot detect this state. 967 Any A8 no [Protocol] section 4.2.1. Clients 968 change cannot detect this state. 969 Any A9 no [Protocol] section 4.13.2.2 970 change 971 Any A10 no Section 4.2.1 972 change 973 Any A11 S1 Section 4.2.3 975 9. TLS Ciphersuites 977 A client or server that supports TLS MUST support 978 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and MAY support other ciphersuites 979 offering equivalent or better protection. 981 Several issues should be considered when selecting TLS ciphersuites 982 that are appropriate for use in a given circumstance. These issues 983 include the following: 985 - The ciphersuite's ability to provide adequate confidentiality 986 protection for passwords and other data sent over the LDAP 987 connection. Client and server implementers should recognize that 988 some TLS ciphersuites provide no confidentiality protection 989 while other ciphersuites that do provide confidentiality 990 protection may be vulnerable to being cracked using brute force 991 methods, especially in light of ever-increasing CPU speeds that 992 reduce the time needed to successfully mount such attacks. 994 Client and server implementers SHOULD carefully consider the 995 value of the password or data being protected versus the level 996 of confidentially protection provided by the ciphersuite to 997 ensure that the level of protection afforded by the ciphersuite 998 is appropriate. 1000 - The ciphersuite's vulnerability (or lack thereof) to man-in-the- 1001 middle attacks. Ciphersuites vulnerable to man-in-the-middle 1002 attacks SHOULD NOT be used to protect passwords or sensitive 1003 data, unless the network configuration is such that the danger 1004 of a man-in-the-middle attack is tolerable. 1006 9.1. TLS Ciphersuites Recommendations 1008 As of the writing of this document, the following recommendations 1009 regarding TLS ciphersuites are applicable. Because circumstances are 1010 constantly changing, this list must not be considered exhaustive, 1011 but is hoped that it will serve as a useful starting point for 1012 implementers. 1014 The following ciphersuites defined in [TLS] MUST NOT be used for 1015 confidentiality protection of passwords or data: 1017 TLS_NULL_WITH_NULL_NULL 1018 TLS_RSA_WITH_NULL_MD5 1019 TLS_RSA_WITH_NULL_SHA 1021 The following ciphersuites defined in [TLS] can be cracked easily 1022 (less than a day of CPU time on a standard CPU in 2000) and are NOT 1023 RECOMMENDED for use in confidentiality protection of passwords or 1024 data. 1026 TLS_RSA_EXPORT_WITH_RC4_40_MD5 1027 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 1028 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA 1029 TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA 1030 TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA 1031 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA 1032 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA 1033 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 1034 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA 1036 The following ciphersuites are vulnerable to man-in-the-middle 1037 attacks: 1039 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 1040 TLS_DH_anon_WITH_RC4_128_MD5 1041 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA 1042 TLS_DH_anon_WITH_DES_CBC_SHA 1043 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA 1045 10. Security Considerations 1047 Security issues are discussed throughout this memo; the 1048 (unsurprising) conclusion is that mandatory security is important 1049 and that session confidentiality protection is required when 1050 snooping is a problem. 1052 Servers are encouraged to prevent modifications by anonymous users. 1054 Servers can minimize denial of service attacks by timing out idle 1055 connections, and returning the unwillingToPerform resultCode rather 1056 than performing computationally expensive operations requested by 1057 unauthorized clients. 1059 The use of cleartext passwords and other unprotected authentication 1060 credentials is strongly discouraged over open networks when the 1061 underlying transport service cannot guarantee confidentiality. 1063 Operational experience shows that clients can (and frequently do) 1064 misuse unauthenticated bind (see section 5.1). For example, a 1065 client program might make a decision to grant access to non- 1066 directory information on the basis of completing a successful bind 1067 operation. Some LDAP server implementations will return a success 1068 response to an unauthenticated bind thus leaving the client with the 1069 impression that the server has successfully authenticated the 1070 identity represented by the user name, when in effect, an anonymous 1071 LDAP association has been created. Clients that use the results from 1072 a simple bind operation to make authorization decisions should 1073 actively detect unauthenticated bind requests (via the empty 1074 password value) and react appropriately. 1076 Access control SHOULD always be applied when reading sensitive 1077 information or updating directory information. 1079 A connection on which the client has not performed the Start TLS 1080 operation or negotiated a suitable SASL mechanism for connection 1081 integrity and encryption services is subject to man-in-the-middle 1082 attacks to view and modify information in transit. 1084 10.1. Start TLS Security Considerations 1086 The goals of using the TLS protocol with LDAP are to ensure 1087 connection confidentiality and integrity, and to optionally provide 1088 for authentication. [TLS] expressly provides these capabilities. 1090 All security gained via use of the Start TLS operation is gained by 1091 the use of TLS itself. The Start TLS operation, on its own, does not 1092 provide any additional security. 1094 Once established, TLS only provides for and ensures confidentiality 1095 and integrity of the operations and data in transit over the LDAP 1096 association--and only if the implementations on the client and 1097 server support and negotiate it. The use of TLS does not provide or 1098 ensure for confidentiality and/or non-repudiation of the data housed 1099 by an LDAP-based directory server. Nor does it secure the data from 1100 inspection by the server administrators. 1102 The level of security provided though the use of TLS depends 1103 directly on both the quality of the TLS implementation used and the 1104 style of usage of that implementation. Additionally, an active- 1105 intermediary attacker can remove the Start TLS extended operation 1106 from the supportedExtension attribute of the root DSE. Therefore, 1107 both parties SHOULD independently ascertain and consent to the 1108 security level achieved once TLS is established and before beginning 1109 use of the TLS connection. For example, the security level of the 1110 TLS connection might have been negotiated down to plaintext. 1112 Clients SHOULD either warn the user when the security level achieved 1113 does not provide confidentiality and/or integrity protection, or be 1114 configurable to refuse to proceed without an acceptable level of 1115 security. 1117 Client and server implementors SHOULD take measures to ensure proper 1118 protection of credentials and other confidential data where such 1119 measures are not otherwise provided by the TLS implementation. 1121 Server implementors SHOULD allow for server administrators to elect 1122 whether and when connection confidentiality and/or integrity is 1123 required, as well as elect whether and when client authentication 1124 via TLS is required. 1126 Additional security considerations relating to the EXTERNAL 1127 mechanism to negotiate TLS can be found in [SASL] and [TLS]. 1129 11. IANA Considerations 1131 The following IANA considerations apply to this document: 1133 Please update the GSSAPI service name registry to point to [Roadmap] 1134 and this document. 1136 [To be completed] 1138 Acknowledgements 1140 This document combines information originally contained in RFC 2829 1141 and RFC 2830. The editor acknowledges the work of Harald Tveit 1142 Alvestrand, Jeff Hodges, Tim Howes, Steve Kille, RL "Bob" Morgan , 1143 and Mark Wahl, each of whom authored one or more of these documents. 1145 This document is based upon input of the IETF LDAP Revision working 1146 group. The contributions and suggestions made by its members in 1147 shaping the contents and technical accuracy of this document is 1148 greatly appreciated. 1150 Normative References 1152 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate 1153 Requirement Levels", BCP 14, RFC 2119, March 1997. 1155 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1156 Specifications: ABNF", RFC 2234, November 1997. 1158 [DIGEST-MD5] Leach, P. C. Newman, and A. Melnikov, "Using Digest 1159 Authentication as a SASL Mechanism", draft-ietf-sasl-rfc2831bis- 1160 xx.txt, a work in progress. 1162 [LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String Representation of 1163 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work in 1164 progress. 1166 [Models] Zeilenga, Kurt D. (editor), "LDAP: Directory Information 1167 Models", draft-ietf-ldapbis-models-xx.txt, a work in progress. 1169 [Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf- 1170 ldapbis-protocol-xx.txt, a work in progress. 1172 [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map", 1173 draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. 1175 [SASL] Melnikov, A. (editor), "Simple Authentication and Security 1176 Layer (SASL)", draft-ietf-sasl-rfc2222bis-xx.txt, a work in 1177 progress. 1179 [SASLPrep] Zeilenga, K., "Stringprep profile for user names and 1180 passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in 1181 progress). 1183 [StringPrep] Hoffman P. and M. Blanchet, "Preparation of 1184 Internationalized Strings ('stringprep')", draft-hoffman- 1185 rfc3454bis-xx.txt, a work in progress. 1187 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", 1188 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 1190 [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1", 1191 draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress. 1193 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1194 RFC 3629, STD 63, November 2003. 1196 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 1197 3.2.0" is defined by "The Unicode Standard, Version 3.0" 1198 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as 1199 amended by the "Unicode Standard Annex #27: Unicode 3.1" 1200 (http://www.unicode.org/reports/tr27/) and by the �Unicode 1201 Standard Annex #28: Unicode 3.2" 1202 (http://www.unicode.org/reports/tr28/). 1204 Informative References 1206 [ANONYMOUS] Zeilenga, K.,"Anonymous SASL Mechanism", draft-zeilenga- 1207 sasl-anon-xx.txt, a work in progress. 1209 [PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga-sasl- 1210 plain-xx.txt, a work in progress. 1212 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May 1213 2000. 1215 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1216 Internet Protocol", RFC 2401, November 1998. 1218 Author's Address 1220 Roger Harrison 1221 Novell, Inc. 1222 1800 S. Novell Place 1223 Provo, UT 84606 1224 +1 801 861 2642 1225 roger_harrison@novell.com 1227 Appendix A. Example Deployment Scenarios 1229 The following scenarios are typical for LDAP directories on the 1230 Internet, and have different security requirements. (In the 1231 following discussion, "sensitive data" refers to information whose 1232 disclosure, alteration, destruction, or loss would adversely affect 1233 the interests or business of its owner or user. Also note that there 1234 may be data that is protected but not sensitive.) This is not 1235 intended to be a comprehensive list; other scenarios are possible, 1236 especially on physically protected networks. 1238 (1) A read-only directory, containing no sensitive data, accessible 1239 to "anyone", and TCP connection hijacking or IP spoofing is not 1240 a problem. Anonymous authentication, described in section 7, is 1241 suitable for this type of deployment, and requires no additional 1242 security functions except administrative service limits. 1244 (2) A read-only directory containing no sensitive data; read access 1245 is granted based on identity. TCP connection hijacking is not 1246 currently a problem. This scenario requires data confidentiality 1247 for sensitive authentication information AND data integrity for 1248 all authentication information. 1250 (3) A read-only directory containing no sensitive data; and the 1251 client needs to ensure the identity of the directory server and 1252 that the directory data is not modified while being returned 1253 from the server. A data origin authentication service AND data 1254 integrity service are required. 1256 (4) A read-write directory, containing no sensitive data; read 1257 access is available to "anyone", update access to properly 1258 authorized persons. TCP connection hijacking is not currently a 1259 problem. This scenario requires data confidentiality for 1260 sensitive authentication information AND data integrity for all 1261 authentication information. 1263 (5) A directory containing sensitive data. This scenario requires 1264 data confidentiality protection AND secure authentication. 1266 Appendix B. Authentication and Authorization: Definitions and Concepts 1268 This appendix defines basic terms, concepts, and interrelationships 1269 regarding authentication, authorization, credentials, and identity. 1270 These concepts are used in describing how various security 1271 approaches are utilized in client authentication and authorization. 1273 B.1. Access Control Policy 1275 An access control policy is a set of rules defining the protection 1276 of resources, generally in terms of the capabilities of persons or 1277 other entities accessing those resources. A common expression of an 1278 access control policy is an access control list. Security objects 1279 and mechanisms, such as those described here, enable the expression 1280 of access control policies and their enforcement. Access control 1281 policies are typically expressed in terms of access control factors 1282 as described below. 1284 B.2. Access Control Factors 1286 A request, when it is being processed by a server, may be associated 1287 with a wide variety of security-related factors (section 4.2 of 1288 [Protocol]). The server uses these factors to determine whether and 1289 how to process the request. These are called access control factors 1290 (ACFs). They might include source IP address, encryption strength, 1291 the type of operation being requested, time of day, etc. Some 1292 factors may be specific to the request itself, others may be 1293 associated with the connection via which the request is transmitted, 1294 others (e.g. time of day) may be "environmental". 1296 Access control policies are expressed in terms of access control 1297 factors. E.g., a request having ACFs i,j,k can perform operation Y 1298 on resource Z. The set of ACFs that a server makes available for 1299 such expressions is implementation-specific. 1301 B.3. Authentication, Credentials, Identity 1303 Authentication credentials are the evidence supplied by one party to 1304 another, asserting the identity of the supplying party (e.g. a user) 1305 who is attempting to establish an association with the other party 1306 (typically a server). Authentication is the process of generating, 1307 transmitting, and verifying these credentials and thus the identity 1308 they assert. An authentication identity is the name presented in a 1309 credential. 1311 There are many forms of authentication credentials -- the form used 1312 depends upon the particular authentication mechanism negotiated by 1313 the parties. For example: X.509 certificates, Kerberos tickets, 1314 simple identity and password pairs. Note that an authentication 1315 mechanism may constrain the form of authentication identities used 1316 with it. 1318 B.4. Authorization Identity 1320 An authorization identity is one kind of access control factor. It 1321 is the name of the user or other entity that requests that 1322 operations be performed. Access control policies are often expressed 1323 in terms of authorization identities; e.g., entity X can perform 1324 operation Y on resource Z. 1326 The authorization identity bound to an association is often exactly 1327 the same as the authentication identity presented by the client, but 1328 it may be different. SASL allows clients to specify an authorization 1329 identity distinct from the authentication identity asserted by the 1330 client's credentials. This permits agents such as proxy servers to 1331 authenticate using their own credentials, yet request the access 1332 privileges of the identity for which they are proxying [SASL]. Also, 1333 the form of authentication identity supplied by a service like TLS 1334 may not correspond to the authorization identities used to express a 1335 server's access control policy, requiring a server-specific mapping 1336 to be done. The method by which a server composes and validates an 1337 authorization identity from the authentication credentials supplied 1338 by a client is implementation-specific. 1340 Appendix C. RFC 2829 Change History 1342 This appendix lists the changes made to the text of RFC 2829 in 1343 preparing this document. 1345 C.0. General Editorial Changes 1346 Version -00 1348 - Changed other instances of the term LDAP to LDAP where v3 of the 1349 protocol is implied. Also made all references to LDAP use the 1350 same wording. 1352 - Miscellaneous grammatical changes to improve readability. 1354 - Made capitalization in section headings consistent. 1356 Version -01 1358 - Changed title to reflect inclusion of material from RFC 2830 and 1359 2251. 1361 C.1. Changes to Section 1 1363 Version -01 1365 - Moved conventions used in document to a separate section. 1367 C.2. Changes to Section 2 1369 Version -01 1371 - Moved section to an appendix. 1373 C.3. Changes to Section 3 1375 Version -01 1377 - Moved section to an appendix. 1379 C.4 Changes to Section 4 1381 Version -00 1383 - Changed "Distinguished Name" to "LDAP distinguished name". 1385 C.5. Changes to Section 5 1387 Version -00 1388 - Added the following sentence: "Servers SHOULD NOT allow clients 1389 with anonymous authentication to modify directory entries or 1390 access sensitive information in directory entries." 1392 C.5.1. Changes to Section 5.1 1394 Version -00 1396 - Replaced the text describing the procedure for performing an 1397 anonymous bind (protocol) with a reference to section 4.2 of RFC 1398 2251 (the protocol spec). 1400 Version -01 1402 - Brought text describing procedure for performing an anonymous 1403 bind from section 4.2 of RFC 2251 bis. This text will be 1404 removed from the draft standard version of that document. 1406 C.6. Changes to Section 6. 1408 Version -00 1410 Reorganized text in section 6.1 as follows: 1412 1. Added a new section (6.1) titled "Simple Authentication" and 1413 moved one of two introductory paragraphs for section 6 into 1414 section 6.1. Added sentences to the paragraph indicating: 1416 a. simple authentication is not suitable for environments where 1417 confidentiality is not available. 1419 b. LDAP implementations SHOULD NOT support simple 1420 authentication unless confidentiality and data integrity 1421 mechanisms are in force. 1423 2. Moved first paragraph of section 6 (beginning with "LDAP 1424 implementations MUST support authentication with a password...") 1425 to section on Digest Authentication (Now section 6.2). 1427 C.6.1. Changes to Section 6.1. 1429 Version -00 Renamed section to 6.2 1431 - Added sentence from original section 6 indicating that the 1432 DIGEST-MD5 SASL mechanism is required for all conforming LDAP 1433 implementations 1435 C.6.2. Changes to Section 6.2 1437 Version -00 1439 - Renamed section to 6.3 1440 - Reworded first paragraph to remove reference to user and the 1441 userPassword password attribute Made the first paragraph more 1442 general by simply saying that if a directory supports simple 1443 authentication that the simple bind operation MAY performed 1444 following negotiation of a TLS ciphersuite that supports 1445 confidentiality. 1447 - Replaced "the name of the user's entry" with "a DN" since not 1448 all bind operations are performed on behalf of a "user." 1450 - Added Section 6.3.1 heading just prior to paragraph 5. 1452 - Paragraph 5: replaced "The server" with "DSAs that map the DN 1453 sent in the bind request to a directory entry with a 1454 userPassword attribute." 1456 C.6.3. Changes to section 6.3. 1458 Version -00 1460 - Renamed to section 6.4. 1462 C.7. Changes to section 7. 1464 none 1466 C.7.1. Changes to section 7.1. 1468 Version -00 1470 - Clarified the entity issuing a certificate by moving the phrase 1471 "to have issued the certificate" immediately after 1472 "Certification Authority." 1474 C.8. Changes to section 8. 1476 Version -00 1478 - Removed the first paragraph because simple authentication is 1479 covered explicitly in section 6. 1481 - Added section 8.1. heading just prior to second paragraph. 1483 - Added section 8.2. heading just prior to third paragraph. 1485 - Added section 8.3. heading just prior to fourth paragraph. 1487 Version -01 1489 - Moved entire section 8 of RFC 2829 into section 3.4 (Using SASL 1490 for Other Security Services) to bring material on SASL 1491 mechanisms together into one location. 1493 C.9. Changes to section 9. 1495 Version -00 1497 - Paragraph 2: changed "EXTERNAL mechanism" to "EXTERNAL SASL 1498 mechanism." 1500 - Added section 9.1. heading. 1502 - Modified a comment in the ABNF from "unspecified userid" to 1503 "unspecified authz id". 1505 - Deleted sentence, "A utf8string is defined to be the UTF-8 1506 encoding of one or more ISO 10646 characters," because it is 1507 redundant. 1509 - Added section 9.1.1. heading. 1511 - Added section 9.1.2. heading. 1513 Version -01 1515 - Moved entire section 9 to become section 3.5 so that it would be 1516 with other SASL material. 1518 C.10. Changes to Section 10. 1520 Version -00 1522 - Updated reference to cracking from a week of CPU time in 1997 to 1523 be a day of CPU time in 2000. 1525 - Added text: "These ciphersuites are NOT RECOMMENDED for use... 1526 and server implementers SHOULD" to sentence just prior the 1527 second list of ciphersuites. 1529 - Added text: "and MAY support other ciphersuites offering 1530 equivalent or better protection," to the last paragraph of the 1531 section. 1533 C.11. Changes to Section 11. 1535 Version -01 1537 - Moved to section 3.6 to be with other SASL material. 1539 C.12. Changes to Section 12. 1541 Version -00 1543 - Inserted new section 12 that specifies when SASL protections 1544 begin following SASL negotiation, etc. The original section 12 1545 is renumbered to become section 13. 1547 Version -01 1548 - Moved to section 3.7 to be with other SASL material. 1550 C.13. Changes to Section 13 (original section 12). 1552 None 1554 Appendix D. RFC 2830 Change History 1556 This appendix lists the changes made to the text of RFC 2830 in 1557 preparing this document. 1559 D.0. General Editorial Changes 1561 - Material showing the PDUs for the Start TLS response was broken 1562 out into a new section. 1564 - The wording of the definition of the Start TLS request and Start 1565 TLS response was changed to make them parallel. NO changes were 1566 made to the ASN.1 definition or the associated values of the 1567 parameters. 1569 - A separate section heading for graceful TLS closure was added 1570 for parallelism with section on abrupt TLS closure. 1572 Appendix E. RFC 2251 Change History 1574 This appendix lists the changes made to the text of RFC 2251 in 1575 preparing this document. 1577 E.0. General Editorial Changes 1579 - All material from section 4.2 of RFC 2251 was moved into this 1580 document. 1582 - A new section was created for the Bind Request 1584 - Section 4.2.1 of RFC 2251 (Sequencing Bind Request) was moved 1585 after the section on the Bind Response for parallelism with the 1586 presentation of the Start TLS operations. The section was also 1587 subdivided to explicitly call out the various effects being 1588 described within it. 1590 - All SASL profile information from RFC 2829 was brought within 1591 the discussion of the Bind operation (primarily sections 4.4 - 1592 4.7). 1594 Appendix F. Change History to Combined Document 1596 F.1. Changes for draft-ldap-bis-authmeth-02 1598 General 1599 - Added references to other LDAP standard documents, to sections 1600 within the document, and fixed broken references. 1602 - General editorial changes--punctuation, spelling, formatting, 1603 etc. 1605 Section 1. 1607 - Added glossary of terms and added sub-section headings 1609 Section 2. 1611 - Clarified security mechanisms 3, 4, & 5 and brought language in 1612 line with IETF security glossary. 1614 Section 3. 1616 - Brought language in requirement (3) in line with security 1617 glossary. 1619 - Clarified that information fetched prior to initiation of TLS 1620 negotiation must be discarded 1622 -Clarified that information fetched prior to initiation of SASL 1623 negotiation must be discarded 1625 - Rewrote paragraph on SASL negotiation requirements to clarify 1626 intent 1628 Section 4.4. 1630 - Added stipulation that sasl choice allows for any SASL mechanism 1631 not prohibited by this document. (Resolved conflict between this 1632 statement and one that prohibited use of ANONYMOUS and PLAIN 1633 SASL mechanisms.) 1635 Section 5.3.6 1637 - Added a.x.bar.com to wildcard matching example on hostname 1638 check. 1640 Section 6 1642 - Added LDAP Association State Transition Tables to show the 1643 various states through which an LDAP association may pass along 1644 with the actions and decisions required to traverse from state 1645 to state. 1647 Appendix A 1649 - Brought security terminology in line with IETF security glossary 1650 throughout the appendix. 1652 F.2. Changes for draft-ldap-bis-authmeth-03 1653 General 1655 - Added introductory notes and changed title of document and 1656 references to conform to WG chair suggestions for the overall 1657 technical specification. 1659 - Several issues--G.13, G.14, G.16, G.17--were resolved without 1660 requiring changes to the document. 1662 Section 3 1664 - Removed reference to /etc/passwd file and associated text. 1666 Section 4 1668 - Removed sections 4.1, 4.2 and parts of section 4.3. This 1669 information was being duplicated in the protocol specification 1670 and will now reside there permanently. 1671 Section 4.2 1673 - changed words, "not recommended" to "strongly discouraged" 1675 Section 4.3 1677 - Based on ldapbis WG discussion at IETF52 two sentences were 1678 added indicating that clients SHOULD NOT send a DN value when 1679 binding with the sasl choice and servers SHALL ignore any value 1680 received in this circumstance. 1681 - 1683 Section 8.3.1 1685 - Generalized the language of this section to not refer to any 1686 specific password attribute or to refer to the directory entry 1687 as a "user" entry. 1689 Section 11 1691 - Added security consideration regarding misuse of unauthenticated 1692 access. 1694 - Added security consideration requiring access control to be 1695 applied only to authenticated users and recommending it be 1696 applied when reading sensitive information or updating directory 1697 information. 1699 F.3. Changes for draft-ldap-bis-authmeth-04 1701 General 1703 - Changed references to use [RFCnnnn] format wherever possible. 1704 (References to works in progress still use [name] format.) 1706 - Various edits to correct typos and bring field names, etc. in 1707 line with specification in [Protocol] draft. 1709 - Several issues--G.13, G.14, G.16, G.17--were resolved without 1710 requiring changes to the document. 1712 Section 4.4.1. 1714 - Changed ABNF grammar to use productions that are like those in 1715 the model draft. 1717 Section 5 1719 - Removed sections 5.1, 5.2, and 5.4 that will be added to 1720 [Protocol]. Renumbered sections to accommodate this change. 1721 - 1723 Section 6 1725 - Reviewed LDAP Association State table for completeness and 1726 accuracy. Renumbered actions A3, A4, and A5 to be A5, A3, and A4 1727 respectively. Re-ordered several lines in the table to ensure 1728 that actions are in ascending order (makes analyzing the table 1729 much more logical). Added action A2 to several states where it 1730 was missing and valid. Added actions A7 and A8 placeholders to 1731 states S1, S2, S4 and S5 pending resolution of issue G.28. 1733 Section 11 1735 - Modified security consideration (originally added in -03) 1736 requiring access control to be applied only to authenticated 1737 users. This seems nonsensical because anonymous users may have 1738 access control applied to limit permissible actions. 1739 - 1740 Section 13 1742 - Verified all normative references and moved informative 1743 references to a new section 14. 1745 F.4. Changes for draft-ldap-bis-authmeth-05 1747 General 1749 - General editory changes to fix punctuation, spelling, line 1750 length issues, etc. 1751 - Verified and updated intra- and inter-document references 1752 throughout. 1753 - Document-wide review for proper usage of RFC 2119 keywords with 1754 several changes to correct improper usage. 1756 Abstract 1757 - Updated to match current contents of documents. This was needed 1758 due to movement of material on Bind and Start TLS operations to 1759 [Protocol] in this revision. 1761 Section 3. 1763 - Renamed section to "Rationale for LDAP Security Mechanisms" and 1764 removed text that did not support this theme. Part of the 1765 motivation for this change was to remove the implication of the 1766 previous section title, "Required Security Mechanisms", and 1767 other text found in the section that everything in the section 1768 was a requirement 1770 - Information from several removed paragraphs that describe 1771 deployment scenarios will be added Appendix A in the next 1772 revision of the draft. 1774 - Paragraph beginning, " If TLS is negotiated, the client MUST 1775 discard all information..." was moved to section 5.1.7 and 1776 integrated with related material there. 1778 - Paragraph beginning, "If a SASL security layer is negotiated..." 1779 was moved to section 4.2 1781 Section 4.l. 1783 - Changed wording of first paragraph to clarify meaning. 1785 Section 4.2. 1786 - Added paragraph from section 3 of -04 beginning, "If a SASL 1787 security layer is negotiated..." 1789 Section 4.3.3. 1790 - Renamed to "Other SASL Mechanisms" and completely rewrote the 1791 section (one sentence) to generalize the treatment of SASL 1792 mechanisms not explicitly mentioned in this document. 1794 Section 4.4.1. 1796 - Added paragraph beginning, "The dnAuthzID choice allows client 1797 applications..." to clarify whether DN form authorization 1798 identities have to also have a corresponding directory entry. 1799 This change was based on editor's perception of WG consensus. 1801 - Made minor clarifying edits in the paragraph beginning, "The 1802 uAuthzID choice allows for compatibility..." 1804 Section 5.1.1. 1806 - Made minor clarifying edits in the last paragraph of the 1807 section. 1809 Section 5.1.7. 1811 - Wording from section 3 paragraph beginning " If TLS is 1812 negotiated, the client MUST discard all information..." was 1813 moved to this section and integrated with existing text. 1815 Section 5.2. 1817 - Changed usage of "TLS connection" to "TLS session" throughout. 1819 - Removed empty section 5.2.1 and renumbered sections it had 1820 previously contained. 1822 Section 8. 1824 - Added introductory paragraph at beginning of section. 1826 Section 8.1. 1828 - Changed term "data privacy" to "data confidentiality" to be 1829 consistent with usage in rest of document. 1831 Section 8.2. 1833 - Changed first paragraph to require implementations that 1834 implement *password-based* authentication to implement and 1835 support DIGEST-MD5 SASL authentication. 1837 Section 11. 1839 - First paragraph: changed "session encryption" to "session 1840 confidentiality protection" to be consistent with usage in rest 1841 of document. 1843 Appendix A. 1845 - Began changes to incorporate information on deployment scenarios 1846 removed from section 3. 1848 F.5. Changes for draft-ldap-bis-authmeth-06 1850 General 1852 - Combined Section 2 (Introduction) and Section 3 (Motivation) and 1853 moved Introduction to section 1. All following sections numbers 1854 were decremented by one as result. 1856 - Edits to fix typos, I-D nits, etc. 1858 - Opened several new issues in Appendix G based on feedback from 1859 WG. Some of these have been resolved. Others require further 1860 discussion. 1862 Section 1 1863 - Added additional example of spoofing under threat (7). 1865 Section 2.1 1867 - Changed definition of "LDAP association" and added terms, 1868 "connection" and "TLS connection" to bring usage in line with 1869 [Protocol]. 1871 Section 4.1.6 1873 - Clarified sentence stating that the client MUST NOT use derived 1874 forms of DNS names. 1876 Section 5.1 1878 - Began edits to LDAP Association state table to clarify meaning 1879 of various states and actions. 1881 - Added action A9 to cover abandoned bind operation and added 1882 appropriate transitions to the state transition table to 1883 accommodate it. 1885 Section 7.2 1887 - Replaced first paragraph to clarify that the "DIGEST-MD5" SASL 1888 mechanism is required to implement. 1890 Section 9 1892 - Rewrote the section to make the advice more applicable over the 1893 long term, i.e. more "timeless." The intent of content in the 1894 original section was preserved. 1896 Section 10 1898 - Added a clarifying example to the consideration regarding misuse 1899 of unauthenticated access. 1901 F.6. Changes for draft-ldap-bis-authmeth-07 1903 General 1905 - Updated external and internal references to accommodate changes 1906 in recent drafts. 1908 - Opened several new issues in Appendix G based on feedback from 1909 WG. Some of these have been resolved. Others require further 1910 discussion. 1912 Section 3 1914 - Rewrote much of section 3.3 to meet the SASL profile 1915 requirements of draft-ietf-sasl-rfc2222bis-xx.txt section 5. 1917 - Changed treatement of SASL ANONYMOUS and PLAIN mechanisms to 1918 bring in line with WG consensus. 1920 Section 4 1922 - Note to implementers in section 4.1.1 based on operational 1923 experience. 1925 - Clarification on client continuing by performing a Start TLS 1926 with TLS already established in section 4.1.4. 1928 - Moved verification of mapping of client's authentication ID to 1929 asserted authorization ID to apply only to explicit assertion. 1930 The local policy in place for implicit assertion is adequate. 1932 Section 7 1934 - Removed most of section 7.2 as the information is now covered 1935 adequately via the new SASL profile in section 3.3. Added note 1936 to implementors regarding the treatment of username and realm 1937 values in DIGEST-MD5. 1939 - Section 7.3. Minor clarifications in wording. 1941 - Section 7.3.1. Clarification that a match of the presented value 1942 to any member of the set of stored passwords constitutes a 1943 successful authentication. 1945 F.6. Changes for draft-ldap-bis-authmeth-08 1947 General 1949 - Changed usage from LDAPv3 to LDAP for usage consistency across 1950 LDAP technical specification. 1952 - Fixed a number of usage nits for consistency and to bring doc in 1953 conformance with publication guidelines. 1955 Abstract 1957 - Significant cleanup and rewording of abstract based on WG 1958 feedback. 1960 Section 2.1 1962 - New definition of user. 1964 Section 3 1966 - Added 1.5 sentences at end of introductory paragraph indicating 1967 the effect of the Bind op on the LDAP association. 1969 Section 3.1 1971 - Retitled section and clarified wording 1973 Section 3.2 1975 - Clarified that simple authentication choice provides three types 1976 of authentication: anonymous, unauthenticated, and simple 1977 password. 1979 Section 3.3.3 1981 - New wording clarifying when negotiated security mechanisms take 1982 effect. 1984 Section 3.3.5 1986 - Changed requirement to discard information about server fetched 1987 prior to SASL negotiation from MUST to SHOULD to allow for 1988 information obtained through secure mechanisms. 1990 Section 3.3.6 1992 - Simplified wording of first paragraph based on suggestion from 1993 WG. 1995 Section 3.4 1997 - Minor clarifications in wording. 1999 Section 3.4.1 2001 - Minor clarifications in wording in first sentence. 2002 - Explicitly called out that the DN value in the dnAuthzID form is 2003 to be matched using DN matching rules. 2004 - Called out that the uAuthzID MUST be prepared using SASLprep 2005 rules before being compared. 2006 - Clarified requirement on assuming global uniqueness by changing 2007 a "generally... MUST" wording to "SHOULD". 2009 Section 4.1.1 2011 - Simplified wording describing conditions when Start TLS cannot 2012 be sent. 2013 - Simplified wording in note to implementers regarding race 2014 condition with outstanding LDAP operations on connection. 2016 Section 4.1.5 2018 - Removed section and moved relevant text to section 4.2.2. 2020 Section 4.1.6 2022 - Renumbered to 4.1.5. 2024 - Updated server identity check rules for server's name based on 2025 WG list discussion. 2027 Section 4.1.7 2029 - Renumbered to 4.1.6 2030 - Changed requirement to discard information about server fetched 2031 prior to TLS negotion from MUST to SHOULD to allow for 2032 information obtained through secure mechanisms. 2034 Section 6.1 2036 - Clarified wording. 2037 - Added definition of anonymous and unauthenticated binds. 2039 Section 10 2041 - Added security consideration (moved from elsewhere) discouraging 2042 use of cleartext passwords on unprotected communication 2043 channels. 2045 Section 11 2047 - Added an IANA consideration to update GSSAPI service name 2048 registry to point to [Roadmap] and [Authmeth] 2050 F.7. Changes for draft-ldap-bis-authmeth-09 2052 General 2054 - Updated section references within document 2055 - Changed reference tags to match other docs in LDAP TS 2056 - Used non-quoted names for all SAL mechanisms 2058 Abstract 2060 - Inspected keyword usage and removed several improper usages. 2062 - Removed sentence saying DIGEST-MD5 is LDAP's mandatory-to- 2063 implement mechanism. This is covered elsewhere in document. 2065 - Moved section 5, authentication state table, of -08 draft to 2066 section 8 of -09 and completely rewrote it. 2068 Section 1 2070 - Reworded sentence beginning, "It is also desireable to allow 2071 authentication methods to carry identities based on existing� 2072 non-LDAP DN�forms..." 2073 - Clarified relationship of this document to other documents in 2074 the LDAP TS. 2076 Section 3.3.5 2077 - Removed paragraph beginning,"If the client is configured to 2078 support multiple SASL mechanisms..." because the actions 2079 specified in the paragraph do not provide the protections 2080 indicated. Added a new paragraph indicating that clients and 2081 server should allow specification of acceptable mechanisms and 2082 only allow those mechanisms to be used. 2084 - Clarified independent behavior when TLS and SASL security layers 2085 are both in force (e.g. one being removed doesn't affect the 2086 other). 2088 Section 3.3.6 2090 - Moved most of section 4.2.2, Client Assertion of Authorization 2091 Identity, to sections 3.3.6, 3.3.6.1, and 3.3.6.2. 2093 Section 3.3.6.4 2095 - Moved some normative comments into text body. 2097 Section 4.1.2 2099 - Non success resultCode values are valid if server is *unwilling* 2100 or unable to negotiate TLS. 2102 Section 4.2.1 2104 - Rewrote entire section based on WG feedback. 2106 Section 4.2.2 2108 - Moved most of this section to 3.3.6 for better document flow. 2110 Section 4.2.3 2112 - Rewrote entire section based on WG feedback. 2114 Section 5.1 2116 - Moved imperative language regarding unauthenticated access from 2117 security considerations to here. 2119 Section 6 2121 - Added several paragraphs regarding the risks of transmitting 2122 passwords in the clear and requiring server implementations to 2123 provide a specific configuration that reduces these risks. 2125 Section 6.2 2127 - Added sentence describing protections provided by DIGEST-MD5 2128 method. 2129 - Changed DNs in exmple to be dc=example,dc=com. 2131 Section 10 2133 - Updated consideration on use of cleartext passwords to include 2134 other unprotected authentication credentials 2135 - Substantial rework of consideration on misuse of unauthenticated 2136 bind. 2138 Appendix G. Issues to be Resolved 2140 This appendix lists open questions and issues that need to be 2141 resolved before work on this document is deemed complete. 2143 G.1. 2145 Section 1 lists 6 security mechanisms that can be used by LDAP 2146 servers. I'm not sure what mechanism 5, "Resource limitation by 2147 means of administrative limits on service controls" means. 2149 Status: resolved. Changed wording to "administrative service limits" 2150 to clarify meaning. 2152 G.2. 2154 Section 2 paragraph 1 defines the term, "sensitive." Do we want to 2155 bring this term and other security-related terms in alignment with 2156 usage with the IETF security glossary (RFC 2828)? 2158 Status: resolved. WG input at IETF 51 was that we should do this, so 2159 the appropriate changes have been made. 2161 G.3. 2163 Section 2, deployment scenario 2: What is meant by the term "secure 2164 authentication function?" 2166 Status: resolved. Based on the idea that a "secure authentication 2167 function" could be provided by TLS, I changed the wording to require 2168 data confidentiality for sensitive authentication information and 2169 data integrity for all authentication information. 2171 G.4. 2173 Section 3, deployment scenario 3: What is meant by the phrase, 2174 "directory data is authenticated by the server?" 2176 Status: resolved. I interpreted this to mean the ability to ensure 2177 the identity of the directory server and the integrity of the data 2178 sent from that server to the client, and explictly stated such. 2180 G.5. 2182 Section 4 paragraph 3: What is meant by the phrase, "this means that 2183 either this data is useless for faking authentication (like the Unix 2184 "/etc/passwd" file format used to be)?" 2186 Status: resolved. Discussion at IETF 52 along with discussions with 2187 the original authors of this material have convinced us that this 2188 reference is simply too arcane to be left in place. In -03 the text 2189 has been modified to focus on the need to either update password 2190 information in a protected fashion outside of the protocol or to 2191 update it in session well protected against snooping, and the 2192 reference to /etc/passwd has been removed. 2194 G.6. 2196 Section 4 paragraph 7 begins: "For a directory needing session 2197 protection..." Is this referring to data confidentiality or data 2198 integrity or both? 2200 Status: resolved. Changed wording to say, "For a directory needing 2201 data security (both data integrity and data confidentiality)..." 2203 G.7. 2205 Section 4 paragraph 8 indicates that "information about the server 2206 fetched prior to the TLS negotiation" must be discarded. Do we want 2207 to explicitly state that this applies to information fetched prior 2208 to the *completion* of the TLS negotiation or is this going too far? 2210 Status: resolved. Based on comments in the IETF 51 LDAPBIS WG 2211 meeting, this has been changed to explicitly state, "fetched prior 2212 to the initiation of the TLS negotiation..." 2214 G.8. 2216 Section 4 paragraph 9 indicates that clients SHOULD check the 2217 supportedSASLMechanisms list both before and after a SASL security 2218 layer is negotiated to ensure that they are using the best available 2219 security mechanism supported mutually by the client and server. A 2220 note at the end of the paragraph indicates that this is a SHOULD 2221 since there are environments where the client might get a list of 2222 supported SASL mechanisms from a different trusted source. 2224 I wonder if the intent of this could be restated more plainly using 2225 one of these two approaches (I've paraphrased for the sake of 2226 brevity): 2228 Approach 1: Clients SHOULD check the supportedSASLMechanisms 2229 list both before and after SASL negotiation or clients SHOULD 2230 use a different trusted source to determine available supported 2231 SASL mechanisms. 2233 Approach 2: Clients MUST check the supportedSASLMechanisms list 2234 both before and after SASL negotiation UNLESS they use a 2235 different trusted source to determine available supported SASL 2236 mechanisms. 2238 Status: resolved. WG input at IETF 51 was that Approach 1 was 2239 probably best. I ended up keeping the basic structure similar to the 2240 original to meet this intent. 2242 G.9. 2244 Section 6.3.1 states: "DSAs that map the DN sent in the bind request 2245 to a directory entry with a userPassword attribute will... compare 2246 [each value in the named user's entry]... with the presented 2247 password." This implies that this applies only to user entries with 2248 userPassword attributes. What about other types of entries that 2249 might allow passwords and might store in the password information in 2250 other attributes? Do we want to make this text more general? 2252 Status: resolved in -03 draft by generalizing section 8.3.1 to not 2253 refer to any specific password attribute and by removing the term 2254 "user" in referring to the directory entry specified by the DN in 2255 the bind request. 2257 G.10 userPassword and simple bind 2259 We need to be sure that we don't require userPassword to be the only 2260 attribute used for authenticating via simple bind. (See 2251 sec 4.2 2261 and authmeth 6.3.1. Work with Jim Sermersheim on resolution to this. 2262 On publication state something like: "This is the specific 2263 implementation of what we discussed in our general reorg 2264 conversation on the list." (Source: Kurt Zeilenga) 2266 Status: resolved in -03 draft by generalizing section 8.3.1 to not 2267 refer to any specific password attribute and by removing the term 2268 "user" in referring to the directory entry specified by the DN in 2269 the bind request. 2271 G.11. Meaning of LDAP Association 2273 The original RFC 2830 uses the term "LDAP association" in describing 2274 a connection between an LDAP client and server regardless of the 2275 state of TLS on that connection. This term needs to be defined or 2276 possibly changed. 2278 Status: resolved. at IETF 51 Bob Morgan indicated that the term 2279 "LDAP association" was intended to distinguish the LDAP-level 2280 connection from the TLS-level connection. This still needs to be 2281 clarified somewhere in the draft. Added "LDAP association" to a 2282 glossary in section 1. 2284 G.12. Is DIGEST-MD5 mandatory for all implementations? 2286 Reading 2829bis I think DIGEST-MD5 is mandatory ONLY IF your server 2287 supports password based authentication...but the following makes it 2288 sound mandatory to provide BOTH password authentication AND DIGEST- 2289 MD5: 2291 "6.2. Digest authentication 2293 LDAP implementations MUST support authentication with a password 2294 using the DIGEST-MD5 SASL mechanism for password protection, as 2295 defined in section 6.1." 2297 The thing is for acl it would be nice (though not critical) to be 2298 able to default the required authentication level for a subject to a 2299 single "fairly secure" mechanism--if there is no such mandatory 2300 authentication scheme then you cannot do that. (Source: Rob Byrne) 2302 Status: resolved. -00 version of the draft added a sentence at the 2303 beginning of section 8.2 stating that LDAP server implementations 2304 must support this method. 2306 G.13. Ordering of authentication levels requested 2308 Again on the subject of authentication level, is it possible to 2309 define an ordering on authentication levels which defines their 2310 relative "strengths" ? This would be useful in acl as you could say 2311 things like"a given aci grants access to a given subject at this 2312 authentication level AND ABOVE". David Chadwick raised this before 2313 in the context of denying access to a subject at a given 2314 authentication level, in which case he wanted to express "deny 2315 access to this subject at this authentication level AND TO ALL 2316 IDENTITIES AUTHENTICATED BELOW THAT LEVEL". (Source: Rob Byrne) 2318 Status: out of scope. This is outside the scope of this document and 2319 will not be addressed. 2321 G.14. Document vulnerabilities of various mechanisms 2323 While I'm here...in 2829, I think it would be good to have some 2324 comments or explicit reference to a place where the security 2325 properties of the particular mandatory authentication schemes are 2326 outlined. When I say "security properties" I mean stuff like "This 2327 scheme is vulnerable to such and such attacks, is only safe if the 2328 key size is > 50, this hash is widely considered the best, etc...". 2329 I think an LDAP implementor is likely to be interested in that 2330 information, without having to wade through the security RFCs. 2331 (Source: Rob Byrne) 2333 Status: out of scope. This is outside the scope of this document and 2334 will not be addressed. 2336 G.15. Include a Start TLS state transition table 2338 The pictoral representation it is nominally based on is here (URL 2339 possibly folded): 2341 http://www.stanford.edu/~hodges/doc/LDAPAssociationStateDiagram- 2342 1999-12-14.html 2343 (Source: Jeff Hodges) 2345 Status: Resolved. 2347 Table provided in -03. Review of content for accuracy in -04. 2348 Additional review is needed, plus comments from WG members indicate 2349 that additional description of each state's meaning would be 2350 helpful. 2352 Did a significant revision of state transition table in -09. Changes 2353 were based on suggestions from WG and greatly simplified overall 2354 table. 2356 G.16. Empty sasl credentials question 2358 I spent some more time looking microscopically at ldap-auth-methods 2359 and ldap-ext-tls drafts. The drafts say that the credential must 2360 have the form dn:xxx or u:xxx or be absent, and although they don't 2361 say what to do in the case of an empty octet string I would say that 2362 we could send protocolError (claim it is a bad PDU). 2364 There is still the question of what to do if the credential is 'dn:' 2365 (or 'u:') followed by the empty string. (Source: ariel@columbia.edu 2366 via Jeff Hodges) 2368 Status: resolved. Kurt Zeilenga indicated during ldapbis WG 2369 discussion at IETF 52 that SASL AuthzID credentials empty and absent 2370 are equivalent in the latest SASL ID. This resolves the issue. 2372 G.17. Hostname check from MUST to SHOULD? 2374 I am uneasy about the hostname check. My experience from PKI with 2375 HTTP probably is a contributing factor; we have people using the 2376 short hostname to get to a server which naturally has the FQDN in 2377 the certificate, no end of problems. I have a certificate on my 2378 laptop which has the FQDN for the casse when the system is on our 2379 Columbia network with a fixed IP; when I dial in however, I have 2380 some horrible dialup name, and using the local https server becomes 2381 annoying. Issuing a certificate in the name 'localhost' is not a 2382 solution! Wildcard match does not solve this problem. For these 2383 reasons I am inclined to argue for 'SHOULD' instead of 2384 'MUST' in paragraph... 2386 Also, The hostname check against the name in the certificate is a 2387 very weak means of preventing man-in-the-middle attacks; the proper 2388 solution is not here yet (SecureDNS or some equivalent). Faking out 2389 DNS is not so hard, and we see this sort of thing in the press on a 2390 pretty regular basis, where site A hijacks the DNS server for site B 2391 and gets all their requests. Some mention of this should be made in 2392 the draft. (Source: ariel@columbia.edu via Jeff Hodges) 2394 Status: resolved. Based on discussion at IETF 52 ldapbis WG meeting, 2395 this text will stand as it is. The check is a MUST, but the behavior 2396 afterward is a SHOULD. This gives server implementations the room to 2397 maneuver as needed. 2399 G.18. Must SASL DN exist in the directory? 2401 If the 'dn:' form of sasl creds is used, is it the intention of the 2402 draft(ers) that this DN must exist in the directory and the client 2403 will have the privileges associated with that entry, or can the 2404 server map the sasl DN to perhaps some other DN in the directory, 2405 in an implementation-dependent fashion? 2407 We already know that if *no* sasl credentials are presented, the DN 2408 or altname in the client certificate may be mapped to a DN in an 2409 implementation-dependent fashion, or indeed to something not in the 2410 directory at all. (Right?) (Source: ariel@columbia.edu via Jeff 2411 Hodges) 2413 Status: resolved. (11/12/02)Based on my research I propose that the 2414 DN MUST exist in the directory when the DN form of sasl creds is 2415 used. I have made this proposal to the ldapbis mailing list. 2417 (11/21/02) Feedback from mailing list has proposed removing this 2418 paragraph entirely because (1) explicit assertion of authorization 2419 identity should only be done when proxying (2) mapping of the 2420 asserted authorization identity is implementation specific and 2421 policy driven [SASL] section 4.2, and (3) keeping this paragraph is 2422 not required for interoperability. 2424 G.19. DN used in conjunction with SASL mechanism 2426 We need to specify whether the DN field in Bind operation can/cannot 2427 be used when SASL mechanism is specified. (source: RL Bob) 2429 Status: resolved. (-03) Based on ldapbis WG discussion at IETF52 two 2430 sentences were added to section 4.3 indicating that clients SHOULD 2431 NOT send a DN value when binding with the sasl choice and servers 2432 SHALL ignore any value received in this circumstance. During edits 2433 for -04 version of draft it was noted that [Protocol] section 4.2 2434 conflicts with this draft. The editor of [Protocol] has been 2435 notified of the discrepancy, and they have been handled. 2437 G.20. Bind states 2439 Differences between unauthenticated and anonymous. There are four 2440 states you can get into. One is completely undefined (this is now 2441 explicitly called out in [Protocol]). This text needs to be moved 2442 from [Protocol] to this draft. (source: Jim Sermersheim) 2444 Status: Resolved. There are four states: (1) no name, no password 2445 (anon); (2) name, no password (anon); (3) no name, password 2446 (invalid); (4) name, password (simple bind). States 1, 2, and 4 are 2447 called out in [AuthMeth]. State 3 is called out in [Protocol]; this 2448 seems appropriate based on review of alternatives. 2450 G.21. Misuse of unauthenticated access 2452 Add a security consideration that operational experience shows that 2453 clients can misuse unauthenticated access (simple bind with name but 2454 no password). Servers SHOULD by default reject authentication 2455 requests that have a DN with an empty password with an error of 2456 invalidCredentials. (Source: Kurt Zeilenga and Chris Newman (Sun)) 2458 Status: Resolved. Added to security considerations in -03. 2460 G.22. Need to move Start TLS protocol information to [Protocol] 2462 Status: Resolved. Removed Sections 5.1, 5.2, and 5.4 for -04 and 2463 they are [Protocol] -11. 2465 G.23. Split Normative and Non-normative references into separate 2466 sections. 2468 Status: Resolved. Changes made in -04 2470 G.24. What is the authentication state if a Bind operation is 2471 abandoned? 2473 Status: Resolved. 2475 (3/24/03) This following text appears in section 4.2.1 of [Protocol] 2476 revision -13 to cover what happens if a bind operation is abandoned: 2478 A failed or abandoned Bind Operation has the effect of leaving the 2479 connection in an anonymous state. To arrive at a known 2480 authentication state after abandoning a bind operation, clients may 2481 unbind, rebind, or make use of the BindResponse. 2483 (6/28/03): The state table in section 6 of [AuthMeth] has been 2484 updated to reflect this wording. 2486 G.25. Difference between checking server hostname and server's 2487 canonical DNS name in Server Identity Check? 2489 Section 4.1.6: I now understand the intent of the check (prevent 2490 man-in-the-middle attacks). But what is the subtle difference 2491 between the "server hostname" and the "server's canonical DNS name"? 2492 (Source: Tim Hahn) 2494 Status: Resolved. 2496 (11/12/02) Sent suggested wording change to this paragraph to the 2497 ldapbis mail list and also asked for opinion as to whether we should 2498 discuss the distinction between server DNS hostname and server 2499 canonical DNS hostname in [AuthMeth]. 2501 (11/21/02): RL Bob Morgan will provide wording that allows 2502 derivations of the name that are provided securely. 2504 (6/28/03): posted to the WG list asking Bob or any other WG member 2505 who is knowledgeable about the issues involved to help me with 2506 wording or other information I can use to make this change and close 2507 the work item. 2509 (10/08/03): Based on WG list feedback, I've updated this text to 2510 read what I judge to be the WG consensus, "The client MUST use the 2511 server provided by the user (or other trusted entity) as the value 2512 to compare against the server name as expressed in the server's 2513 certificate. A hostname derived from the user input is to be 2514 considered provided by the user only if derived in a secure fashion 2515 (e.g., DNSSEC)." 2517 G.26. Server Identity Check using servers located via SRV records 2519 Section 4.1.6: What should be done if the server was found using SRV 2520 records based on the "locate" draft/RFC? (Source: Tim Hahn). 2522 Status: Resolved. Section 5 of draft-ietf-ldapext-locate-08 2523 specifically calls out how the server identity should be performed 2524 if the server is located using the method defined in that draft. 2525 This is the right location for this information, and the coverage 2526 appears to be adequate. 2528 G.27 Inconsistency in effect of TLS closure on LDAP association. 2530 Section 4.4.1 of authmeth -03 (section 4.1 of RFC2830) states that 2531 TLS closure alert will leave the LDAP association intact. Contrast 2532 this with Section 4.5.2 (section 5.2 of RFC2830) that says that the 2533 closure of the TLS connection MUST cause the LDAP association to 2534 move to an anonymous authentication. 2536 Status: Resolved. (11/12/02) This is actually a [Protocol] issue 2537 because these sections have now been moved to [Protocol] -11. I have 2538 proposed the following text for Section 4.4.1 of [AuthMeth] -03 2539 (section 4.13.3.1 of [Protocol]) to resolve this apparent 2540 discrepancy: 2542 "Either the client or server MAY terminate the TLS connection on an 2543 LDAP association by sending a TLS closure alert. The LDAP 2544 connection remains open for further communication after TLS closure 2545 occurs although the authentication state of the LDAP connection is 2546 affected (see [AuthMeth] section 4.2.2). 2548 (11/21/02): resolution to this is expected in [Protocol] -12 2550 (06/28/03): [Protocol]-15 clarifies that a TLS closure alert 2551 terminates the TLS connection while leaving the LDAP connection 2552 intact. The authentication state table in [AuthMeth] specifies the 2553 effect on the LDAP association. 2555 G.28 Ordering of external sources of authorization identities 2556 Section 4.3.2 implies that external sources of authorization 2557 identities other than TLS are permitted. What is the behavior when 2558 two external sources of authentication credentials are available 2559 (e.g. TLS and IPsec are both present (is this possible?)) and a SASL 2560 EXTERNAL Bind operation is performed? 2562 Status: resolved. 11/20/02: Resolved by Section 4.2 of [SASL] which 2563 states that the decision to allow or disallow the asserted identity 2564 is based on an implementation defined policy. 2566 G.29 Rewrite of Section 9, TLS Ciphersuites 2568 This section contains anachronistic references and needs to be 2569 updated/rewritten in a way that provides useful guidance for future 2570 readers in a way that will transcend the passage of time. 2572 Status: Resolved. (6/28/03): Rewrote the section to cover the 2573 general issues and considerations involved in selecting TLS 2574 ciphersuites. 2576 G.30 Update to Appendix A, Example Deployment Scenarios 2578 This section needs to be updated to indicate which security 2579 mechanisms and/or combinations of security mechanisms described 2580 elsewhere in the document can provide the types of protections 2581 suggested in this appendix. 2583 G.31 Use of PLAIN SASL Mechanism 2585 At least one LDAP server implementer has found the SASL "PLAIN" 2586 mechanism useful in authenticating to legacy systems that do not 2587 represent authentication identities as DNs. Section 3.3.1 appears to 2588 implicitly disallow the use of the SASL "PLAIN" mechanism with LDAP. 2589 Should we allow the use of this mechanism? I.e. is this "SASL" 2590 "PLAIN" MUST NOT be used with LDAP, or is it simply that LDAP 2591 doesn't define bindings for these mechanism. If SASL "PLAIN" is 2592 allowed, the following adjustments will be needed to section 3.3.1: 2593 (a) change section heading, (b) remove reference to "PLAIN" in the 2594 section, (c) ensure wording of last sentence regarding non-DN 2595 AuthZIDs is consistent with rest of the section. 2597 Status: Resolved. 2599 (6/28/03): email to WG list stating issue and asking if we should 2600 remove the reference to SASL "PLAIN". 2602 For -07 draft I've generalized the SASL profile in section 3.3 to 2603 allow any SASL mechanism. 2605 G.32 Clarification on use of SASL mechanisms 2607 Section 3.3.1: BTW, what _are_ the "ANONYMOUS" and "PLAIN" SASL 2608 mechanisms? They are not defined in RFC2222. If you refer to other 2609 SASL mechanisms than those in rfc2222, Maybe you should only list 2610 which mechanisms _are_used, instead of which ones are _not. (Source: 2611 Hallvard Furuseth) 2613 I (Kurt Zeilenga) note[s] as well that the ANONYMOUS/PLAIN section 2614 (4.2) should 2615 be deleted. ANONYMOUS and PLAIN, like in other mechanism, 2616 can be used in LDAP if a) supported and b) enabled. I note 2617 that they each offer capabilities not found in their simple 2618 bind equivalents (and hence are used in some deployments). 2619 For example, PLAIN (over TLS) is quite useful when interacting 2620 with legacy authentication subsystems. (Source: Kurt Zeilenga) 2622 Status: Resolved. 2624 For -07 draft I've generalized the SASL profile in section 3.3 to 2625 allow any SASL mechanism. 2627 G.33 Clarification on use of password protection based on AuthZID form 2629 Section 3.3.1: "If an authorization identity of a form different 2630 from a DN is requested by the client, a mechanism that protects the 2631 password in transit SHOULD be used." What has that to do with DNs? 2632 A mechanism that protects the password in transit should be used in 2633 any case, shouldn't it? 2635 Status: Resolved. 2637 In -08 draft this text was removed. There is already a general 2638 security consideration that covers this issue. 2640 G.34 Clarification on use of matching rules in Server Identity Check 2642 The text in section 4.1.6 isn't explicit on whether all rules apply 2643 to both CN and dNSName values. The text should be clear as to which 2644 rules apply to which values.... in particular, the wildcard 2645 rules. (Source: Kurt Zeilenga) 2647 G.35 Requested Additions to Security Considerations 2649 Requested to mention hostile servers which the user might have been 2650 fooled to into contacting. Which mechanisms that are standardized by 2651 the LDAP standard do/do not disclose the user's password to the 2652 server? (Or to servers doing man-in-the-middle attack? Or is that a 2653 stupid question?) 2655 Requested to mention denial of service attacks. 2657 Requested list of methods that need/don't need the server to know 2658 the user's plaintext password. (I say 'know' instead of 'store' 2659 because it could still store the password encrypted, but in a way 2660 which it knows how to decrypt.) 2662 (Source: Hallvard Furuseth) 2664 G.36 Add reference to definition of DIGEST-MD5 2666 Need a reference to the definition of DIGEST-MD5 SASL mechanism in 2667 section 7.2 (Source: Hallvard Furuseth) 2669 Status: Resolved. A reference to to the DIGEST-MD5 SASL mechanism, 2670 [DigestAuth], is included in the -07 revision. 2672 G.37 Clarification on procedure for certificate-based authentication 2674 8.1. Certificate-based authentication with TLS states: "Following 2675 the successful completion of TLS negotiation, the client will send 2676 an LDAP bind request with the SASL "EXTERNAL" mechanism." Is this 2677 immediately following, or just some time later? Should the wording, 2678 "the client will send..." actually read, "the client MUST send..."? 2680 G.38 Effect of Start TLS on authentication state 2682 Should the server drop all knowledge of connection, i.e. return to 2683 anonymous state, if it gets a Start TLS request on a connection that 2684 has successfully bound using the simple method? 2686 G.39 Be sure that there is a consideration in [SCHEMA] that discusses 2687 multiple password values in userPassword 2689 Allowing multiple values obviously does raise a number of security 2690 considerations and these need to be discussed in the document. 2692 Certainly applications which intend to replace the userPassword with 2693 new value(s) should use modify/replaceValues (or 2694 modify/deleteAttribute+addAttribute). Additionally, server 2695 implementations should be encouraged to provide administrative 2696 controls which, if enabled, restrict userPassword to one value. 2698 G.40. Clarify need to verify mapping between authentication identity 2699 and resulting authorization identity on implicit assertion of AuthZID. 2701 4.2.2.3. Error Conditions 2703 "For either form of assertion, the server MUST verify that the 2704 client's authentication identity as supplied in its TLS credentials 2705 is permitted to be mapped to the asserted authorization identity." 2707 This makes sense for the explicit assertion case, but seems to be 2708 ambiguous for the implicit case. 2709 IMHO, the mapping can be done as two steps: 2710 a). deriving LDAP authentication identity from TLS credentials; If t 2711 this steps fails, EXTERNAL mechanism returns failure. 2713 b). verify that the authorization identity is allowed for the 2714 derived authentication identity. This is always "noop" for the 2715 implicit case. 2716 I am not sure that the text is saying this. 2717 (Source: Alexey Melnikov email 8/1/2003 5:30:43 PM) 2719 Status: Resolved in -07. After reading the comments and the text of 2720 the draft, I believe that this should be clarified. The local policy 2721 used to map the AuthNID to the AuthZID in the implicit case is 2722 sufficient and that no additional verification is useful or needed. 2723 This text has been moved to apply only to the explicit assertion 2724 case. 2726 G.41. Section 7.2 contains unnecessary and misleading detail. 2728 " I am not sure why this section is required in the document. 2729 DIGEST-MD5 is defined in a separate document and there should be 2730 nothing magical about its usage in LDAP. If DIGEST-MD5 description 2731 creates confusion for LDAP implementors, let's fix the DIGEST-MD5 2732 document! Also, this section tries to redefine DIGEST-MD5 behavior, 2733 which is explicitly prohibited by the SASL specification." 2734 (Source: Alexey Melnikov: email 8/1/2003 5:30:43 PM) 2736 Status: Resolved. 2738 After reading the comments and the text of the draft plus the 2739 related text in draft-ietf-sasl-rfc2831bis-02.txt plus 2740 http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis- 2741 02.txt, I am inclined to agree with Alexey. In -07 I rewrote section 2742 3.3 (SASL mechanisms) to match the profiling requirements 2743 rfc2831bis. I then dramatically reduced the material in section 7.2 2744 to a bare minimum and let the SASL profile stand on its own. 2746 G.42. Does change for G.41 cause interoperability issue? 2748 There is one issue with the way the authmeth draft is currently 2749 written that changes the SASL DIGEST-MD5 behavior on the way the 2750 server responds with the subsequent authentication information . 2751 This has been documented in this fashion since RFC 2829 (section 2752 6.1) was originally published and may cause an interoperability 2753 issue at this point if it changed to follow the DIGEST-MD5 spec (as 2754 it was in -07 of AuthMeth). Take this issue to the list. 2756 Status: Resolved 2758 (10/08/03) This item was discussed on the WG list between 5/2/03 and 2759 5/9/03. Consensus apppears to support the notion that RFC 2829 was 2760 in error and that the semantics of RFC 2831 are correct and should 2761 be reflected in authmeth. This is already the case as of the -07 2762 draft. 2764 G.43. DIGEST-MD5 Realms recommendations for LDAP 2765 From http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis- 2766 02.txt: A protocol profile SHOULD provide a guidance how realms are 2767 to be constructed and used in the protocol and MAY further restrict 2768 its syntax and protocol-specific semantics." 2770 I don't believe that any such guidance exists within the LDAP TS. 2771 The most likely place for this to reside is in the authmeth draft. 2773 Related email from Alexey Melnikov (8/4/2003 1:08:40 PM): 2775 "The problem I have with the document is that it references realm 2776 without explaining what it is (or at least some examples of valid 2777 values). For LDAP, some recommendations should be given. For 2778 example: 2779 1). Use a hardcoded string as the realm (one of the implementations 2780 I worked on was doing that) 2781 2). Use hostname (realm==host) or domain/cluster name (realm 2782 includes multiple hosts). 2783 3). Use a node in DIT above user entry, for example for "cn=Barbara 2784 Jensen, ou=Accounting, o=Ace Industry, c=US" 2785 and "cn=John Doe, ou=Accounting, o=Ace Industry, c=US" realm can be 2786 "ou=Accounting, o=Ace Industry, c=US" 2787 (or "o=Ace Industry, c=US"); for "cn=Gern Jensen, ou=Product 2788 Testing,o=Ace Industry, c=US" realm can be "ou=Product Testing, 2789 o=Ace Industry, c=US". 2791 Of course other choices are possible. 2793 Alexey 2795 To summarize: I'd like authmeth to define a realm name for use with 2796 Digest-MD5 that corresponds to LDAP DNs known to this server. 2797 Authzid is okay, but perhaps could be better put into context. 2799 John McMeeking (5/12/2003) 2801 Status: Resolved. 2803 draft-ietf-sasl-rfc2222bis-03.txt no longer requires this 2804 information in a SASL protocol. In addition, the ldapbis WG chairs 2805 have ruled this work out of scope. Individuals are welcome to make 2806 submissions to provide guidance on the use of realm and realm values 2807 in LDAP. 2809 G.44. Use of DNs in usernames and realms in DIGEST-MD5 2811 In reading the discussion on the mailing list, I reach the following 2812 conclusions: 2814 DIGEST-MD5 username and realm are simple strings. The syntax of 2815 these strings allows strings that look like DNs in form, however, 2816 DIGEST-MD5 treats them a simple strings for comparision purposes. 2817 For example, the DNs cn=roger, o=US and cn=roger,o=us are equivalent 2818 when being compared semantically as DNs, however, these would be 2819 considered two different username values in DIGEST-MD5 because 2820 simple octet-wise semantics (rather than DN semantics) are used to 2821 compare username values in DIGEST-MD5. Ditto for realm values. 2823 Status: Resolved. 2825 In -07 revision I added notes to implementors expressing this issue 2826 in section 7.2. 2828 G.45: Open Issue: Is Simple+TLS mandatory to implement? 2830 Going forward, it would be much better to clarify that simple 2831 +TLS is to be used for DN/password credentials and DIGEST-MD5 2832 (or PLAIN+TLS) be used for username/password credentials. (Kurt 2833 Zeilenga, 5/12/2003) 2835 I don't believe you can mandate simple/TLS! At the time RFC 2829 was 2836 debated, a large number on the WG wanted this. They did not get 2837 their way because of the complexity of the solution. It was argued 2838 that a password-based method would be better. I think they believed 2839 it would still be DN/password, though. (Ron Ramsay, 5/12/2003) 2841 This was officially opened as an issue by WG co-chair Kurt Zeilenga 2842 on 5/12/03. Little direct discussion has occurred since, however 2843 there has been significant discussion on the use of DN values as the 2844 username for DIGEST-MD5. 2846 Status: Resolved. 2848 Based on WG list discussion, Kurt Zeilenga has gaged a lack of WG 2849 consensus that Simple+TLS should be mandatory to implement. No 2850 further discussion is necessary. 2852 Intellectual Property Rights 2854 The IETF takes no position regarding the validity or scope of any 2855 intellectual property or other rights that might be claimed to 2856 pertain to the implementation or use of the technology described in 2857 this document or the extent to which any license under such rights 2858 might or might not be available; neither does it represent that it 2859 has made any effort to identify any such rights. Information on the 2860 IETF's procedures with respect to rights in standards-track and 2861 standards-related documentation can be found in BCP-11. Copies of 2862 claims of rights made available for publication and any assurances 2863 of licenses to be made available, or the result of an attempt made 2864 to obtain a general license or permission for the use of such 2865 proprietary rights by implementors or users of this specification 2866 can be obtained from the IETF Secretariat. 2868 The IETF invites any interested party to bring to its attention any 2869 copyrights, patents or patent applications, or other proprietary 2870 rights which may cover technology that may be required to practice 2871 this standard. Please address the information to the IETF Executive 2872 Director. 2874 Full Copyright 2876 Copyright (C) The Internet Society (2003). All Rights Reserved. 2878 This document and translations of it may be copied and furnished to 2879 others, and derivative works that comment on or otherwise explain it 2880 or assist in its implementation may be prepared, copied, published 2881 and distributed, in whole or in part, without restriction of any 2882 kind, provided that the above copyright notice and this paragraph 2883 are included on all such copies and derivative works. However, this 2884 document itself may not be modified in any way, such as by removing 2885 the copyright notice or references to the Internet Society or other 2886 Internet organizations, except as needed for the purpose of 2887 developing Internet standards in which case the procedures for 2888 copyrights defined in the Internet Standards process must be 2889 followed, or as required to translate it into languages other than 2890 English.