idnits 2.17.1 draft-ietf-sasl-rfc2222bis-02.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 19 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 20 pages -- Found 20 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (August 2003) is 7561 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 859, but not defined == Missing Reference: 'RFC 3501' is mentioned on line 320, but not defined ** Obsolete undefined reference: RFC 3501 (Obsoleted by RFC 9051) == Missing Reference: 'StringPrep' is mentioned on line 322, but not defined == Unused Reference: 'Stringprep' is defined on line 650, 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' -- No information found for draft-yergeau-rfc2279bis-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'UTF-8' -- No information found for draft-ietf-sasl-rfc2831bis-XX - is the name correct? -- 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: 10 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 Editor 4 Document: draft-ietf-sasl-rfc2222bis-02.txt August 2003 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 19 August 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 19 August 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 19 August 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 length) 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 authorization identity 178 other than the empty string, newly defined mechanisms are expected to 179 be capable of carrying the entire Unicode repertoire (with the 180 exception of the NUL character). An authorization identity of the 181 empty string and and an absent authorization identity MUST be treated 182 as equivalent. However, mechanisms SHOULD NOT allow both (i.e. if an 184 Internet DRAFT SASL 19 August 2003 186 authorization identity is allowed to be absent, but one is 187 transferred, it SHOULD NOT be an empty string). 189 The identity derived from the client's authentication credentials is 190 known as the "authentication identity". With any mechanism, 191 transmitting an authorization identity of the empty string directs 192 the server to derive an authorization identity from the client's 193 authentication identity. 195 If the authorization identity transmitted during the authentication 196 protocol exchange is not the empty string, this is typically referred 197 to as "proxy authentication". This feature permits agents such as 198 proxy servers to authenticate using their own credentials, yet 199 request the access privileges of the identity for which they are 200 proxying. 202 The server makes an implementation defined policy decision as to 203 whether the authentication identity is permitted to have the access 204 privileges of the authorization identity and whether the 205 authorization identity is permitted to receive service. If it is 206 not, the server indicates failure of the authentication protocol 207 exchange. 209 As a client might not have the same information as the server, 210 clients SHOULD NOT themselves try to derive authorization identities 211 from authentication identities when clients could instead transmit an 212 authorization identity of the empty string. 214 The server SHOULD verify the correctness of a received authorization 215 identity. Profiles whose authorization identities are simple user 216 names (e.g. IMAP [RFC 3501]) are encouraged to employ [SASLPrep] 217 profile [SASLPrep] of the "stringprep" algorithm [StringPrep] to 218 prepare these names for matching. If the preparation of the 219 authorization identity fails or results in an empty string, the 220 server MUST fail the authentication exchange. The only exception to 221 this rule is when the received authorization identity is already the 222 empty string. 224 4.3. Security layers 226 If use of a security layer is negotiated by the authentication 227 protocol exchange, the security layer is applied to all subsequent 228 data sent over the connection. The security layer takes effect 229 immediately following the last response of the authentication 230 exchange for data sent by the client and the completion indication 231 for data sent by the server. 233 Internet DRAFT SASL 19 August 2003 235 Once the security layer is in effect, the protocol stream is 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 283 Internet DRAFT SASL 19 August 2003 285 selected mechanism is defined to have the server start with an 286 initial challenge, the command fails. See section 6.1 of this 287 document for further information. 289 A definition of the method by which the authentication protocol 290 exchange is carried out, including how the challenges and responses 291 are encoded, how the server indicates completion or failure of the 292 exchange, how the client aborts an exchange, and how the exchange 293 method interacts with any line length limits in the protocol. 295 The command SHOULD have a method for the server to include an 296 optional challenge with a success notification. This allows the 297 server to avoid a round trip when using a mechanism which is defined 298 to have the server send additional data along with the indication of 299 successful completion. See section 6.2 of this document for further 300 information. 302 In addition, a protocol profile SHOULD specify a mechanism through 303 which a client may obtain the names of the SASL mechanisms available 304 to it. This is typically done through the protocol's extensions or 305 capabilities mechanism. 307 Identification of the octet where any negotiated security layer 308 starts to take effect, in both directions. 310 If both TLS and SASL security layer are allowed to be negotiated by 311 the protocol, the protocol profile MUST define in which order they 312 are applied to a cleartext data sent over the connection. 314 A protocol profile MAY further refine the definition of an 315 authorization identity by adding additional syntactic restrictions 316 and protocol-specific semantics. A protocol profile MUST specify the 317 form of the authorization identity (as it is protocol specific, as 318 opposed to the authentication identity which is mechanism specific) 319 and how authorization identities are to be compared. Profiles whose 320 authorization identities are simple user names (e.g. IMAP [RFC 3501]) 321 are encouraged to employ [SASLPrep] profile [SASLPrep] of the 322 "stringprep" algorithm [StringPrep] to prepare these names for 323 matching. 325 Certain SASL mechanisms, e.g. DIGEST-MD5 [SASL-DIGEST], use a concept 326 of realm. Conceptually, realm is the name of a collection of user's 327 accounts. Realms allow the protected resources on a server to be 328 partitioned into a set of protection spaces, each with its own 329 authentication mechanisms and/or authorization database. For example, 330 a proxy/frontend can use different realms for different 331 servers/backends it represents. The realm value is a case- 332 insensitive string, generally assigned by the origin server, which 334 Internet DRAFT SASL 19 August 2003 336 may have additional semantics specific to the authentication 337 mechanism. 339 A protocol profile SHOULD provide a guidance how realms are to be 340 constructed and used in the protocol and MAY further restrict its 341 syntax and protocol-specific semantics. 343 A protocol profile SHOULD NOT attempt to amend the definition of 344 mechanisms or make mechanism-specific encodings. This breaks the 345 separation between protocol and mechanism that is fundamental to the 346 design of SASL. 348 6. Specific issues 350 6.1. Client sends data first 352 Some mechanisms specify that the first data sent in the 353 authentication protocol exchange is from the client to the server. 355 If a protocol's profile permits the command which initiates an 356 authentication protocol exchange to contain an initial client 357 response, this parameter SHOULD be used with such mechanisms. 359 If the initial client response parameter is not given, or if a 360 protocol's profile does not permit the command which initiates an 361 authentication protocol exchange to contain an initial client 362 response, then the server issues a challenge with no data. The 363 client's response to this challenge is then used as the initial 364 client response. (The server then proceeds to send the next 365 challenge, indicates completion, or indicates failure.) 367 6.2. Server returns success with additional data 369 Some mechanisms may specify that additional data be sent to the 370 client along with an indication of successful completion of the 371 exchange. This data would, for example, authenticate the server to 372 the client. 374 If a protocol's profile does not permit this additional data to be 375 returned with a success indication, then the server issues the data 376 as a server challenge, without an indication of successful 377 completion. The client then responds with no data. After receiving 378 this empty response, the server then indicates successful completion 379 (with no additional data). 381 Client implementors should be aware of an additional failure case 382 that might occur when the profile supports sending the additional 383 data with success. Imagine that an active attacker is trying to 385 Internet DRAFT SASL 19 August 2003 387 impersonate the server and sends a faked data, that should be used to 388 authenticate the server to the client, with success. (A similar 389 situation can happen when either the server and/or the client has a 390 bug and they calculate different responses). After checking the data 391 the client will think that the authentication exchange has failed, 392 however the server will think that the authentication exchange has 393 completed successfully. At this point the client can't abort the 394 authentication exchange, it SHOULD close the connection instead. 395 However, if the profile didn't support sending of additional data 396 with success, the client could have aborted the exchange at the very 397 last step of the authentication exchange. 399 6.3. Multiple authentications 401 Unless otherwise stated by the protocol's profile, only one 402 successful SASL negotiation may occur in a protocol session. In this 403 case, once an authentication protocol exchange has successfully 404 completed, further attempts to initiate an authentication protocol 405 exchange fail. 407 In the case that a profile explicitly permits multiple successful 408 SASL negotiations to occur, then in no case may multiple security 409 layers be simultaneously in effect. If a security layer is in effect 410 and a subsequent SASL negotiation selects a second security layer, 411 then the second security layer replaces the first. If a security 412 layer is in effect and a subsequent SASL negotiation selects no 413 security layer, the original security layer must be removed. The next 414 paragraph explains why this is important. 416 Below the term "realm" has the meaning as defined in the section 5. 417 A security layer that remains in effect when a client, which already 418 has authenticated and established the security layer with "Realm A", 419 authenticates to "Realm B", without negotiating a new security layer, 420 enables "Realm B" to make guesses about previously observed 421 ciphertext using the server's SASL engine as an oracle. "Realm B" may 422 observe how known cleartext is encrypted. 424 Internet DRAFT SASL 19 August 2003 426 +---------+ +---------+ 427 | | | | 428 | Realm B | | Realm A | 429 | | | | 430 +---------+ +---------+ 431 | ^ | 432 | : +-----------+ | 433 Traffic from | : | Encryption| | Traffic from A 434 B to client +-------->| end point |<-------+ to client 435 : | (SSL/SASL)| 436 : +-----------+ 437 : | 438 : | 439 : +---+ 440 : | | 441 : | | 442 : | | Encryption tunnel, e.g. SASL or SSL, 443 : | | between the server 444 (1) Recording +---------:| | and a single client only. 445 encrypted | | Separate tunnels to different 446 traffic between | | clients. 447 Realm A and client +---+ 448 | 449 | 450 +-----------> Traffic to clients 452 7. The EXTERNAL mechanism 454 The mechanism name associated with external authentication is 455 "EXTERNAL". 457 The client sends an initial response with the UTF-8 encoding of the 458 authorization identity. The form of the authorization identity is 459 further restricted by the application-level protocol's SASL profile. 461 The server uses information, external to SASL, to determine whether 462 the client is authorized to authenticate as the authorization 463 identity. If the client is so authorized, the server indicates 464 successful completion of the authentication exchange; otherwise the 465 server indicates failure. 467 The system providing this external information may be, for example, 468 IPsec or TLS. 470 If the client sends the empty string as the authorization identity 471 (thus requesting the authorization identity be derived from the 472 client's authentication credentials), the authorization identity is 473 to be derived from authentication credentials which exist in the 475 Internet DRAFT SASL 19 August 2003 477 system which is providing the external authentication. 479 7.1. Formal syntax 481 The following syntax specification uses the augmented Backus-Naur 482 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core 483 rules as specified in Appendix A of the ABNF specification [ABNF]. 484 Non-terminals referenced but not defined below are as defined by 485 [UTF-8]. 487 The "initial-response" rule below defines the initial response sent 488 from client to server. 490 initial-response = *( UTF8-char-no-null ) 492 UTF8-char-no-null = UTF8-1-no-null / UTF8-2 / UTF8-3 / UTF8-4 494 UTF8-1-no-null = %x01-7F 496 7.2. Example 498 The following is an example of an EXTERNAL authentication in the SMTP 499 protocol [SMTP-AUTH]. In this example, the client is proxy 500 authenticating, sending the authorization id "fred". The server has 501 determined the client's identity through IPsec and has a security 502 policy that permits that identity to proxy authenticate as any other 503 identity. 505 To the protocol profile, the four octet sequence "fred" is an opaque 506 binary blob. The SASL protocol profile for SMTP specifies that 507 server challenges and client responses are encoded in BASE64; the 508 BASE64 encoding of "fred" is "ZnJlZA==". 510 S: 220 smtp.example.com ESMTP server ready 511 C: EHLO jgm.example.com 512 S: 250-smtp.example.com 513 S: 250 AUTH DIGEST-MD5 EXTERNAL 514 C: AUTH EXTERNAL ZnJlZA== 515 S: 235 Authentication successful. 517 8. IANA Considerations 519 Registration of a SASL mechanism is done by filling in the template 520 in section 8.4 and sending it in to iana@iana.org. IANA has the 521 right to reject obviously bogus registrations, but will perform no 522 review of claims made in the registration form. 524 Internet DRAFT SASL 19 August 2003 526 There is no naming convention for SASL mechanisms; any name that 527 conforms to the syntax of a SASL mechanism name can be registered. 528 An IETF Standards Track document may reserve a portion of the SASL 529 mechanism namespace for its own use, amending the registration rules 530 for that portion of the namespace. 532 While the registration procedures do not require it, authors of SASL 533 mechanisms are encouraged to seek community review and comment 534 whenever that is feasible. Authors may seek community review by 535 posting a specification of their proposed mechanism as an internet- 536 draft. SASL mechanisms intended for widespread use should be 537 standardized through the normal IETF process, when appropriate. 539 8.1. Comments on SASL mechanism registrations 541 Comments on registered SASL mechanisms should first be sent to the 542 "owner" of the mechanism. Submitters of comments may, after a 543 reasonable attempt to contact the owner, request IANA to attach their 544 comment to the SASL mechanism registration itself. If IANA approves 545 of this the comment will be made accessible in conjunction with the 546 SASL mechanism registration itself. 548 8.2. Location of registered SASL mechanism list 550 SASL mechanism registrations are available at the URL 551 "http://www.iana.org/assignments/sasl-mechanisms" The SASL mechanism 552 description and other supporting material may also be published as an 553 Informational RFC by sending it to "rfc-editor@rfc-editor.org" 554 (please follow the instructions to RFC authors [RFC-INSTRUCTIONS]). 556 8.3. Change control 558 Once a SASL mechanism registration has been published by IANA, the 559 author may request a change to its definition. The change request 560 follows the same procedure as the registration request. 562 The owner of a SASL mechanism may pass responsibility for the SASL 563 mechanism to another person or agency by informing IANA; this can be 564 done without discussion or review. 566 The IESG may reassign responsibility for a SASL mechanism. The most 567 common case of this will be to enable changes to be made to 568 mechanisms where the author of the registration has died, moved out 569 of contact or is otherwise unable to make changes that are important 570 to the community. 572 SASL mechanism registrations may not be deleted; mechanisms which are 573 no longer believed appropriate for use can be declared OBSOLETE by a 575 Internet DRAFT SASL 19 August 2003 577 change to their "intended use" field; such SASL mechanisms will be 578 clearly marked in the lists published by IANA. 580 The IESG is considered to be the owner of all SASL mechanisms which 581 are on the IETF standards track. 583 8.4. Registration template 585 To: iana@isi.edu 586 Subject: Registration of SASL mechanism X 588 SASL mechanism name: 590 Security considerations: 592 Published specification (optional, recommended): 594 Person & email address to contact for further information: 596 Intended usage: 598 (One of COMMON, LIMITED USE or OBSOLETE) 600 Owner/Change controller: 602 (Any other information that the author deems interesting may be 603 added below this line.) 605 8.5. The EXTERNAL mechanism registration 607 It is requested that the SASL Mechanism registry [IANA-SASL] entry 608 for the EXTERNAL mechanism be updated to reflect that this document 609 now provides its technical specification. 611 To: iana@iana.org 612 Subject: Updated Registration of SASL mechanism EXTERNAL 614 SASL mechanism name: EXTERNAL 616 Security considerations: See RFC XXXX, section 10. 618 Published specification (optional, recommended): RFC XXXX 620 Person & email address to contact for further information: 621 Alexey Melnikov 623 Intended usage: COMMON 625 Internet DRAFT SASL 19 August 2003 627 Owner/Change controller: IESG 629 Note: Updates existing entry for EXTERNAL 631 9. References 633 9.1. Normative References 635 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 636 ABNF", RFC 2234, November 1997 638 [CHARSET-POLICY] Alvestrand, "IETF Policy on Character Sets and 639 Languages", RFC 2277, January 1998 641 [GSSAPI] Linn, "Generic Security Service Application Program 642 Interface, Version 2, Update 1", RFC 2743, January 2000 644 [ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) - 645 Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993. 647 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 648 Requirement Levels", RFC 2119, March 1997 650 [Stringprep] P. Hoffman, M. Blanchet, "Preparation of 651 Internationalized Strings ("stringprep")", RFC 3454, December 2002. 653 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names 654 and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt. 656 [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", work 657 in progress (draft-yergeau-rfc2279bis-XX) that replaces RFC 2279, 658 Janyary 1998 660 9.2. Informative References 662 <> [SASL-GSSAPI] Myers, "SASL GSSAPI 663 mechanisms", work in progress, draft-ietf-cat-sasl-gssapi-XX.txt, 664 September 2000 666 [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest 667 Authentication as a SASL Mechanism", work in progress, draft-ietf- 668 sasl-rfc2831bis-XX.txt, replaces RFC 2831 670 [SASL-OTP] Newman, "The One-Time-Password SASL Mechanism", RFC 2444, 671 October 1998 673 [SMTP-AUTH] Myers, "SMTP Service Extension for Authentication", RFC 674 2554, March 1999 676 Internet DRAFT SASL 19 August 2003 678 [RFC-INSTRUCTIONS] Postel, Reynolds, "Instructions to RFC Authors", 679 RFC 2223, October 1997 681 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) 682 MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms. 684 10. Security considerations 686 Security issues are discussed throughout this memo. 688 The mechanisms that support integrity protection are designed such 689 that the negotiation of the security layer and authorization identity 690 is integrity protected. When the client selects a security layer 691 with at least integrity protection, this protects against an active 692 attacker hijacking the connection and modifying the authentication 693 exchange to negotiate a plaintext connection. 695 When a server or client supports multiple authentication mechanisms, 696 each of which has a different security strength, it is possible for 697 an active attacker to cause a party to use the least secure mechanism 698 supported. To protect against this sort of attack, a client or 699 server which supports mechanisms of different strengths should have a 700 configurable minimum strength that it will use. It is not sufficient 701 for this minimum strength check to only be on the server, since an 702 active attacker can change which mechanisms the client sees as being 703 supported, causing the client to send authentication credentials for 704 its weakest supported mechanism. 706 The client's selection of a SASL mechanism is done in the clear and 707 may be modified by an active attacker. It is important for any new 708 SASL mechanisms to be designed such that an active attacker cannot 709 obtain an authentication with weaker security properties by modifying 710 the SASL mechanism name and/or the challenges and responses. 712 Any protocol interactions prior to authentication are performed in 713 the clear and may be modified by an active attacker. In the case 714 where a client selects integrity protection, it is important that any 715 security-sensitive protocol negotiations be performed after 716 authentication is complete. Protocols should be designed such that 717 negotiations performed prior to authentication should be either 718 ignored or revalidated once authentication is complete. 720 When use of a security layer is negotiated by the authentication 721 protocol exchange, the receiver should handle gracefully any security 722 encoded data buffer larger than the defined/negotiated maximal size. 723 In particular, it must not blindly allocate the amount of memory 724 specified in the buffer size field, as this might cause the "out of 725 memory" condition. If the receiver detects a large block, it SHOULD 727 Internet DRAFT SASL 19 August 2003 729 close the connection. 731 "stringprep" and Unicode security considerations apply to 732 authentication identities, authorization identities and passwords. 734 The EXTERNAL mechanism provides no security protection; it is 735 vulnerable to spoofing by either client or server, active attack, and 736 eavesdropping. It should only be used when external security 737 mechanisms are present and have sufficient strength. 739 11. Editor's Address 741 Alexey Melnikov 742 Isode 744 Email: mel@isode.com 746 12. Acknowledgments 748 This document is a revision of RFC 2222 written by John G. Myers 749 . He also wrote the major part of this 750 document. 752 Thank you to Magnus Nystrom for the ASCII picture used in section 753 6.3. 755 Definition of realm was extracted from RFC 2617 ("HTTP 756 Authentication: Basic and Digest Access Authentication"). 758 Contributions of many members of the SASL mailing list are gratefully 759 acknowledged. 761 13. Full Copyright Statement 763 Copyright (C) The Internet Society (2003). All Rights Reserved. 765 This document and translations of it may be copied and furnished to 766 others, and derivative works that comment on or otherwise explain it 767 or assist in its implementation may be prepared, copied, published 768 and distributed, in whole or in part, without restriction of any 769 kind, provided that the above copyright notice and this paragraph are 770 included on all such copies and derivative works. However, this 771 document itself may not be modified in any way, such as by removing 772 the copyright notice or references to the Internet Society or other 773 Internet organizations, except as needed for the purpose of 774 developing Internet standards in which case the procedures for 775 copyrights defined in the Internet Standards process must be 777 Internet DRAFT SASL 19 August 2003 779 followed, or as required to translate it into languages other than 780 English. 782 The limited permissions granted above are perpetual and will not be 783 revoked by the Internet Society or its successors or assigns. 785 This document and the information contained herein is provided on an 786 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 787 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 788 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 789 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 790 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 792 Acknowledgement 794 Funding for the RFC Editor function is currently provided by the 795 Internet Society. 797 Appendix A. Relation of SASL to transport security 799 Questions have been raised about the relationship between SASL and 800 various services (such as IPsec and TLS) which provide a secured 801 connection. 803 Two of the key features of SASL are: 805 The separation of the authorization identity from the identity in 806 the client's credentials. This permits agents such as proxy 807 servers to authenticate using their own credentials, yet request 808 the access privileges of the identity for which they are proxying. 810 Upon successful completion of an authentication exchange, the 811 server knows the authorization identity the client wishes to use. 812 This allows servers to move to a "user is authenticated" state in 813 the protocol. 815 These features are extremely important to some application protocols, 816 yet Transport Security services do not always provide them. To 817 define SASL mechanisms based on these services would be a very messy 818 task, as the framing of these services would be redundant with the 819 framing of SASL and some method of providing these important SASL 820 features would have to be devised. 822 Sometimes it is desired to enable within an existing connection the 823 use of a security service which does not fit the SASL model. (TLS is 824 an example of such a service.) This can be done by adding a command, 825 for example "STARTTLS", to the protocol. Such a command is outside 826 the scope of SASL, and should be different from the command which 828 Internet DRAFT SASL 19 August 2003 830 starts a SASL authentication protocol exchange. 832 In certain situations, it is reasonable to use SASL underneath one of 833 these Transport Security services. The transport service would 834 secure the connection, either service would authenticate the client, 835 and SASL would negotiate the authorization identity. The SASL 836 negotiation would be what moves the protocol from "unauthenticated" 837 to "authenticated" state. The "EXTERNAL" SASL mechanism is 838 explicitly intended to handle the case where the transport service 839 secures the connection and authenticates the client and SASL 840 negotiates the authorization identity. 842 When using SASL underneath a sufficiently strong Transport Security 843 service, a SASL security layer would most likely be redundant. The 844 client and server would thus probably want to negotiate off the use 845 of a SASL security layer. 847 Appendix B. IANA considerations 849 The IANA is directed to modify the SASL mechanisms registry as 850 follows: 852 Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism 853 registrations to OBSOLETE. Change the "Published specification" 854 of the EXTERNAL mechanism to this document. 856 Appendix C. Changes since RFC 2222 858 The GSSAPI mechanism was removed. It is now specified in a separate 859 document [SASL-GSSAPI]. 861 The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has 862 been removed. 864 The "SKEY" mechanism described in RFC 2222 is obsolete and has been 865 removed. It has been replaced by the OTP mechanism [SASL-OTP]. 867 The overview has been substantially reorganized and clarified. 869 Clarified the definition and semantics of the authorization identity. 871 Prohibited the NULL character in authorization identities. 873 Added a section on character string issues. 875 The word "must" in the first paragraph of the "Protocol profile 876 requirements" section was changed to "MUST". 878 Internet DRAFT SASL 19 August 2003 880 Specified that protocol profiles SHOULD provide a way for clients to 881 discover available SASL mechanisms. 883 Made the requirement that protocol profiles specify the semantics of 884 the authorization identity optional to the protocol profile. 885 Clarified that such a specification is a refinement of the definition 886 in the base SASL spec. 888 Added a requirement discouraging protocol profiles from breaking the 889 separation between protocol and mechanism. 891 Mentioned that standards track documents may carve out their own 892 portions of the SASL mechanism namespace. 894 Specified that the authorization identity in the EXTERNAL mechanism 895 is encoded in UTF-8. 897 Added a statement that a protocol profile SHOULD allow challenge data 898 to be sent with a success indication. 900 Added a security consideration for the EXTERNAL mechansim. 902 Clarified sections concerning success with additional data. 904 Updated IANA related URLs. 906 Updated references and split them into Informative and Normative. 908 Added text to the Security Considerations section regarding handling 909 of extremely large SASL blocks. 911 Replaced UTF-8 ABNF with the reference to the UTF-8 document. 913 Added text about SASLPrep for authentication identities and 914 passwords. 916 Added paragraph about verifying authorization identities. 918 This document requires to drop a security layer on reauthentication 919 when no security layer is negotiated. This differs from RFC 2222, 920 which required to keep the last security layer in this case. 922 Added a protocol profile requirement to specify interaction between 923 SASL and TLS security layers. 925 Internet DRAFT SASL 19 August 2003 927 Status of this Memo ......................................... i 928 1. Abstract .............................................. 2 929 2. Organization of this document ......................... 2 930 2.1. How to read this document ............................. 2 931 2.2. Conventions used in this document ..................... 2 932 3. Overview .............................................. 2 933 4. Authentication mechanisms ............................. 3 934 4.1. Authentication protocol exchange ...................... 4 935 4.2. Authorization identities and proxy authentication ..... 4 936 4.3. Security layers ....................................... 5 937 4.4. Character string issues ............................... 6 938 5. Protocol profile requirements ......................... 6 939 6. Specific issues ....................................... 8 940 6.1. Client sends data first ............................... 8 941 6.2. Server returns success with additional data ........... 8 942 6.3. Multiple authentications .............................. 9 943 7. The EXTERNAL mechanism ............................... 10 944 7.1. Formal syntax ........................................ 11 945 7.2. Example .............................................. 11 946 8. IANA Considerations .................................. 11 947 8.1. Comments on SASL mechanism registrations ............. 12 948 8.2. Location of registered SASL mechanism list ........... 12 949 8.3. Change control ....................................... 12 950 8.4. Registration template ................................ 13 951 8.5. The EXTERNAL mechanism registration .................. 13 952 9. References ........................................... 14 953 9.1. Normative References ................................. 14 954 9.2. Informative References ............................... 14 955 10. Security considerations .............................. 15 956 11. Editor's Address ..................................... 16 957 12. Acknowledgments ...................................... 16 958 13. Full Copyright Statement ............................. 16 959 Appendix A. Relation of SASL to transport security ......... 17 960 Appendix B. IANA considerations ............................ 18 961 Appendix C. Changes since RFC 2222 ......................... 18