idnits 2.17.1 draft-ietf-sasl-rfc2222bis-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 18 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages -- Found 19 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2003) is 7651 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SASL-GSSAPI' is mentioned on line 783, but not defined == Missing Reference: 'RFC 3501' is mentioned on line 215, but not defined ** Obsolete undefined reference: RFC 3501 (Obsoleted by RFC 9051) == Missing Reference: 'StringPrep' is mentioned on line 257, but not defined == Unused Reference: 'Stringprep' is defined on line 587, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-10646' ** Obsolete normative reference: RFC 3454 (ref. 'Stringprep') (Obsoleted by RFC 7564) -- No information found for draft-ietf-sasl-saslprep-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASLPrep' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE-NORMALIZATION' -- No information found for draft-yergeau-rfc2279bis-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'UTF-8' -- Obsolete informational reference (is this intentional?): RFC 2554 (ref. 'SMTP-AUTH') (Obsoleted by RFC 4954) -- Obsolete informational reference (is this intentional?): RFC 2223 (ref. 'RFC-INSTRUCTIONS') (Obsoleted by RFC 7322) Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet Draft May 2003 4 Document: draft-ietf-sasl-rfc2222bis-00.txt 5 Expires in six months 7 Simple Authentication and Security Layer (SASL) 9 Status of this Memo 11 This document is an Internet Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its Areas, and its Working Groups. Note that 16 other groups may also distribute working documents as Internet 17 Drafts. Internet Drafts are draft documents valid for a maximum of 18 six months. Internet Drafts may be updated, replaced, or obsoleted 19 by other documents at any time. It is not appropriate to use 20 Internet Drafts as reference material or to cite them other than as 21 ``work in progress''. 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 A revised version of this draft document will be submitted to the RFC 30 editor as a Draft Standard for the Internet Community. Discussion 31 and suggestions for improvement are requested. Distribution of this 32 draft is unlimited. 34 Internet DRAFT SASL 18 May 2003 36 1. Abstract 38 SASL provides a method for adding authentication support with an 39 optional security layer to connection-based protocols. It also 40 describes a structure for authentication mechanisms. The result is 41 an abstraction layer between protocols and authentication mechanisms 42 such that any SASL-compatible authentication mechanism can be used 43 with any SASL-compatible protocol. 45 This document describes how a SASL authentication mechanism is 46 structured, how a protocol adds support for SASL, defines the 47 protocol for carrying a security layer over a connection, and defines 48 the EXTERNAL SASL authentication mechanism. 50 2. Organization of this document 52 2.1. How to read this document 54 This document is written to serve two different audiences, protocol 55 designers using this specification to support authentication in their 56 protocol, and implementors of clients or servers for those protocols 57 using this specification. 59 The sections "Overview", "Authentication Mechanisms", "Protocol 60 Profile Requirements", "Specific Issues", and "Security 61 Considerations" cover issues that protocol designers need to 62 understand and address in profiling this specification for use in a 63 specific protocol. 65 Implementors of a protocol using this specification need the 66 protocol-specific profiling information in addition to the 67 information in this document. 69 2.2. Conventions used in this document 71 In examples, "C:" and "S:" indicate lines sent by the client and 72 server respectively. 74 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 75 in this document are to be interpreted as defined in "Key words for 76 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 78 3. Overview 80 The Simple Authentication and Security Layer (SASL) is a method for 81 adding authentication support to connection-based protocols. 83 The SASL specification has three layers, as indicated in the diagram 85 Internet DRAFT SASL 18 May 2003 87 below. At the top, a protocol definition using SASL specifies a 88 profile, including a command for identifying and authenticating a 89 user to a server and for optionally negotiating a security layer for 90 subsequent protocol interactions. At the bottom, a SASL mechanism 91 definition specifies an authentication mechanism. The SASL 92 framework, specified by this document, constrains the behavior of 93 protocol profiles and mechanisms, separating protocol from mechanism 94 and defining how they interact. 96 SMTP Protocol LDAP Protocol Etc 97 Profile Profile . . . 98 \----- | -----/ 99 \ | / 100 SASL framework 101 / | \ 102 /----- | -----\ 103 EXTERNAL DIGEST-MD5 Etc 104 SASL mechanism SASL mechanism . . . 106 This separation between the definition of protocols and the 107 definition of authentication mechanisms is crucial. It permits an 108 authentication mechanism to be defined once, making it usable by any 109 SASL protocol profiles. In many implementations, the same SASL 110 mechanism code is used for multiple protocols. 112 4. Authentication mechanisms 114 SASL mechanisms are named by strings, from 1 to 20 characters in 115 length, consisting of upper-case letters, digits, hyphens, and/or 116 underscores. SASL mechanism names must be registered with the IANA. 117 IETF Standards Track documents may override this registration 118 requirement by reserving a portion of the SASL mechanism namespace 119 for their own use; the GSSAPI mechanism specification [SASL-GSSAPI] 120 does this. Procedures for registering new SASL mechanisms are given 121 in the section "Registration procedures". 123 The "sasl-mech" rule below defines the syntax of a SASL mechanism 124 name. This uses the augmented Backus-Naur Form (BNF) notation as 125 specified in [ABNF] and the ABNF core rules as specified in Appendix 126 A of the ABNF specification [ABNF]. 128 sasl-mech = 1*20mech-char 129 mech-char = %x41-5A / DIGIT / "-" / "_" 130 ; mech names restricted to uppercase letters, 131 ; digits, "-" and "_" 133 Internet DRAFT SASL 18 May 2003 135 4.1. Authentication protocol exchange 137 A SASL mechanism is responsible for conducting an authentication 138 protocol exchange. This consists of a series of server challenges 139 and client responses, the contents of which are specific to and 140 defined by the mechanism. To the protocol, the challenges and 141 responses are opaque binary tokens of arbitrary length. The 142 protocol's profile then specifies how these binary tokens are then 143 encoded for transfer over the connection. 145 After receiving an authentication command or any client response, a 146 server mechanism may issue a challenge, indicate failure, or indicate 147 completion. The server mechanism MAY return additional data with a 148 completion indication. The protocol's profile specifies how each of 149 these is then represented over the connection. 151 After receiving a challenge, a client mechanism may issue a response 152 or abort the exchange. The protocol's profile specifies how each of 153 these is then represented over the connection. 155 During the authentication protocol exchange, the mechanism performs 156 authentication, transmits an authorization identity (frequently known 157 as a userid) from the client to server, and negotiates the use of a 158 mechanism-specific security layer. If the use of a security layer is 159 agreed upon, then the mechanism must also define or negotiate the 160 maximum security layer buffer size that each side is able to receive. 162 4.2. Authorization identities and proxy authentication 164 An authorization identity is a string of zero or more ISO 10646 165 [ISO-10646] coded characters. The NUL (U+0000) character is not 166 permitted in authorization identities. The meaning of an 167 authorization identity of the empty string (zero lenght) is defined 168 below in this section. The authorization identity is used by the 169 server as the primary identity for making access policy decisions. 171 The character encoding scheme used for transmitting an authorization 172 identity over protocol is specified in each authentication mechanism 173 (with the authentication mechanism's blob being further 174 restricted/encoded by the protocol profile). Per IETF character set 175 policy [CHARSET-POLICY], authentication mechanisms SHOULD encode 176 these and other strings in UTF-8 [UTF-8]. While some legacy 177 mechanisms are incapable of transmitting an authoriation identity 178 other than the empty string, newly defined mechanisms are expected to 179 be capable of carrying the entire repertoire of Unicode Normalization 180 form KC [UNICODE-NORMALIZATION] (with the exception of the NUL 181 character). 183 Internet DRAFT SASL 18 May 2003 185 The identity derived from the client's authentication credentials is 186 known as the "authentication identity". With any mechanism, 187 transmitting an authorization identity of the empty string directs 188 the server to derive an authorization identity from the client's 189 authentication identity. 191 If the authorization identity transmitted during the authentication 192 protocol exchange is not the empty string, this is typically referred 193 to as "proxy authentication". This feature permits agents such as 194 proxy servers to authenticate using their own credentials, yet 195 request the access privileges of the identity for which they are 196 proxying. 198 The server makes an implementation defined policy decision as to 199 whether the authentication identity is permitted to have the access 200 privileges of the authorization identity and whether the 201 authorization identity is permitted to receive service. If it is 202 not, the server indicates failure of the authentication protocol 203 exchange. 205 As a client might not have the same information as the server, 206 clients SHOULD NOT themselves try to derive authorization identities 207 from authentication identities when clients could instead transmit an 208 authorization identity of the empty string. 210 <> 214 The server SHOULD verify the correctness of a received authorization 215 identity. For example, an IMAP [RFC 3501] server will prepare the 216 received authorization identity using the "SASLPrep" profile 217 [SASLPrep] of the "stringprep" algorithm [StringPrep]. If the 218 preparation of the authorization identity fails or results in an 219 empty string, the server MUST fail the authentication exchange. The 220 only exception to this rule is when the received authorization 221 identity is the empty string. 223 4.3. Security layers 225 If use of a security layer is negotiated by the authentication 226 protocol exchange, the security layer is applied to all subsequent 227 data sent over the connection. The security layer takes effect 228 immediately following the last response of the authentication 229 exchange for data sent by the client and the completion indication 230 for data sent by the server. 232 Once the security layer is in effect, the protocol stream is 234 Internet DRAFT SASL 18 May 2003 236 processed by the security layer into buffers of security encoded 237 data. Each buffer of security encoded data is transferred over the 238 connection as a stream of octets prepended with a four octet field in 239 network byte order that represents the length of the following 240 buffer. The length of the security encoded data buffer MUST be no 241 larger than the maximum size that was either defined in the mechanism 242 specification or negotiated by the other side during the 243 authentication protocol exchange. Upon the receipt of a data buffer 244 which is larger than the defined/negotiated maximal buffer size, the 245 receiver SHOULD close the connection. This might be a sign of an 246 attack or a buggy implementation. 248 4.4. Character string issues 250 Per IETF character set policy [CHARSET-POLICY], authentication 251 mechanisms SHOULD encode character strings in UTF-8 [UTF-8]. In 252 order to avoid noninteroperability due to differing normalizations, 253 when a mechanism specifies that a string authentication identity or 254 password used as input to a cryptographic function (or used for 255 comparison) it SHOULD specify that the string first be prepared using 256 the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm 257 [StringPrep]. This should be done by both the client (upon getting 258 user input or retrieving a value from configuration) and by the 259 server (upon receiving the value from the client). If preparation 260 fails or results in an empty string, the client/server SHALL fail the 261 authentication exchange. 263 5. Protocol profile requirements 265 In order to use this specification, a protocol definition MUST supply 266 the following information: 268 A service name, to be selected from the IANA registry of "service" 269 elements for the GSSAPI host-based service name form. [GSSAPI] This 270 service name is made available to the authentication mechanism. 272 The registry is available at the URL 273 "http://www.iana.org/assignments/gssapi-service-names" A definition 274 of the command to initiate the authentication protocol exchange. 275 This command must have as a parameter the name of the mechanism being 276 selected by the client. 278 The command SHOULD have an optional parameter giving an initial 279 response. This optional parameter allows the client to avoid a round 280 trip when using a mechanism which is defined to have the client send 281 data first. When this initial response is sent by the client and the 282 selected mechanism is defined to have the server start with an 284 Internet DRAFT SASL 18 May 2003 286 initial challenge, the command fails. See section 6.1 of this 287 document for further information. A definition of the method by 288 which the authentication protocol exchange is carried out, including 289 how the challenges and responses are encoded, how the server 290 indicates completion or failure of the exchange, how the client 291 aborts an exchange, and how the exchange method interacts with any 292 line length limits in the protocol. 294 The command SHOULD have a method for the server to include an 295 optional challenge with a success notification. This allows the 296 server to avoid a round trip when using a mechanism which is defined 297 to have the server send additional data along with the indication of 298 successful completion. See section 6.2 of this document for further 299 information. 301 Identification of the octet where any negotiated security layer 302 starts to take effect, in both directions. 304 In addition, a protocol profile SHOULD specify a mechanism through 305 which a client may obtain the names of the SASL mechanisms available 306 to it. This is typically done through the protocol's extensions or 307 capabilities mechanism. 309 A protocol profile MAY further refine the definition of an 310 authorization identity by adding additional syntactic restrictions 311 and protocol-specific semantics. 313 A protocol profile SHOULD NOT attempt to amend the definition of 314 mechanisms or make mechanism-specific encodings. This breaks the 315 separation between protocol and mechanism that is fundamental to the 316 design of SASL. 318 6. Specific issues 320 6.1. Client sends data first 322 Some mechanisms specify that the first data sent in the 323 authentication protocol exchange is from the client to the server. 325 If a protocol's profile permits the command which initiates an 326 authentication protocol exchange to contain an initial client 327 response, this parameter SHOULD be used with such mechanisms. 329 If the initial client response parameter is not given, or if a 330 protocol's profile does not permit the command which initiates an 331 authentication protocol exchange to contain an initial client 332 response, then the server issues a challenge with no data. The 333 client's response to this challenge is then used as the initial 335 Internet DRAFT SASL 18 May 2003 337 client response. (The server then proceeds to send the next 338 challenge, indicates completion, or indicates failure.) 340 6.2. Server returns success with additional data 342 Some mechanisms may specify that additional data be sent to the 343 client along with an indication of successful completion of the 344 exchange. This data would, for example, authenticate the server to 345 the client. 347 If a protocol's profile does not permit this additional data to be 348 returned with a success indication, then the server issues the data 349 as a server challenge, without an indication of successful 350 completion. The client then responds with no data. After receiving 351 this empty response, the server then indicates successful completion 352 (with no additional data). 354 Client implementors should be aware of an additional failure case 355 that might occur when the profile supports sending the additional 356 data with success. Imagine that an active attacker is trying to 357 impersonate the server and sends a faked data, that should be used to 358 authenticate the server to the client, with success. (A similar 359 situation can happen when the server has a bug and produces the wrong 360 response). After checking the data the client will think that the 361 authentication exchange has failed, however the server will think 362 that the authentication exchange has completed successfully. At this 363 point the client can't abort the authentication exchange, it SHOULD 364 close the connection instead. However if the profile didn't support 365 sending of additional data with success, the client could have 366 aborted the exchange. 368 <> 371 6.3. Multiple authentications 373 Unless otherwise stated by the protocol's profile, only one 374 successful SASL negotiation may occur in a protocol session. In this 375 case, once an authentication protocol exchange has successfully 376 completed, further attempts to initiate an authentication protocol 377 exchange fail. 379 In the case that a profile explicitly permits multiple successful 380 SASL negotiations to occur, then in no case may multiple security 381 layers be simultaneously in effect. If a security layer is in effect 382 and a subsequent SASL negotiation selects no security layer, the 383 original security layer remains in effect. If a security layer is in 384 effect and a subsequent SASL negotiation selects a second security 386 Internet DRAFT SASL 18 May 2003 388 layer, then the second security layer replaces the first. 390 7. The EXTERNAL mechanism 392 The mechanism name associated with external authentication is 393 "EXTERNAL". 395 The client sends an initial response with the UTF-8 encoding of the 396 authorization identity. The form of the authorization identity is 397 further restricted by the application-level protocol's SASL profile. 399 The server uses information, external to SASL, to determine whether 400 the client is authorized to authenticate as the authorization 401 identity. If the client is so authorized, the server indicates 402 successful completion of the authentication exchange; otherwise the 403 server indicates failure. 405 The system providing this external information may be, for example, 406 IPsec or TLS. 408 If the client sends the empty string as the authorization identity 409 (thus requesting the authorization identity be derived from the 410 client's authentication credentials), the authorization identity is 411 to be derived from authentication credentials which exist in the 412 system which is providing the external authentication. 414 7.1. Formal syntax 416 The following syntax specification uses the augmented Backus-Naur 417 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core 418 rules as specified in Appendix A of the ABNF specification [ABNF]. 419 Non-terminals referenced but not defined below are as defined by 420 [UTF-8]. 422 The "initial-response" rule below defines the initial response sent 423 from client to server. 425 initial-response = *( UTF8-char-no-null ) 427 UTF8-char-no-null = UTF8-1-no-null / UTF8-2 / UTF8-3 / UTF8-4 429 UTF8-1-no-null = %x01-7F 431 7.2. Example 433 The following is an example of an EXTERNAL authentication in the SMTP 434 protocol [SMTP-AUTH]. In this example, the client is proxy 436 Internet DRAFT SASL 18 May 2003 438 authenticating, sending the authorization id "fred". The server has 439 determined the client's identity through IPsec and has a security 440 policy that permits that identity to proxy authenticate as any other 441 identity. 443 To the protocol profile, the four octet sequence "fred" is an opaque 444 binary blob. The SASL protocol profile for SMTP specifies that 445 server challenges and client responses are encoded in BASE64; the 446 BASE64 encoding of "fred" is "ZnJlZA==". 448 S: 220 smtp.example.com ESMTP server ready 449 C: EHLO jgm.example.com 450 S: 250-smtp.example.com 451 S: 250 AUTH DIGEST-MD5 EXTERNAL 452 C: AUTH EXTERNAL ZnJlZA== 453 S: 235 Authentication successful. 455 8. IANA Considerations 457 Registration of a SASL mechanism is done by filling in the template 458 in section 8.4 and sending it in to iana@iana.org. IANA has the 459 right to reject obviously bogus registrations, but will perform no 460 review of claims made in the registration form. 462 There is no naming convention for SASL mechanisms; any name that 463 conforms to the syntax of a SASL mechanism name can be registered. 464 An IETF Standards Track document may reserve a portion of the SASL 465 mechanism namespace for its own use, amending the registration rules 466 for that portion of the namespace. 468 While the registration procedures do not require it, authors of SASL 469 mechanisms are encouraged to seek community review and comment 470 whenever that is feasible. Authors may seek community review by 471 posting a specification of their proposed mechanism as an internet- 472 draft. SASL mechanisms intended for widespread use should be 473 standardized through the normal IETF process, when appropriate. 475 8.1. Comments on SASL mechanism registrations 477 Comments on registered SASL mechanisms should first be sent to the 478 "owner" of the mechanism. Submitters of comments may, after a 479 reasonable attempt to contact the owner, request IANA to attach their 480 comment to the SASL mechanism registration itself. If IANA approves 481 of this the comment will be made accessible in conjunction with the 482 SASL mechanism registration itself. 484 Internet DRAFT SASL 18 May 2003 486 8.2. Location of registered SASL mechanism list 488 SASL mechanism registrations are available at the URL 489 "http://www.iana.org/assignments/sasl-mechanisms" The SASL mechanism 490 description and other supporting material may also be published as an 491 Informational RFC by sending it to "rfc-editor@rfc-editor.org" 492 (please follow the instructions to RFC authors [RFC-INSTRUCTIONS]). 494 8.3. Change control 496 Once a SASL mechanism registration has been published by IANA, the 497 author may request a change to its definition. The change request 498 follows the same procedure as the registration request. 500 The owner of a SASL mechanism may pass responsibility for the SASL 501 mechanism to another person or agency by informing IANA; this can be 502 done without discussion or review. 504 The IESG may reassign responsibility for a SASL mechanism. The most 505 common case of this will be to enable changes to be made to 506 mechanisms where the author of the registration has died, moved out 507 of contact or is otherwise unable to make changes that are important 508 to the community. 510 SASL mechanism registrations may not be deleted; mechanisms which are 511 no longer believed appropriate for use can be declared OBSOLETE by a 512 change to their "intended use" field; such SASL mechanisms will be 513 clearly marked in the lists published by IANA. 515 The IESG is considered to be the owner of all SASL mechanisms which 516 are on the IETF standards track. 518 8.4. Registration template 520 To: iana@isi.edu 521 Subject: Registration of SASL mechanism X 523 SASL mechanism name: 525 Security considerations: 527 Published specification (optional, recommended): 529 Person & email address to contact for further information: 531 Intended usage: 533 (One of COMMON, LIMITED USE or OBSOLETE) 535 Internet DRAFT SASL 18 May 2003 537 Owner/Change controller: 539 (Any other information that the author deems interesting may be 540 added below this line.) 542 8.5. The EXTERNAL mechanism registration 544 It is requested that the SASL Mechanism registry [IANA-SASL] entry 545 for the EXTERNAL mechanism be updated to reflect that this document 546 now provides its technical specification. 548 To: iana@iana.org Subject: Updated Registration of SASL mechanism 549 EXTERNAL 551 SASL mechanism name: EXTERNAL 553 Security considerations: See RFC XXXX, section 10. 555 Published specification (optional, recommended): RFC XXXX 557 Person & email address to contact for further information: 558 Alexey Melnikov 560 Intended usage: COMMON 562 Owner/Change controller: IESG 564 Note: Updates existing entry for EXTERNAL 566 9. References 568 9.1. Normative References 570 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 571 ABNF", RFC 2234, November 1997 573 [CHARSET-POLICY] Alvestrand, "IETF Policy on Character Sets and 574 Languages", RFC 2277, January 1998 576 [GSSAPI] Linn, "Generic Security Service Application Program 577 Interface, Version 2, Update 1", RFC 2743, January 2000 579 [ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) - 580 Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993. 582 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 583 Requirement Levels", RFC 2119, March 1997 585 Internet DRAFT SASL 18 May 2003 587 [Stringprep] P. Hoffman, M. Blanchet, "Preparation of 588 Internationalized Strings ("stringprep")", RFC 3454, December 2002. 590 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names 591 and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt. 593 [UNICODE-NORMALIZATION] Davis, Durst, "Unicode Standard Annex #15: 594 Unicode Normalization Forms", March 2001, 595 http://www.unicode.org/unicode/reports/tr15/ 597 [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", work 598 in progress (draft-yergeau-rfc2279bis-XX) that replaces RFC 2279, 599 Janyary 1998 601 9.2. Informative References 603 <> [SASL-GSSAPI] Myers, "SASL GSSAPI 604 mechanisms", draft-ietf-cat-sasl-gssapi-XX.txt, September 2000 606 [SASL-OTP] Newman, "The One-Time-Password SASL Mechanism", RFC 2444, 607 October 1998 609 [SMTP-AUTH] Myers, "SMTP Service Extension for Authentication", RFC 610 2554, March 1999 612 [RFC-INSTRUCTIONS] Postel, Reynolds, "Instructions to RFC Authors", 613 RFC 2223, October 1997 615 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) 616 MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms. 618 10. Security considerations 620 Security issues are discussed throughout this memo. 622 The mechanisms that support integrity protection are designed such 623 that the negotiation of the security layer and authorization identity 624 is integrity protected. When the client selects a security layer 625 with at least integrity protection, this protects against an active 626 attacker hijacking the connection and modifying the authentication 627 exchange to negotiate a plaintext connection. 629 When a server or client supports multiple authentication mechanisms, 630 each of which has a different security strength, it is possible for 631 an active attacker to cause a party to use the least secure mechanism 632 supported. To protect against this sort of attack, a client or 633 server which supports mechanisms of different strengths should have a 634 configurable minimum strength that it will use. It is not sufficient 636 Internet DRAFT SASL 18 May 2003 638 for this minimum strength check to only be on the server, since an 639 active attacker can change which mechanisms the client sees as being 640 supported, causing the client to send authentication credentials for 641 its weakest supported mechanism. 643 The client's selection of a SASL mechanism is done in the clear and 644 may be modified by an active attacker. It is important for any new 645 SASL mechanisms to be designed such that an active attacker cannot 646 obtain an authentication with weaker security properties by modifying 647 the SASL mechanism name and/or the challenges and responses. 649 Any protocol interactions prior to authentication are performed in 650 the clear and may be modified by an active attacker. In the case 651 where a client selects integrity protection, it is important that any 652 security-sensitive protocol negotiations be performed after 653 authentication is complete. Protocols should be designed such that 654 negotiations performed prior to authentication should be either 655 ignored or revalidated once authentication is complete. 657 When use of a security layer is negotiated by the authentication 658 protocol exchange, the receiver should handle gracefully any security 659 encoded data buffer larger than the defined/negotiated maximal size. 660 In particular, it must not blindly allocate the ammount of memory 661 specified in the buffer size field, as this might cause the "out of 662 memory" condition. If the receiver detects a large block, it SHOULD 663 close the connection. 665 "stringprep" and Unicode security considerations apply to 666 authentication identities, authorization identities and passwords. 668 The EXTERNAL mechanism provides no security protection; it is 669 vulnerable to spoofing by either client or server, active attack, and 670 eavesdropping. It should only be used when external security 671 mechanisms are present and have sufficient strength. 673 11. Editor's Address 675 Alexey Melnikov 676 ACI Worldwide/MessagingDirect 678 Email: mel@messagingdirect.com 680 12. Acknowledgments 682 This document is a revision of RFC 2222 written by John G. Myers 683 . He also wrote the major part of this 684 document. 686 Internet DRAFT SASL 18 May 2003 688 13. Full Copyright Statement 690 Copyright (C) The Internet Society (2003). All Rights Reserved. 692 This document and translations of it may be copied and furnished to 693 others, and derivative works that comment on or otherwise explain it 694 or assist in its implementation may be prepared, copied, published 695 and distributed, in whole or in part, without restriction of any 696 kind, provided that the above copyright notice and this paragraph are 697 included on all such copies and derivative works. However, this 698 document itself may not be modified in any way, such as by removing 699 the copyright notice or references to the Internet Society or other 700 Internet organizations, except as needed for the purpose of 701 developing Internet standards in which case the procedures for 702 copyrights defined in the Internet Standards process must be 703 followed, or as required to translate it into languages other than 704 English. 706 The limited permissions granted above are perpetual and will not be 707 revoked by the Internet Society or its successors or assigns. 709 This document and the information contained herein is provided on an 710 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 711 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 712 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 713 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 714 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 716 Acknowledgement 718 Funding for the RFC Editor function is currently provided by the 719 Internet Society. 721 Appendix A. Relation of SASL to transport security 723 Questions have been raised about the relationship between SASL and 724 various services (such as IPsec and TLS) which provide a secured 725 connection. 727 Two of the key features of SASL are: 729 The separation of the authorization identity from the identity in 730 the client's credentials. This permits agents such as proxy 731 servers to authenticate using their own credentials, yet request 732 the access privileges of the identity for which they are proxying. 734 Upon successful completion of an authentication exchange, the 735 server knows the authorization identity the client wishes to use. 737 Internet DRAFT SASL 18 May 2003 739 This allows servers to move to a "user is authenticated" state in 740 the protocol. 742 These features are extremely important to some application protocols, 743 yet Transport Security services do not always provide them. To 744 define SASL mechanisms based on these services would be a very messy 745 task, as the framing of these services would be redundant with the 746 framing of SASL and some method of providing these important SASL 747 features would have to be devised. 749 Sometimes it is desired to enable within an existing connection the 750 use of a security service which does not fit the SASL model. (TLS is 751 an example of such a service.) This can be done by adding a command, 752 for example "STARTTLS", to the protocol. Such a command is outside 753 the scope of SASL, and should be different from the command which 754 starts a SASL authentication protocol exchange. 756 In certain situations, it is reasonable to use SASL underneath one of 757 these Transport Security services. The transport service would 758 secure the connection, either service would authenticate the client, 759 and SASL would negotiate the authorization identity. The SASL 760 negotiation would be what moves the protocol from "unauthenticated" 761 to "authenticated" state. The "EXTERNAL" SASL mechanism is 762 explicitly intended to handle the case where the transport service 763 secures the connection and authenticates the client and SASL 764 negotiates the authorization identity. 766 When using SASL underneath a sufficiently strong Transport Security 767 service, a SASL security layer would most likely be redundant. The 768 client and server would thus probably want to negotiate off the use 769 of a SASL security layer. 771 Appendix B. IANA considerations 773 The IANA is directed to modify the SASL mechanisms registry as 774 follows: 776 Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism 777 registrations to OBSOLETE. Change the "Published specification" 778 of the EXTERNAL mechanism to this document. 780 Appendix C. Changes since RFC 2222 782 The GSSAPI mechanism was removed. It is now specified in a separate 783 document [SASL-GSSAPI]. 785 The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has 786 been removed. 788 Internet DRAFT SASL 18 May 2003 790 The "SKEY" mechanism described in RFC 2222 is obsolete and has been 791 removed. It has been replaced by the OTP mechanism [SASL-OTP]. 793 The overview has been substantially reorganized and clarified. 795 Clarified the definition and semantics of the authorization identity. 797 Prohibited the NULL character in authorization identities. 799 Added a section on character string issues. 801 The word "must" in the first paragraph of the "Protocol profile 802 requirements" section was changed to "MUST". 804 Specified that protocol profiles SHOULD provide a way for clients to 805 discover available SASL mechanisms. 807 Made the requirement that protocol profiles specify the semantics of 808 the authorization identity optional to the protocol profile. 809 Clarified that such a specification is a refinement of the definition 810 in the base SASL spec. 812 Added a requirement discouraging protocol profiles from breaking the 813 separation between protocol and mechanism. 815 Mentioned that standards track documents may carve out their own 816 portions of the SASL mechanism namespace. 818 Specified that the authorization identity in the EXTERNAL mechanism 819 is encoded in UTF-8. 821 Added a statement that a protocol profile SHOULD allow challenge data 822 to be sent with a success indication. 824 Added a security consideration for the EXTERNAL mechansim. 826 Clarified sections concerning success with additional data. 828 Updated IANA related URLs. 830 Updated references and split them into Informative and Normative. 832 Added text to the Security Considerations section regarding handling 833 of extremely large SASL blocks. 835 Replaced UTF-8 ABNF with the reference to the UTF-8 document. 837 Added text about SASLPrep for authentication identities and 839 Internet DRAFT SASL 18 May 2003 841 passwords. 843 Added paragraph about verifying authorization identities. 845 Internet DRAFT SASL 18 May 2003 847 Table of contents 849 Status of this Memo .......................................... i 850 1. Abstract ............................................... 2 851 2. Organization of this document .......................... 2 852 2.1. How to read this document .............................. 2 853 2.2. Conventions used in this document ...................... 2 854 3. Overview ............................................... 2 855 4. Authentication mechanisms .............................. 3 856 4.1. Authentication protocol exchange ....................... 4 857 4.2. Authorization identities and proxy authentication ...... 4 858 4.3. Security layers ........................................ 5 859 4.4. Character string issues ................................ 6 860 5. Protocol profile requirements .......................... 6 861 6. Specific issues ........................................ 7 862 6.1. Client sends data first ................................ 7 863 6.2. Server returns success with additional data ............ 8 864 6.3. Multiple authentications ............................... 8 865 7. The EXTERNAL mechanism ................................. 9 866 7.1. Formal syntax .......................................... 9 867 7.2. Example ................................................ 9 868 8. IANA Considerations ................................... 10 869 8.1. Comments on SASL mechanism registrations .............. 10 870 8.2. Location of registered SASL mechanism list ............ 11 871 8.3. Change control ........................................ 11 872 8.4. Registration template ................................. 11 873 8.5. The EXTERNAL mechanism registration ................... 12 874 9. References ............................................ 12 875 9.1. Normative References .................................. 12 876 9.2. Informative References ................................ 13 877 10. Security considerations ............................... 13 878 11. Editor's Address ...................................... 14 879 12. Acknowledgments ....................................... 14 880 13. Full Copyright Statement .............................. 15 881 Appendix A. Relation of SASL to transport security .......... 15 882 Appendix B. IANA considerations ............................. 16 883 Appendix C. Changes since RFC 2222 .......................... 16