idnits 2.17.1 draft-ietf-sasl-rfc2222bis-06.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 26 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 27 pages -- Found 27 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 are 5 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 224: '... clients SHOULD NOT derive authoriza...' RFC 2119 keyword, line 225: '...Instead, clients SHOULD provide no (or...' RFC 2119 keyword, line 229: '... The server SHOULD verify that a rec...' RFC 2119 keyword, line 231: '... user names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep" profile...' RFC 2119 keyword, line 233: '...ng. The profiles MAY use a stringprep ...' (37 more instances...) == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2222, but the abstract doesn't seem to mention this, which it should. 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 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 (February 2004) is 7369 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: 'RFC 3501' is mentioned on line 358, but not defined ** Obsolete undefined reference: RFC 3501 (Obsoleted by RFC 9051) == Missing Reference: 'StringPrep' is mentioned on line 396, but not defined == Unused Reference: 'ISO-10646' is defined on line 974, but no explicit reference was found in the text == Unused Reference: 'Stringprep' is defined on line 990, but no explicit reference was found in the text == Unused Reference: 'RFC-INSTRUCTIONS' is defined on line 1033, 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. 'ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-10646' -- Possible downref: Non-RFC (?) normative reference: ref. 'KEYWORDS' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' ** 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-ietf-sasl-gssapi-XX - is the name correct? -- No information found for draft-ietf-sasl-rfc2831bis-XX - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2554 (ref. 'SMTP-AUTH') (Obsoleted by RFC 4954) -- No information found for draft-ietf-xmpp-core-XX - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2223 (ref. 'RFC-INSTRUCTIONS') (Obsoleted by RFC 7322) Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 16 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-06.txt February 2004 5 Obsoletes: RFC 2222 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 Standards Track RFC for the Internet Community. 31 Discussion and suggestions for improvement are requested. 32 Distribution of this draft is unlimited. 34 When published as an RFC this document will obsolete RFC 2222. 36 Internet DRAFT SASL 14 February 2004 38 1. Abstract 40 The Simple Authentication and Security Layer (SASL) provides a method 41 for adding authentication support with an optional security layer to 42 connection-based protocols. It also describes a structure for 43 authentication mechanisms. The result is an abstraction layer 44 between protocols and authentication mechanisms such that any SASL- 45 compatible authentication mechanism can be used with any SASL- 46 compatible protocol. 48 This document describes how a SASL authentication mechanism is 49 structured, describes how a protocol adds support for SASL, defines 50 the protocol for carrying a security layer over a connection, and 51 defines the EXTERNAL SASL authentication mechanism. 53 2. Organization of this document 55 2.1. How to read this document 57 This document is written to serve several different audiences, 58 protocol designers using this specification to support authentication 59 in their protocol, mechanism designers that define new SASL 60 mechanisms, and implementors of clients or servers for those 61 protocols using this specification. 63 The sections "Overview", "Authentication Mechanisms", "Protocol 64 Profile Requirements", "Specific Issues", and "Security 65 Considerations" cover issues that protocol designers need to 66 understand and address in profiling this specification for use in a 67 specific protocol. 69 The sections "Overview", "Authentication Mechanisms", "Mechanism 70 Profile Requirements" and "Security Considerations" cover issues that 71 mechanism designers need to understand and address in designing new 72 SASL mechanisms. 74 Implementors of a protocol using this specification need the 75 protocol-specific profiling information in addition to the 76 information in this document. 78 2.2. Conventions used in this document 80 In examples, "C:" and "S:" indicate lines sent by the client and 81 server respectively. 83 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 84 in this document are to be interpreted as defined in "Key words for 85 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 87 Internet DRAFT SASL 14 February 2004 89 Character names in this document use the notation for code points and 90 names from the Unicode Standard [Unicode]. For example, the letter 91 "a" may be represented as either or . 93 This document uses terms "integrity protection" and "confidentiality 94 protection". The former references to a security layer that is able 95 to detect data modification by using some kind of hash. However, 96 integrity protection doesn't make the data unreadable to an attacker. 97 Confidentiality protection is a security layer that is able to make 98 the data unreadable to an attacker by using encryption. 99 Confidentiality protection usually implies integrity protection. 101 3. Overview 103 The Simple Authentication and Security Layer (SASL) is a method for 104 adding authentication support to connection-based protocols. 106 The SASL specification has three layers, as indicated in the diagram 107 below. At the top, a protocol definition using SASL specifies a 108 profile, including a command for identifying and authenticating a 109 user to a server and for optionally negotiating a security layer for 110 subsequent protocol interactions. At the bottom, a SASL mechanism 111 definition specifies an authentication mechanism. The SASL 112 framework, specified by this document, constrains the behavior of 113 protocol profiles and mechanisms, separating protocol from mechanism 114 and defining how they interact. 116 SMTP Protocol LDAP Protocol Etc 117 Profile Profile . . . 118 \----- | -----/ 119 \ | / 120 SASL framework 121 / | \ 122 /----- | -----\ 123 EXTERNAL DIGEST-MD5 Etc 124 SASL mechanism SASL mechanism . . . 126 This separation between the definition of protocols and the 127 definition of authentication mechanisms is crucial. It permits an 128 authentication mechanism to be defined once, making it usable by any 129 SASL protocol profile. In many implementations, the same SASL 130 mechanism code is used for multiple protocols. 132 4. Authentication mechanisms 134 SASL mechanisms are named by strings, from 1 to 20 characters in 135 length, consisting of ASCII [ASCII] upper-case letters, digits, 137 Internet DRAFT SASL 14 February 2004 139 hyphens, and/or underscores. SASL mechanism names must be registered 140 with the Internet Assigned Numbers Authority (IANA). IETF standards 141 track documents may direct the IANA to reserve a portion of the SASL 142 mechanism namespace and may specify different registration criteria 143 for the reserved portion; the GSSAPI mechanism specification 144 [SASL-GSSAPI] does this. Procedures for registering new SASL 145 mechanisms are given in section 8. 147 The "sasl-mech" production below defines the syntax of a SASL 148 mechanism name. This uses the Augmented Backus-Naur Form (ABNF) 149 notation as specified in [ABNF] and the ABNF core rules as specified 150 in Appendix A of the ABNF specification [ABNF]. 152 sasl-mech = 1*20mech-char 153 mech-char = %x41-5A / DIGIT / "-" / "_" 154 ; mech names restricted to ASCII uppercase letters, 155 ; digits, "-" and "_" 157 4.1. Authentication protocol exchange 159 A SASL mechanism is responsible for conducting an authentication 160 protocol exchange. This consists of a series of server challenges 161 and client responses, the contents of which are specific to and 162 defined by the mechanism. To the protocol, the challenges and 163 responses are opaque binary tokens of arbitrary length. The 164 protocol's profile then specifies how these binary tokens are then 165 encoded for transfer over the connection. 167 After receiving an authentication command or any client response, a 168 server mechanism may issue a challenge, indicate failure, or indicate 169 completion. The server mechanism may return additional data with a 170 completion indication. The protocol's profile specifies how each of 171 these is then represented over the connection. 173 After receiving a challenge, a client mechanism may issue a response 174 or abort the exchange. The protocol's profile specifies how each of 175 these is then represented over the connection. 177 During the authentication protocol exchange, the mechanism performs 178 authentication, transmits an authorization identity (frequently known 179 as a userid) from the client to server, and negotiates the use of a 180 mechanism-specific security layer. If the use of a security layer is 181 agreed upon, then the mechanism must also define or negotiate the 182 maximum security layer buffer size that each side is able to receive. 184 Internet DRAFT SASL 14 February 2004 186 4.2. Authorization and authentication identities 188 SASL authentication deals with two identities: the authorization 189 identity and the authentication identity. The transmitted 190 authorization identity may be an empty string (zero length), but the 191 transmitted authentication identity may not be an empty string. 193 A mechanisms which are incapable of transmitting an authorization 194 identity must be treated as if it always transmits an authorization 195 identity of an empty string. 197 Authentication identity is the identity derived from the client's 198 authentication credentials. 200 The authorization identity is used by the server as the primary 201 identity for making access policy decisions. 203 4.2.1. Authorization identities and proxy authentication 205 With any mechanism, transmitting an authorization identity of the 206 empty string directs the server to derive the authorization identity 207 from the client's authentication identity. 209 If the authorization identity transmitted during the authentication 210 protocol exchange is not the empty string, this is typically referred 211 to as "proxy authentication". This feature permits agents such as 212 proxy servers to authenticate using their own credentials, yet 213 request the access privileges of the identity for which they are 214 proxying. 216 The server makes an implementation defined policy decision as to 217 whether the authentication identity is permitted to have the access 218 privileges of the authorization identity and whether the 219 authorization identity is permitted to receive service. If it is 220 not, the server indicates failure of the authentication protocol 221 exchange. 223 As a client might not have the same information as the server, 224 clients SHOULD NOT derive authorization identities from 225 authentication identities. Instead, clients SHOULD provide no (or 226 empty) authorization identity when the user has not provided an 227 authorization identity. 229 The server SHOULD verify that a received authorization identity is in 230 the correct form. Profiles whose authorization identities are simple 231 user names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep" profile 232 [SASLprep] of the "stringprep" algorithm [StringPrep] to prepare 233 these names for matching. The profiles MAY use a stringprep profile 235 Internet DRAFT SASL 14 February 2004 237 that is more strict than "SASLprep". If the preparation of the 238 authorization identity fails or results in an empty string, the 239 server MUST fail the authentication exchange. The only exception to 240 this rule is when the received authorization identity is already the 241 empty string. 243 4.2.2. Authorization Identity Format 245 An authorization identity is a string of zero or more Unicode 246 [Unicode] coded characters. The NUL character is not 247 permitted in authorization identities. 249 The character encoding scheme used for transmitting an authorization 250 identity over the protocol is specified in each authentication 251 mechanism. All IETF-defined mechanisms MUST, and all other 252 mechanisms SHOULD, use UTF-8 [UTF-8]. (See [CHARSET-POLICY] for IETF 253 policy regarding character sets and encoding schemes.) 255 Mechanisms are expected to be capable of carrying the entire Unicode 256 repertoire (with the exception of the NUL character). An 257 authorization identity of the empty string and an absent 258 authorization identity MUST be treated as equivalent. A mechanism 259 which provides an optional field for an authorization identity, 260 SHOULD NOT allow that field, when present, to be empty. The meaning 261 of the empty string as an authorization identity is described in the 262 previous section. 264 4.3. Security layers 266 If use of a security layer is negotiated by the authentication 267 protocol exchange, the security layer is applied to all subsequent 268 data sent over the connection (until another security layer is 269 negotiated; see also section 6.3). The security layer takes effect 270 immediately following the last response of the authentication 271 exchange for data sent by the client and the completion indication 272 for data sent by the server. 274 Note that all SASL mechanisms that are unable to negotiate a security 275 layer automatically select no security layer. 277 Once the security layer is in effect the protocol stream is processed 278 by the security layer into buffers of security encoded data. Each 279 buffer of security encoded data is transferred over the connection as 280 a stream of octets prepended with a four octet field in network byte 281 order that represents the length of the following buffer. The length 282 of the security encoded data buffer MUST be no larger than the 283 maximum size that was either defined in the mechanism specification 284 or negotiated by the other side during the authentication protocol 286 Internet DRAFT SASL 14 February 2004 288 exchange. Upon the receipt of a data buffer which is larger than the 289 defined/negotiated maximal buffer size the receiver SHOULD close the 290 connection. This might be a sign of an attack or a buggy 291 implementation. 293 5. Protocol and mechanism profiles 295 5.1. Protocol profile requirements 297 In order to use this specification, a protocol definition MUST supply 298 the following information: 300 1) A service name, to be selected from the IANA registry of "service" 301 elements for the GSSAPI host-based service name form [GSSAPI]. This 302 service name is made available to the authentication mechanism. 304 The registry is available at the URL 305 . 307 2) A definition of the command to initiate the authentication 308 protocol exchange. This command must have as a parameter the name of 309 the mechanism being selected by the client. 311 The command SHOULD have an optional parameter giving an initial 312 response. If the protocol allows for the initial response, the 313 protocol profile SHOULD also describe how an empty initial response 314 is encoded. This optional parameter allows the client to avoid a 315 round trip when using a mechanism which is defined to have the client 316 send data first. When this initial response is sent by the client 317 and the selected mechanism is defined to have the server start with 318 an initial challenge, the command fails. See section 6.1 of this 319 document for further information. 321 3) A definition of the method by which the authentication protocol 322 exchange is carried out, including how the challenges and responses 323 are encoded, how the server indicates completion or failure of the 324 exchange, how the client aborts an exchange, and how the exchange 325 method interacts with any line length limits in the protocol. 327 The exchange method SHOULD allow the server to include an optional 328 data ("optional challenge") with a success notification. This allows 329 the server to avoid a round trip when using a mechanism which is 330 defined to have the server send additional data along with the 331 indication of successful completion. See section 6.2 of this 332 document for further information. 334 4) A protocol profile SHOULD specify a mechanism through which a 335 client may obtain the names of the SASL mechanisms available to it. 337 Internet DRAFT SASL 14 February 2004 339 This is typically done through the protocol's extensions or 340 capabilities mechanism. 342 5) Identification of the octet where any negotiated security layer 343 starts to take effect, in both directions. 345 6) Specify if the protocol profile supports "multiple 346 authentications" (see section 6.3). 348 7) If both TLS and SASL security layer are allowed to be negotiated 349 by the protocol, the protocol profile MUST define in which order they 350 are applied to a cleartext data sent over the connection. 352 8) A protocol profile MAY further refine the definition of an 353 authorization identity by adding additional syntactic restrictions 354 and protocol-specific semantics. A protocol profile MUST specify the 355 form of the authorization identity (since it is protocol specific, as 356 opposed to the authentication identity, which is mechanism specific) 357 and how authorization identities are to be compared. Profiles whose 358 authorization identities are simple user names (e.g. IMAP [RFC 3501]) 359 SHOULD use "SASLprep" profile [SASLprep] of the "stringprep" 360 algorithm [StringPrep] to prepare these names for matching. The 361 profiles MAY use a stringprep profile that is more strict than 362 SASLprep. 364 A protocol profile SHOULD NOT attempt to amend the definition of 365 mechanisms or make mechanism-specific encodings. This breaks the 366 separation between protocol and mechanism that is fundamental to the 367 design of SASL. Likewise, SASL mechanisms SHOULD be profile neutral. 369 5.2. Mechanism profile guidelines 371 Designers of new SASL mechanism should be aware of the following 372 issues: 374 1) Authorization identity. 376 While some legacy mechanisms are incapable of transmitting an 377 authorization identity (which means that for these mechanisms the 378 authorization identity is always the empty string), newly defined 379 mechanisms SHOULD be capable of transmitting a non-empty 380 authorization identity. See also section 4.2. 382 2) Character string issues 384 Authentication mechanisms SHOULD encode character strings in UTF-8 385 [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character 387 Internet DRAFT SASL 14 February 2004 389 sets in IETF protocols). In order to avoid interoperability problems 390 due to differing normalizations, when a mechanisms specifies that 391 character data is to be used as input to a cryptographic and/or 392 comparison function, the mechanism specification MUST detail how the 393 data is to be represented, including any normalizations or other 394 preparations, to ensure proper function. Designers of mechanisms 395 SHOULD use the "SASLprep" profile [SASLprep] of the "stringprep" 396 algorithm [StringPrep] where applicable. 398 The preparation can be potentially performed on the client end (upon 399 getting user input or retrieving a value from configuration) or on 400 the server end (upon receiving the value from the client, retrieving 401 a value from its authentication database or generating a new value in 402 order to store in in the authentication database). SASL mechanisms 403 must define which entity (or entities) must perform the preparation. 404 If preparation fails or results in an empty string, the entity doing 405 the preparation SHALL fail the authentication exchange. 407 Implementation note: A server end can be represented by multiple 408 processes. For example, it may consist of the server process itself 409 that communicated with a client, and a command line utility (a server 410 agent) that is able to store passwords/hashes in a database that can 411 be later used by the server. For the server agent the requirement to 412 "fail the authentication exchange" should be interpreted as a 413 requirement to refuse to store the data in the database. 415 6. Specific issues 417 6.1. Client sends data first 419 Some mechanisms specify that the first data sent in the 420 authentication protocol exchange is from the client to the server. 422 If a protocol's profile permits the command which initiates an 423 authentication protocol exchange to contain an initial client 424 response, this parameter SHOULD be used with such mechanisms. 426 If the initial client response parameter is not given, or if a 427 protocol's profile does not permit the command which initiates an 428 authentication protocol exchange to contain an initial client 429 response, then the server issues a challenge with no data. The 430 client's response to this challenge is then used as the initial 431 client response. (The server then proceeds to send the next 432 challenge, indicates completion, or indicates failure.) 434 Internet DRAFT SASL 14 February 2004 436 6.1.1. Client sends data first examples 438 The following are two examples of an SECURID authentication [SASL- 439 SECURID] in the SMTP protocol [SMTP]. In the first example below, 440 the client is trying fast reauthentication by sending the initial 441 response: 443 S: 220-smtp.example.com ESMTP Server 444 C: EHLO client.example.com 445 S: 250-smtp.example.com Hello client.example.com, pleased to meet you 446 S: 250-AUTH GSSAPI SECURID 447 S: 250 DSN 448 C: AUTH SECURID AG1hZ251cwAxMjM0NTY3OAA= 449 S: 235 Authentication successful 451 The example below is almost identical to the previous, but here the 452 client chooses not to use the initial response parameter. 454 S: 220-smtp.example.com ESMTP Server 455 C: EHLO client.example.com 456 S: 250-smtp.example.com Hello client.example.com, pleased to meet you 457 S: 250-AUTH GSSAPI SECURID 458 S: 250 DSN 459 C: AUTH SECURID 460 S: 334 461 C: AG1hZ251cwAxMjM0NTY3OAA= 462 S: 235 Authentication successful 464 Section 7.2 contains an additional example. 466 6.2. Server returns success with additional data 468 Some mechanisms may specify that additional data be sent to the 469 client along with an indication of successful completion of the 470 exchange. This data would, for example, authenticate the server to 471 the client. 473 If a protocol's profile does not permit this additional data to be 474 returned with a success indication, then the server issues the data 475 as a server challenge, without an indication of successful 476 completion. The client then responds with no data. After receiving 477 this empty response, the server then indicates successful completion 478 (with no additional data). 480 Client implementors should be aware of an additional failure case 481 that might occur when the profile supports sending the additional 482 data with success. Imagine that an active attacker is trying to 484 Internet DRAFT SASL 14 February 2004 486 impersonate the server and sends faked data, which should be used to 487 authenticate the server to the client, with success. (A similar 488 situation can happen when either the server and/or the client has a 489 bug and they calculate different responses.) After checking the data, 490 the client will think that the authentication exchange has failed, 491 however the server will think that the authentication exchange has 492 completed successfully. At this point the client can not abort the 493 authentication exchange; it SHOULD close the connection instead. 494 However, if the profile did not support sending of additional data 495 with success, the client could have aborted the exchange at the very 496 last step of the authentication exchange. 498 6.2.1. Server returns success with additional data examples 500 The following are two examples of a DIGEST-MD5 authentication [SASL- 501 DIGEST] in the XMPP protocol [XMPP]. In the first example below, the 502 server is sending mutual authentication data with success. 504 C: 509 S: 515 S: 516 517 DIGEST-MD5 518 CRAM-MD5 519 520 521 C: 523 S: 524 cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi 525 LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== 526 527 C: 528 dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i 529 T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw 530 MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i 531 LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo 532 YXJzZXQ9dXRmLTgK 534 Internet DRAFT SASL 14 February 2004 536 537 S: 538 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= 539 541 The example below is almost identical to the previous, but here 542 the server chooses not to use the additional data with success. 544 C: 549 S: 555 S: 556 557 DIGEST-MD5 558 CRAM-MD5 559 560 561 C: 563 S: 564 cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi 565 LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== 566 567 C: 568 dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i 569 T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw 570 MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i 571 LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo 572 YXJzZXQ9dXRmLTgK 573 574 S: 575 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= 576 577 C: 578 S: 580 6.3. Multiple authentications 582 Unless otherwise stated by the protocol's profile, only one 583 successful SASL negotiation may occur in a protocol session. In this 585 Internet DRAFT SASL 14 February 2004 587 case, once an authentication protocol exchange has successfully 588 completed, further attempts to initiate an authentication protocol 589 exchange fail. 591 If a profile explicitly permits multiple successful SASL negotiations 592 to occur, then in no case may multiple security layers be 593 simultaneously in effect. If a security layer is in effect and a 594 subsequent SASL negotiation selects a second security layer, then the 595 second security layer replaces the first. If a security layer is in 596 effect and a subsequent SASL negotiation selects no security layer, 597 the original security layer remains in effect. 599 Note that keeping the original security layer is a subject to a class 600 of security attack described in section 6.3.1. However, at the time 601 of the writing of this document the Working Group consensus is not to 602 change SASL handling of security layers, as the risk of such attacks 603 is considered to be low and specific to only certain classes of 604 implementations. The protocol profiles that allow for 605 reauthentication SHOULD recommend that another security layer is 606 negotiated once a security layer was installed. 608 Also note, that if a subsequent authentication fails, the protocol 609 profile MAY allow the connection state to return to non- 610 authenticated, however the previously negotiated security layer MUST 611 NOT be removed. Only a successful reauthentication is able 612 replace/remove the previously negotiated security layer. 614 6.3.1. Description of Multiple Authentication attack 616 Let's assume that the protected resources on a server are partitioned 617 into a set of protection spaces, each with its own authentication 618 mechanisms and/or authorization database. Let's use the term 619 "partition" to reference any such protected space. An example of a 620 partition might be an HTTP "realm". Also a proxy/frontend can use 621 different partitions for different servers/backends it represents. 623 Now consider the following scenario. A client has already 624 authenticated and established a security layer with "Partition A" 625 which is managed by the server AA. Now the same client authenticates 626 to "Partition B" (managed by the server BB) without negotiating a new 627 security layer, while the security layer negotiated with "Partition 628 A" remains in effect. The server BB is now able to observe how known 629 cleartext is encrypted. This scenario enables the server BB to make 630 guesses about previously observed ciphertext between the client and 631 the server AA using the server's SASL engine as an oracle. This 632 scenario is illustrated below: 634 Internet DRAFT SASL 14 February 2004 636 +---------+ +---------+ 637 | | | | 638 |Partition| |Partition| 639 | B | | A | 640 +---------+ +---------+ 641 | ^ | 642 | : +-----------+ | 643 Traffic from | : | Encryption| | Traffic from A 644 B to client +-------->| end point |<-------+ to client 645 : | (SSL/SASL)| 646 : +-----------+ 647 : | 648 : | 649 : +---+ 650 : | | 651 : | | 652 : | | Encryption tunnel, e.g. SASL or SSL, 653 : | | between the server 654 (1) Recording +---------:| | and a single client only. 655 encrypted | | Separate tunnels to different 656 traffic between | | clients. 657 Partition A and client +---+ 658 | 659 | 660 +-----------> Traffic to clients 662 <> 668 7. The EXTERNAL mechanism 670 The mechanism name associated with external authentication is 671 "EXTERNAL". 673 The client sends an initial response with the UTF-8 encoding of the 674 authorization identity. The form of the authorization identity is 675 further restricted by the application-level protocol's SASL profile. 677 The server uses information, external to SASL, to determine whether 678 the client is authorized to authenticate as the authorization 679 identity. If the client is so authorized, the server indicates 680 successful completion of the authentication exchange; otherwise the 682 Internet DRAFT SASL 14 February 2004 684 server indicates failure. 686 The system providing this external information may be, for example, 687 IPSec or TLS. However, the client can make no assumptions as to what 688 information the server can use in determining client authorization. 689 For example, just because TLS was established, doesn't mean that the 690 server will use the information provided by TLS. 692 If the client sends the empty string as the authorization identity, 693 the authorization identity is to be derived from authentication 694 credentials which exist in the system that is providing the external 695 authentication. 697 7.1. Formal syntax 699 The following syntax specification uses the augmented Backus-Naur 700 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core 701 rules as specified in Appendix A of the ABNF specification [ABNF]. 702 Non-terminals referenced but not defined below are as defined by 703 [UTF-8]. 705 The "extern-init-resp" rule below defines the initial response sent 706 from client to server. 708 extern-init-resp = *( UTF8-char-no-nul ) 710 UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4 712 UTF8-1-no-nul = %x01-7F 714 7.2. Example 716 The following is an example of an EXTERNAL authentication in the SMTP 717 protocol [SMTP]. In this example, the client is proxy 718 authenticating, sending the authorization identity "fred" using in 719 the (optional) initial response. The server has determined the 720 client's identity through IPsec and has a security policy that 721 permits that identity to proxy authenticate as any other identity. 723 To the protocol profile, the four octet sequence "fred" is an opaque 724 binary data. The SASL protocol profile for SMTP [SMTP-AUTH] specifies 725 that server challenges and client responses are encoded in BASE64 726 [BASE64]; the BASE64 encoding of "fred" is "ZnJlZA==". 728 S: 220 smtp.example.com ESMTP server ready 729 C: EHLO jgm.example.com 730 S: 250-smtp.example.com 732 Internet DRAFT SASL 14 February 2004 734 S: 250 AUTH DIGEST-MD5 EXTERNAL 735 C: AUTH EXTERNAL ZnJlZA== 736 S: 235 Authentication successful. 738 The following example is almost identical to the one above, but the 739 client doesn't use proxy authentication. 741 S: 220 smtp.example.com ESMTP server ready 742 C: EHLO jgm.example.com 743 S: 250-smtp.example.com 744 S: 250 AUTH DIGEST-MD5 EXTERNAL 745 C: AUTH EXTERNAL 746 S: 235 Authentication successful. 748 8. IANA Considerations 750 8.1. Guidelines for IANA 752 It is requested that IANA updates the SASL mechanisms registry as 753 follows: 755 Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism 756 registrations to OBSOLETE. Change the "Published specification" 757 of the EXTERNAL mechanism to this document. Updated registration 758 is provided in Section 8.6. 760 8.2. Registration procedure 762 Registration of a SASL mechanism is done by filling in the template 763 in section 8.5 and sending it via electronic mail to . 764 IANA has the right to reject obviously bogus registrations, but will 765 perform no review of claims made in the registration form. SASL 766 mechanism registrations are currently available at the URL 767 . 769 There is no naming convention for SASL mechanisms; any name that 770 conforms to the syntax of a SASL mechanism name can be registered. 771 An IETF Standards Track document may reserve a portion of the SASL 772 mechanism namespace ("family of SASL mechanisms") for its own use, 773 amending the registration rules for that portion of the namespace. 774 Each family of SASL mechanisms MUST be identified by a prefix. 776 While the registration procedures do not require it, authors of SASL 778 Internet DRAFT SASL 14 February 2004 780 mechanisms are encouraged to seek community review and comment 781 whenever that is feasible. Authors may seek community review by 782 posting a specification of their proposed mechanism as an Internet- 783 Draft. SASL mechanisms intended for widespread use should be 784 standardized through the normal IETF process, when appropriate. 786 8.3. Comments on SASL mechanism registrations 788 Comments on registered SASL mechanisms should first be sent to the 789 "owner" of the mechanism and/or to the SASL WG mailing list. 790 Submitters of comments may, after a reasonable attempt to contact the 791 owner, request IANA to attach their comment to the SASL mechanism 792 registration itself. If IANA approves of this, the comment will be 793 made accessible in conjunction with the SASL mechanism registration 794 itself. 796 8.4. Change control 798 Once a SASL mechanism registration has been published by IANA, the 799 author may request a change to its definition. The change request 800 follows the same procedure as the registration request. 802 The owner of a SASL mechanism may pass responsibility for the SASL 803 mechanism to another person or agency by informing IANA; this can be 804 done without discussion or review. 806 The IESG may reassign responsibility for a SASL mechanism. The most 807 common case of this will be to enable changes to be made to 808 mechanisms where the author of the registration has died, moved out 809 of contact or is otherwise unable to make changes that are important 810 to the community. 812 SASL mechanism registrations may not be deleted; mechanisms which are 813 no longer believed appropriate for use can be declared OBSOLETE by a 814 change to their "intended use" field; such SASL mechanisms will be 815 clearly marked in the lists published by IANA. 817 The IESG is considered to be the owner of all SASL mechanisms which 818 are on the IETF standards track. 820 8.5. Registration template 822 Subject: Registration of SASL mechanism X 824 Family of SASL mechanisms: (YES or NO) 826 SASL mechanism name (or prefix for the family): 828 Internet DRAFT SASL 14 February 2004 830 Security considerations: 832 Published specification (optional, recommended): 834 Person & email address to contact for further information: 836 Intended usage: 838 (One of COMMON, LIMITED USE or OBSOLETE) 840 Owner/Change controller: 842 (Any other information that the author deems interesting may be 843 added below this line.) 845 8.6. The EXTERNAL mechanism registration 847 It is requested that the SASL Mechanism registry [IANA-SASL] entry 848 for the EXTERNAL mechanism be updated to reflect that this document 849 now provides its technical specification. 851 Subject: Updated Registration of SASL mechanism EXTERNAL 853 Family of SASL mechanisms: NO 855 SASL mechanism name: EXTERNAL 857 Security considerations: See RFC XXXX, section 9. 859 Published specification (optional, recommended): RFC XXXX 861 Person & email address to contact for further information: 862 Alexey Melnikov 864 Intended usage: COMMON 866 Owner/Change controller: IESG 868 Note: Updates existing entry for EXTERNAL 870 9. Security considerations 872 Security issues are discussed throughout this memo. 874 The mechanisms that support integrity protection are designed such 875 that the negotiation of the security layer and authorization identity 877 Internet DRAFT SASL 14 February 2004 879 is integrity protected. When the client selects a security layer 880 with at least integrity protection, this protects against an active 881 attacker hijacking the connection and modifying the authentication 882 exchange to negotiate a plaintext connection. 884 When a server or client supports multiple authentication mechanisms, 885 each of which has a different security strength, it is possible for 886 an active attacker to cause a party to use the least secure mechanism 887 supported. To protect against this sort of attack, a client or 888 server which supports mechanisms of different strengths should have a 889 configurable minimum strength that it will use. It is not sufficient 890 for this minimum strength check to only be on the server, since an 891 active attacker can change which mechanisms the client sees as being 892 supported, causing the client to send authentication credentials for 893 its weakest supported mechanism. 895 The client's selection of a SASL mechanism is done in the clear and 896 may be modified by an active attacker. It is important for any new 897 SASL mechanisms to be designed such that an active attacker cannot 898 obtain an authentication with weaker security properties by modifying 899 the SASL mechanism name and/or the challenges and responses. 901 In order to detect Man-in-the-middle (MITM) attacks the client MAY 902 list available SASL mechanisms both before and after the SASL 903 security layer is negotiated. This allows the client to detect 904 active attacks that remove mechanisms from the server's list of 905 supported mechanisms, and allows the client to ensure that it is 906 using the best mechanism supported by both client and server. New 907 protocol profiles SHOULD require servers to make the list of SASL 908 mechanisms available for the initial authentication available to the 909 client after security layers are established. Some older protocols 910 do not require this (or don't support listing of SASL mechanisms once 911 authentication is complete); for these protocols clients MUST NOT 912 treat an empty list of SASL mechanisms after authentication as a MITM 913 attack. 915 Any protocol interactions prior to authentication are performed in 916 the clear and may be modified by an active attacker. In the case 917 where a client selects integrity protection, it is important that any 918 security-sensitive protocol negotiations be performed after 919 authentication is complete. Protocols should be designed such that 920 negotiations performed prior to authentication should be either 921 ignored or revalidated once authentication is complete. 923 When use of a security layer is negotiated by the authentication 924 protocol exchange, the receiver should handle gracefully any security 925 encoded data buffer larger than the defined/negotiated maximal size. 926 In particular, it must not blindly allocate the amount of memory 928 Internet DRAFT SASL 14 February 2004 930 specified in the buffer size field, as this might cause the "out of 931 memory" condition. If the receiver detects a large block, it SHOULD 932 close the connection. 934 Distributed server implementations need to be careful in how they 935 trust other parties and, in particular, authentication secrets should 936 only be disclosed to other parties that are trusted to manage and use 937 those secrets in manner acceptable to disclosing party. It should be 938 noted that, where those secrets are used to provide data 939 confidentiality protections, if a third party (other than the 940 discloser/disclosee) has knowledge of some portion of the protected 941 information, it can use this knowledge in an attack upon other 942 portions of the protected information. 944 Section 6.3.1 contains a description of a potential class of attack 945 on a distributed server implementation. The section also gives some 946 recommendations about mitigating such attacks. 948 "stringprep" and Unicode security considerations apply to 949 authentication identities, authorization identities and passwords. 951 The EXTERNAL mechanism provides no security protection; it is 952 vulnerable to spoofing by either client or server, active attack, and 953 eavesdropping. It should only be used when external security 954 mechanisms are present and have sufficient strength. 956 10. References 958 10.1. Normative References 960 [ABNF] Crocker, D. (Ed.), Overell, P., "Augmented BNF for Syntax 961 Specifications: ABNF", RFC 2234, November 1997 963 [ASCII] American National Standards Institute, "Code Extension 964 Techniques for Use with the 7-bit Coded Character Set of American 965 National Standard Code (ASCII) for Information Interchange", FIPS PUB 966 35, 1974 968 [CHARSET-POLICY] Alvestrand, H., "IETF Policy on Character Sets and 969 Languages", RFC 2277, BCP 18, January 1998 971 [GSSAPI] Linn, J., "Generic Security Service Application Program 972 Interface, Version 2, Update 1", RFC 2743, January 2000 974 [ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) - 975 Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993. 977 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 979 Internet DRAFT SASL 14 February 2004 981 Requirement Levels", RFC 2119, BCP 19, March 1997 983 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 984 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, 985 MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the 986 "Unicode Standard Annex #27: Unicode 3.1" 987 (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard 988 Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/). 990 [Stringprep] Hoffman, P., Blanchet, M., "Preparation of 991 Internationalized Strings ("stringprep")", RFC 3454, December 2002. 993 [SASLprep] Zeilenga, K., "SASLprep: Stringprep profile for user names 994 and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt. 996 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 997 RFC 3629, STD 63, November 2003. 999 10.2. Informative References 1001 [SASL-GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", work in 1002 progress, draft-ietf-sasl-gssapi-XX.txt, November 2003 1004 [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest 1005 Authentication as a SASL Mechanism", work in progress, draft-ietf- 1006 sasl-rfc2831bis-XX.txt, replaces RFC 2831 1008 [SASL-OTP] Newman, C., "The One-Time-Password SASL Mechanism", RFC 1009 2444, October 1998. 1011 [SASL-SECURID] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 1012 2808, April 2000. 1014 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 1015 2001. 1017 [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", 1018 RFC 2554, March 1999. 1020 Being revised by Siemborski, R., "SMTP Service Extension for 1021 Authentication", work in progress, draft-siemborski-rfc2554bis- 1022 XX.txt. 1024 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol 1025 (XMPP): Core", work in progress, draft-ietf-xmpp-core-XX.txt. 1027 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 1029 Internet DRAFT SASL 14 February 2004 1031 Encodings", RFC 3548, July 2003. 1033 [RFC-INSTRUCTIONS] Postel, J., Reynolds, J., "Instructions to RFC 1034 Authors", RFC 2223, October 1997. 1036 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) 1037 MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms. 1039 11. Editor's Address 1041 Alexey Melnikov 1042 Isode Limited 1044 Email: Alexey.Melnikov@isode.com 1046 12. Acknowledgments 1048 This document is a revision of RFC 2222 written by John G. Myers. He 1049 also contributed significantly to this revision. 1051 Magnus Nystrom provided the ASCII art used in Section 6.3. 1053 Definition of partition was extracted from RFC 2617 ("HTTP 1054 Authentication: Basic and Digest Access Authentication"). 1056 Contributions of many members of the SASL mailing list are gratefully 1057 acknowledged, in particular Kurt D. Zeilenga, Peter Saint-Andre, Rob 1058 Siemborski, Jeffrey Hutzelman, Hallvard B Furuseth, Tony Hansen and 1059 Abhijit Menon-Sen for proofreading the document and various editorial 1060 suggestions. 1062 13. Full Copyright Statement 1064 Copyright (C) The Internet Society (2004). All Rights Reserved. 1066 This document and translations of it may be copied and furnished to 1067 others, and derivative works that comment on or otherwise explain it 1068 or assist in its implementation may be prepared, copied, published 1069 and distributed, in whole or in part, without restriction of any 1070 kind, provided that the above copyright notice and this paragraph are 1071 included on all such copies and derivative works. However, this 1072 document itself may not be modified in any way, such as by removing 1073 the copyright notice or references to the Internet Society or other 1074 Internet organizations, except as needed for the purpose of 1075 developing Internet standards in which case the procedures for 1076 copyrights defined in the Internet Standards process must be 1077 followed, or as required to translate it into languages other than 1079 Internet DRAFT SASL 14 February 2004 1081 English. 1083 The limited permissions granted above are perpetual and will not be 1084 revoked by the Internet Society or its successors or assigns. 1086 This document and the information contained herein is provided on an 1087 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1088 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1089 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1090 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1091 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1093 Acknowledgement 1095 Funding for the RFC Editor function is currently provided by the 1096 Internet Society. 1098 Appendix A. Relation of SASL to transport security 1100 Questions have been raised about the relationship between SASL and 1101 various services (such as IPsec and TLS) which provide a secured 1102 connection. 1104 Two of the key features of SASL are: 1106 The separation of the authorization identity from the identity in 1107 the client's credentials. This permits agents such as proxy 1108 servers to authenticate using their own credentials, yet request 1109 the access privileges of the identity for which they are proxying. 1111 Upon successful completion of an authentication exchange, the 1112 server knows the authorization identity the client wishes to use. 1113 This allows servers to move to a "user is authenticated" state in 1114 the protocol. 1116 These features are extremely important to some application protocols, 1117 yet Transport Security services do not always provide them. To 1118 define SASL mechanisms based on these services would be a very messy 1119 task, as the framing of these services would be redundant with the 1120 framing of SASL and some method of providing these important SASL 1121 features would have to be devised. 1123 Sometimes it is desired to enable within an existing connection the 1124 use of a security service which does not fit the SASL model. (TLS is 1125 an example of such a service.) This can be done by adding a command, 1126 for example "STARTTLS", to the protocol. Such a command is outside 1127 the scope of SASL, and should be different from the command which 1128 starts a SASL authentication protocol exchange. 1130 Internet DRAFT SASL 14 February 2004 1132 In certain situations, it is reasonable to use SASL underneath one of 1133 these Transport Security services. The transport service would 1134 secure the connection, either service would authenticate the client, 1135 and SASL would negotiate the authorization identity. The SASL 1136 negotiation would be what moves the protocol from "unauthenticated" 1137 to "authenticated" state. The "EXTERNAL" SASL mechanism is 1138 explicitly intended to handle the case where the transport service 1139 secures the connection and authenticates the client and SASL 1140 negotiates the authorization identity. 1142 Appendix B. Changes since RFC 2222 1144 The GSSAPI mechanism was removed. It is now specified in a separate 1145 document [SASL-GSSAPI]. 1147 The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has 1148 been removed. 1150 The "SKEY" mechanism described in RFC 2222 is obsolete and has been 1151 removed. It has been replaced by the OTP mechanism [SASL-OTP]. 1153 The overview has been substantially reorganized and clarified. 1155 Clarified the definition and semantics of the authorization identity. 1157 Prohibited the NUL character in authorization identities. 1159 Added a section on character string issues. 1161 The word "must" in the first paragraph of the "Protocol profile 1162 requirements" section was changed to "MUST". 1164 Specified that protocol profiles SHOULD provide a way for clients to 1165 discover available SASL mechanisms. 1167 Made the requirement that protocol profiles specify the semantics of 1168 the authorization identity optional to the protocol profile. 1169 Clarified that such a specification is a refinement of the definition 1170 in the base SASL spec. 1172 Added a requirement discouraging protocol profiles from breaking the 1173 separation between protocol and mechanism. 1175 Mentioned that standards track documents may carve out their own 1176 portions of the SASL mechanism namespace and may amend registration 1177 rules for the portion. However registration of individual SASL 1178 mechanisms is still required. 1180 Internet DRAFT SASL 14 February 2004 1182 Specified that the authorization identity in the EXTERNAL mechanism 1183 is encoded in UTF-8. 1185 Added a statement that a protocol profile SHOULD allow challenge data 1186 to be sent with a success indication. 1188 Added a security consideration for the EXTERNAL mechanism. 1190 Clarified sections concerning success with additional data. 1192 Cleaned up IANA considerations/registrations and assembled them in 1193 one place. 1195 Updated references and split them into Informative and Normative. 1197 Added text to the Security Considerations section regarding handling 1198 of extremely large SASL blocks. 1200 Replaced UTF-8 ABNF with the reference to the UTF-8 document. 1202 Added text about SASLprep for authentication identities and 1203 passwords. Described where SASLprep preparation should take place. 1205 Added paragraph about verifying authorization identities. 1207 Added a protocol profile requirement to specify interaction between 1208 SASL and TLS security layers. 1210 Added a protocol profile requirement to specify if it supports 1211 reauthentication. 1213 Removed the text that seemed to suggest that SASL security layer must 1214 not be used when TLS is available. 1216 Created two subsections in 4.2 to talk separately about proxy 1217 authorization and format of the authorization identities. 1219 Made requirement to verify that an authorization identity is correct 1220 by performing SASLprep a SHOULD, instead of a MUST. 1222 Clarified that each SASL mechanism must decide where SASLprep is 1223 taking place. 1225 Added 4 new examples for initial response and additional data with 1226 success. 1228 Added text on checking the list of available SASL mechanisms after 1229 negotiating a security layer. 1231 Internet DRAFT SASL 14 February 2004 1233 Added definition of "integrity protection" and "confidentiality 1234 protection". 1236 Added warning about negotiating no layer once a security layer is 1237 negotiated. 1239 Added new section with guidelines to a SASL mechanism designer. 1241 Added a requirement to specify how an empty initial challenge is 1242 encoded if initial response is supported by a protocol. 1244 Internet DRAFT SASL 14 February 2004 1246 Status of this Memo .......................................... i 1247 1. Abstract ............................................... 2 1248 2. Organization of this document .......................... 2 1249 2.1. How to read this document .............................. 2 1250 2.2. Conventions used in this document ...................... 2 1251 3. Overview ............................................... 3 1252 4. Authentication mechanisms .............................. 3 1253 4.1. Authentication protocol exchange ....................... 4 1254 4.2. Authorization and authentication identities ............ 4 1255 4.2.1. Authorization identities and proxy authentication .... 5 1256 4.2.2. Authorization Identity Format ........................ 6 1257 4.3. Security layers ........................................ 6 1258 4.4. Character string issues ................................ 7 1259 5. Protocol profile requirements .......................... 7 1260 5. Protocol and mechanism profiles ........................ 7 1261 5.1. Protocol profile requirements .......................... 7 1262 5.2. Mechanism profile guidelines ........................... 8 1263 6. Specific issues ........................................ 9 1264 6.1. Client sends data first ................................ 9 1265 6.1.1. Examples ............................................. 9 1266 6.2. Server returns success with additional data ........... 10 1267 6.2.1. Examples ............................................ 10 1268 6.3. Multiple authentications .............................. 12 1269 6.3.1. Description of Multiple Authentication attack ....... 13 1270 7. The EXTERNAL mechanism ................................ 14 1271 7.1. Formal syntax ......................................... 15 1272 7.2. Example ............................................... 15 1273 8. IANA Considerations ................................... 15 1274 8.1. Guidelines for IANA ................................... 16 1275 8.2. Registration procedure ................................ 16 1276 8.3. Comments on SASL mechanism registrations .............. 16 1277 8.4. Change control ........................................ 17 1278 8.5. Registration template ................................. 17 1279 8.6. The EXTERNAL mechanism registration ................... 18 1280 9. Security considerations ................................ 18 1281 10. References ........................................... 20 1282 10.1. Normative References ................................. 20 1283 10.2. Informative References ............................... 21 1284 11. Editor's Address ...................................... 21 1285 12. Acknowledgments ....................................... 22 1286 13. Full Copyright Statement .............................. 22 1287 Appendix A. Relation of SASL to transport security .......... 23 1288 Appendix B. Changes since RFC 2222 .......................... 24