idnits 2.17.1 draft-ietf-sasl-rfc2222bis-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** 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 0) being 62 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 (June 2003) is 7619 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 840, but not defined == Missing Reference: 'RFC 3501' is mentioned on line 319, but not defined ** Obsolete undefined reference: RFC 3501 (Obsoleted by RFC 9051) == Missing Reference: 'StringPrep' is mentioned on line 321, but not defined == Unused Reference: 'Stringprep' is defined on line 640, 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' -- 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 (==), 10 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-01.txt June 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 27 June 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 27 June 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 27 June 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 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 184 Internet DRAFT SASL 27 June 2003 186 authorization identity is transferred, it SHOULD NOT be an empty 187 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 27 June 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 27 June 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. 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 If both TLS and SASL security layer are allowed to be negotiated by 305 the protocol, the protocol profile MUST define in which order they 306 are applied to a cleartext data sent over the connection. 308 In addition, a protocol profile SHOULD specify a mechanism through 309 which a client may obtain the names of the SASL mechanisms available 310 to it. This is typically done through the protocol's extensions or 311 capabilities mechanism. 313 A protocol profile MAY further refine the definition of an 314 authorization identity by adding additional syntactic restrictions 315 and protocol-specific semantics. A protocol profile MUST specify the 316 form of the authorization identity (as it is protocol specific, as 317 opposed to the authentication identity which is mechanism specific) 318 and how authorization identities are to be compared. Profiles whose 319 authorization identities are simple user names (e.g. IMAP [RFC 3501]) 320 are encouraged to employ [SASLPrep] profile [SASLPrep] of the 321 "stringprep" algorithm [StringPrep] to prepare these names for 322 matching. 324 <> 326 A protocol profile SHOULD NOT attempt to amend the definition of 327 mechanisms or make mechanism-specific encodings. This breaks the 328 separation between protocol and mechanism that is fundamental to the 329 design of SASL. 331 Internet DRAFT SASL 27 June 2003 333 6. Specific issues 335 6.1. Client sends data first 337 Some mechanisms specify that the first data sent in the 338 authentication protocol exchange is from the client to the server. 340 If a protocol's profile permits the command which initiates an 341 authentication protocol exchange to contain an initial client 342 response, this parameter SHOULD be used with such mechanisms. 344 If the initial client response parameter is not given, or if a 345 protocol's profile does not permit the command which initiates an 346 authentication protocol exchange to contain an initial client 347 response, then the server issues a challenge with no data. The 348 client's response to this challenge is then used as the initial 349 client response. (The server then proceeds to send the next 350 challenge, indicates completion, or indicates failure.) 352 6.2. Server returns success with additional data 354 Some mechanisms may specify that additional data be sent to the 355 client along with an indication of successful completion of the 356 exchange. This data would, for example, authenticate the server to 357 the client. 359 If a protocol's profile does not permit this additional data to be 360 returned with a success indication, then the server issues the data 361 as a server challenge, without an indication of successful 362 completion. The client then responds with no data. After receiving 363 this empty response, the server then indicates successful completion 364 (with no additional data). 366 Client implementors should be aware of an additional failure case 367 that might occur when the profile supports sending the additional 368 data with success. Imagine that an active attacker is trying to 369 impersonate the server and sends a faked data, that should be used to 370 authenticate the server to the client, with success. (A similar 371 situation can happen when the server has a bug and produces the wrong 372 response). After checking the data the client will think that the 373 authentication exchange has failed, however the server will think 374 that the authentication exchange has completed successfully. At this 375 point the client can't abort the authentication exchange, it SHOULD 376 close the connection instead. However if the profile didn't support 377 sending of additional data with success, the client could have 378 aborted the exchange. 380 <> 386 6.3. Multiple authentications 388 Unless otherwise stated by the protocol's profile, only one 389 successful SASL negotiation may occur in a protocol session. In this 390 case, once an authentication protocol exchange has successfully 391 completed, further attempts to initiate an authentication protocol 392 exchange fail. 394 In the case that a profile explicitly permits multiple successful 395 SASL negotiations to occur, then in no case may multiple security 396 layers be simultaneously in effect. If a security layer is in effect 397 and a subsequent SASL negotiation selects a second security layer, 398 then the second security layer replaces the first. If a security 399 layer is in effect and a subsequent SASL negotiation selects no 400 security layer, the original security layer must be removed. The next 401 paragraph explains why this is important. 403 A security layer that remains in effect when a client, which already 404 has authenticated and established the security layer with "Realm A", 405 authenticates to "Realm B", without negotiating a new security layer, 406 enables "Realm B" to make guesses about previously observed 407 ciphertext using the web server's SASL engine as an oracle. "Realm 408 B" may observe how known cleartext is encrypted. 410 <> 414 Internet DRAFT SASL 27 June 2003 416 +---------+ +---------+ 417 | | | | 418 | Realm B | | Realm A | 419 | | | | 420 +---------+ +---------+ 421 | ^ | 422 | : +-----------+ | 423 Traffic from | : | Encryption| | Traffic from A 424 B to client +-------->| end point |<-------+ to client 425 : | (SSL/SASL)| 426 : +-----------+ 427 : | 428 : | 429 : +---+ 430 : | | 431 : | | 432 : | | Encryption tunnel, e.g. SASL or SSL, 433 : | | between the server 434 (1) Recording +---------:| | and a single client only. 435 encrypted | | Separate tunnels to different 436 traffic between | | clients. 437 Realm A and client +---+ 438 | 439 | 440 +-----------> Traffic to clients 442 7. The EXTERNAL mechanism 444 The mechanism name associated with external authentication is 445 "EXTERNAL". 447 The client sends an initial response with the UTF-8 encoding of the 448 authorization identity. The form of the authorization identity is 449 further restricted by the application-level protocol's SASL profile. 451 The server uses information, external to SASL, to determine whether 452 the client is authorized to authenticate as the authorization 453 identity. If the client is so authorized, the server indicates 454 successful completion of the authentication exchange; otherwise the 455 server indicates failure. 457 The system providing this external information may be, for example, 458 IPsec or TLS. 460 If the client sends the empty string as the authorization identity 461 (thus requesting the authorization identity be derived from the 462 client's authentication credentials), the authorization identity is 463 to be derived from authentication credentials which exist in the 465 Internet DRAFT SASL 27 June 2003 467 system which is providing the external authentication. 469 7.1. Formal syntax 471 The following syntax specification uses the augmented Backus-Naur 472 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core 473 rules as specified in Appendix A of the ABNF specification [ABNF]. 474 Non-terminals referenced but not defined below are as defined by 475 [UTF-8]. 477 The "initial-response" rule below defines the initial response sent 478 from client to server. 480 initial-response = *( UTF8-char-no-null ) 482 UTF8-char-no-null = UTF8-1-no-null / UTF8-2 / UTF8-3 / UTF8-4 484 UTF8-1-no-null = %x01-7F 486 7.2. Example 488 The following is an example of an EXTERNAL authentication in the SMTP 489 protocol [SMTP-AUTH]. In this example, the client is proxy 490 authenticating, sending the authorization id "fred". The server has 491 determined the client's identity through IPsec and has a security 492 policy that permits that identity to proxy authenticate as any other 493 identity. 495 To the protocol profile, the four octet sequence "fred" is an opaque 496 binary blob. The SASL protocol profile for SMTP specifies that 497 server challenges and client responses are encoded in BASE64; the 498 BASE64 encoding of "fred" is "ZnJlZA==". 500 S: 220 smtp.example.com ESMTP server ready 501 C: EHLO jgm.example.com 502 S: 250-smtp.example.com 503 S: 250 AUTH DIGEST-MD5 EXTERNAL 504 C: AUTH EXTERNAL ZnJlZA== 505 S: 235 Authentication successful. 507 8. IANA Considerations 509 Registration of a SASL mechanism is done by filling in the template 510 in section 8.4 and sending it in to iana@iana.org. IANA has the 511 right to reject obviously bogus registrations, but will perform no 512 review of claims made in the registration form. 514 Internet DRAFT SASL 27 June 2003 516 There is no naming convention for SASL mechanisms; any name that 517 conforms to the syntax of a SASL mechanism name can be registered. 518 An IETF Standards Track document may reserve a portion of the SASL 519 mechanism namespace for its own use, amending the registration rules 520 for that portion of the namespace. 522 While the registration procedures do not require it, authors of SASL 523 mechanisms are encouraged to seek community review and comment 524 whenever that is feasible. Authors may seek community review by 525 posting a specification of their proposed mechanism as an internet- 526 draft. SASL mechanisms intended for widespread use should be 527 standardized through the normal IETF process, when appropriate. 529 8.1. Comments on SASL mechanism registrations 531 Comments on registered SASL mechanisms should first be sent to the 532 "owner" of the mechanism. Submitters of comments may, after a 533 reasonable attempt to contact the owner, request IANA to attach their 534 comment to the SASL mechanism registration itself. If IANA approves 535 of this the comment will be made accessible in conjunction with the 536 SASL mechanism registration itself. 538 8.2. Location of registered SASL mechanism list 540 SASL mechanism registrations are available at the URL 541 "http://www.iana.org/assignments/sasl-mechanisms" The SASL mechanism 542 description and other supporting material may also be published as an 543 Informational RFC by sending it to "rfc-editor@rfc-editor.org" 544 (please follow the instructions to RFC authors [RFC-INSTRUCTIONS]). 546 8.3. Change control 548 Once a SASL mechanism registration has been published by IANA, the 549 author may request a change to its definition. The change request 550 follows the same procedure as the registration request. 552 The owner of a SASL mechanism may pass responsibility for the SASL 553 mechanism to another person or agency by informing IANA; this can be 554 done without discussion or review. 556 The IESG may reassign responsibility for a SASL mechanism. The most 557 common case of this will be to enable changes to be made to 558 mechanisms where the author of the registration has died, moved out 559 of contact or is otherwise unable to make changes that are important 560 to the community. 562 SASL mechanism registrations may not be deleted; mechanisms which are 563 no longer believed appropriate for use can be declared OBSOLETE by a 565 Internet DRAFT SASL 27 June 2003 567 change to their "intended use" field; such SASL mechanisms will be 568 clearly marked in the lists published by IANA. 570 The IESG is considered to be the owner of all SASL mechanisms which 571 are on the IETF standards track. 573 8.4. Registration template 575 To: iana@isi.edu 576 Subject: Registration of SASL mechanism X 578 SASL mechanism name: 580 Security considerations: 582 Published specification (optional, recommended): 584 Person & email address to contact for further information: 586 Intended usage: 588 (One of COMMON, LIMITED USE or OBSOLETE) 590 Owner/Change controller: 592 (Any other information that the author deems interesting may be 593 added below this line.) 595 8.5. The EXTERNAL mechanism registration 597 It is requested that the SASL Mechanism registry [IANA-SASL] entry 598 for the EXTERNAL mechanism be updated to reflect that this document 599 now provides its technical specification. 601 To: iana@iana.org Subject: Updated Registration of SASL mechanism 602 EXTERNAL 604 SASL mechanism name: EXTERNAL 606 Security considerations: See RFC XXXX, section 10. 608 Published specification (optional, recommended): RFC XXXX 610 Person & email address to contact for further information: 611 Alexey Melnikov 613 Intended usage: COMMON 615 Internet DRAFT SASL 27 June 2003 617 Owner/Change controller: IESG 619 Note: Updates existing entry for EXTERNAL 621 9. References 623 9.1. Normative References 625 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 626 ABNF", RFC 2234, November 1997 628 [CHARSET-POLICY] Alvestrand, "IETF Policy on Character Sets and 629 Languages", RFC 2277, January 1998 631 [GSSAPI] Linn, "Generic Security Service Application Program 632 Interface, Version 2, Update 1", RFC 2743, January 2000 634 [ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) - 635 Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993. 637 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 638 Requirement Levels", RFC 2119, March 1997 640 [Stringprep] P. Hoffman, M. Blanchet, "Preparation of 641 Internationalized Strings ("stringprep")", RFC 3454, December 2002. 643 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names 644 and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt. 646 [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", work 647 in progress (draft-yergeau-rfc2279bis-XX) that replaces RFC 2279, 648 Janyary 1998 650 9.2. Informative References 652 <> [SASL-GSSAPI] Myers, "SASL GSSAPI 653 mechanisms", draft-ietf-cat-sasl-gssapi-XX.txt, September 2000 655 [SASL-OTP] Newman, "The One-Time-Password SASL Mechanism", RFC 2444, 656 October 1998 658 [SMTP-AUTH] Myers, "SMTP Service Extension for Authentication", RFC 659 2554, March 1999 661 [RFC-INSTRUCTIONS] Postel, Reynolds, "Instructions to RFC Authors", 662 RFC 2223, October 1997 664 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) 666 Internet DRAFT SASL 27 June 2003 668 MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms. 670 10. Security considerations 672 Security issues are discussed throughout this memo. 674 The mechanisms that support integrity protection are designed such 675 that the negotiation of the security layer and authorization identity 676 is integrity protected. When the client selects a security layer 677 with at least integrity protection, this protects against an active 678 attacker hijacking the connection and modifying the authentication 679 exchange to negotiate a plaintext connection. 681 When a server or client supports multiple authentication mechanisms, 682 each of which has a different security strength, it is possible for 683 an active attacker to cause a party to use the least secure mechanism 684 supported. To protect against this sort of attack, a client or 685 server which supports mechanisms of different strengths should have a 686 configurable minimum strength that it will use. It is not sufficient 687 for this minimum strength check to only be on the server, since an 688 active attacker can change which mechanisms the client sees as being 689 supported, causing the client to send authentication credentials for 690 its weakest supported mechanism. 692 The client's selection of a SASL mechanism is done in the clear and 693 may be modified by an active attacker. It is important for any new 694 SASL mechanisms to be designed such that an active attacker cannot 695 obtain an authentication with weaker security properties by modifying 696 the SASL mechanism name and/or the challenges and responses. 698 Any protocol interactions prior to authentication are performed in 699 the clear and may be modified by an active attacker. In the case 700 where a client selects integrity protection, it is important that any 701 security-sensitive protocol negotiations be performed after 702 authentication is complete. Protocols should be designed such that 703 negotiations performed prior to authentication should be either 704 ignored or revalidated once authentication is complete. 706 When use of a security layer is negotiated by the authentication 707 protocol exchange, the receiver should handle gracefully any security 708 encoded data buffer larger than the defined/negotiated maximal size. 709 In particular, it must not blindly allocate the ammount of memory 710 specified in the buffer size field, as this might cause the "out of 711 memory" condition. If the receiver detects a large block, it SHOULD 712 close the connection. 714 "stringprep" and Unicode security considerations apply to 715 authentication identities, authorization identities and passwords. 717 Internet DRAFT SASL 27 June 2003 719 The EXTERNAL mechanism provides no security protection; it is 720 vulnerable to spoofing by either client or server, active attack, and 721 eavesdropping. It should only be used when external security 722 mechanisms are present and have sufficient strength. 724 11. Editor's Address 726 Alexey Melnikov 727 Isode 729 Email: mel@isode.com 731 12. Acknowledgments 733 This document is a revision of RFC 2222 written by John G. Myers 734 . He also wrote the major part of this 735 document. 737 Thank you to Magnus Nystrom for the ASCII picture used in section 738 6.3. 740 <> 742 13. Full Copyright Statement 744 Copyright (C) The Internet Society (2003). All Rights Reserved. 746 This document and translations of it may be copied and furnished to 747 others, and derivative works that comment on or otherwise explain it 748 or assist in its implementation may be prepared, copied, published 749 and distributed, in whole or in part, without restriction of any 750 kind, provided that the above copyright notice and this paragraph are 751 included on all such copies and derivative works. However, this 752 document itself may not be modified in any way, such as by removing 753 the copyright notice or references to the Internet Society or other 754 Internet organizations, except as needed for the purpose of 755 developing Internet standards in which case the procedures for 756 copyrights defined in the Internet Standards process must be 757 followed, or as required to translate it into languages other than 758 English. 760 The limited permissions granted above are perpetual and will not be 761 revoked by the Internet Society or its successors or assigns. 763 This document and the information contained herein is provided on an 764 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 765 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 767 Internet DRAFT SASL 27 June 2003 769 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 770 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 771 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 773 Acknowledgement 775 Funding for the RFC Editor function is currently provided by the 776 Internet Society. 778 Appendix A. Relation of SASL to transport security 780 Questions have been raised about the relationship between SASL and 781 various services (such as IPsec and TLS) which provide a secured 782 connection. 784 Two of the key features of SASL are: 786 The separation of the authorization identity from the identity in 787 the client's credentials. This permits agents such as proxy 788 servers to authenticate using their own credentials, yet request 789 the access privileges of the identity for which they are proxying. 791 Upon successful completion of an authentication exchange, the 792 server knows the authorization identity the client wishes to use. 793 This allows servers to move to a "user is authenticated" state in 794 the protocol. 796 These features are extremely important to some application protocols, 797 yet Transport Security services do not always provide them. To 798 define SASL mechanisms based on these services would be a very messy 799 task, as the framing of these services would be redundant with the 800 framing of SASL and some method of providing these important SASL 801 features would have to be devised. 803 Sometimes it is desired to enable within an existing connection the 804 use of a security service which does not fit the SASL model. (TLS is 805 an example of such a service.) This can be done by adding a command, 806 for example "STARTTLS", to the protocol. Such a command is outside 807 the scope of SASL, and should be different from the command which 808 starts a SASL authentication protocol exchange. 810 In certain situations, it is reasonable to use SASL underneath one of 811 these Transport Security services. The transport service would 812 secure the connection, either service would authenticate the client, 813 and SASL would negotiate the authorization identity. The SASL 814 negotiation would be what moves the protocol from "unauthenticated" 815 to "authenticated" state. The "EXTERNAL" SASL mechanism is 816 explicitly intended to handle the case where the transport service 818 Internet DRAFT SASL 27 June 2003 820 secures the connection and authenticates the client and SASL 821 negotiates the authorization identity. 823 When using SASL underneath a sufficiently strong Transport Security 824 service, a SASL security layer would most likely be redundant. The 825 client and server would thus probably want to negotiate off the use 826 of a SASL security layer. 828 Appendix B. IANA considerations 830 The IANA is directed to modify the SASL mechanisms registry as 831 follows: 833 Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism 834 registrations to OBSOLETE. Change the "Published specification" 835 of the EXTERNAL mechanism to this document. 837 Appendix C. Changes since RFC 2222 839 The GSSAPI mechanism was removed. It is now specified in a separate 840 document [SASL-GSSAPI]. 842 The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has 843 been removed. 845 The "SKEY" mechanism described in RFC 2222 is obsolete and has been 846 removed. It has been replaced by the OTP mechanism [SASL-OTP]. 848 The overview has been substantially reorganized and clarified. 850 Clarified the definition and semantics of the authorization identity. 852 Prohibited the NULL character in authorization identities. 854 Added a section on character string issues. 856 The word "must" in the first paragraph of the "Protocol profile 857 requirements" section was changed to "MUST". 859 Specified that protocol profiles SHOULD provide a way for clients to 860 discover available SASL mechanisms. 862 Made the requirement that protocol profiles specify the semantics of 863 the authorization identity optional to the protocol profile. 864 Clarified that such a specification is a refinement of the definition 865 in the base SASL spec. 867 Added a requirement discouraging protocol profiles from breaking the 869 Internet DRAFT SASL 27 June 2003 871 separation between protocol and mechanism. 873 Mentioned that standards track documents may carve out their own 874 portions of the SASL mechanism namespace. 876 Specified that the authorization identity in the EXTERNAL mechanism 877 is encoded in UTF-8. 879 Added a statement that a protocol profile SHOULD allow challenge data 880 to be sent with a success indication. 882 Added a security consideration for the EXTERNAL mechansim. 884 Clarified sections concerning success with additional data. 886 Updated IANA related URLs. 888 Updated references and split them into Informative and Normative. 890 Added text to the Security Considerations section regarding handling 891 of extremely large SASL blocks. 893 Replaced UTF-8 ABNF with the reference to the UTF-8 document. 895 Added text about SASLPrep for authentication identities and 896 passwords. 898 Added paragraph about verifying authorization identities. 900 This document requires to drop a security layer on reauthentication 901 when no security layer is negotiated. This differs from RFC 2222, 902 which required to keep the last security layer in this case. 904 Added a protocol profile requirement to specify interaction between 905 SASL and TLS security layers. 907 Internet DRAFT SASL 27 June 2003 909 Table of contents 911 Status of this Memo .......................................... i 912 1. Abstract ............................................... 2 913 2. Organization of this document .......................... 2 914 2.1. How to read this document .............................. 2 915 2.2. Conventions used in this document ...................... 2 916 3. Overview ............................................... 2 917 4. Authentication mechanisms .............................. 3 918 4.1. Authentication protocol exchange ....................... 4 919 4.2. Authorization identities and proxy authentication ...... 4 920 4.3. Security layers ........................................ 5 921 4.4. Character string issues ................................ 6 922 5. Protocol profile requirements .......................... 6 923 6. Specific issues ........................................ 8 924 6.1. Client sends data first ................................ 8 925 6.2. Server returns success with additional data ............ 8 926 6.3. Multiple authentications ............................... 9 927 7. The EXTERNAL mechanism ................................ 10 928 7.1. Formal syntax ......................................... 11 929 7.2. Example ............................................... 11 930 8. IANA Considerations ................................... 11 931 8.1. Comments on SASL mechanism registrations .............. 12 932 8.2. Location of registered SASL mechanism list ............ 12 933 8.3. Change control ........................................ 12 934 8.4. Registration template ................................. 13 935 8.5. The EXTERNAL mechanism registration ................... 13 936 9. References ............................................ 14 937 9.1. Normative References .................................. 14 938 9.2. Informative References ................................ 14 939 10. Security considerations ............................... 15 940 11. Editor's Address ...................................... 16 941 12. Acknowledgments ....................................... 16 942 13. Full Copyright Statement .............................. 16 943 Appendix A. Relation of SASL to transport security .......... 17 944 Appendix B. IANA considerations ............................. 18 945 Appendix C. Changes since RFC 2222 .......................... 18