idnits 2.17.1 draft-ietf-sasl-rfc2222bis-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1095. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1102. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1108. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1053), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 1053. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 27 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages -- Found 28 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 : ---------------------------------------------------------------------------- == 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 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 (March 2004) is 7339 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 387, but not defined ** Obsolete undefined reference: RFC 3501 (Obsoleted by RFC 9051) == Missing Reference: 'StringPrep' is mentioned on line 425, but not defined == Unused Reference: 'Stringprep' is defined on line 969, but no explicit reference was found in the text == Unused Reference: 'BASE64' is defined on line 1008, but no explicit reference was found in the text == Unused Reference: 'RFC-INSTRUCTIONS' is defined on line 1011, 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. '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 3548 (ref. 'BASE64') (Obsoleted by RFC 4648) -- Obsolete informational reference (is this intentional?): RFC 2223 (ref. 'RFC-INSTRUCTIONS') (Obsoleted by RFC 7322) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'IPSec') (Obsoleted by RFC 4301) Summary: 13 errors (**), 0 flaws (~~), 11 warnings (==), 20 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-07.txt March 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 31 March 2004 38 Abstract 40 The Simple Authentication and Security Layer (SASL) is a framework 41 for providing authentication and data security services in 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 SASL EXTERNAL authentication mechanism. 53 1. Organization of this document 55 1.1. How to read this document 57 This document is written to serve several different audiences 59 o) protocol designers using this specification to support 60 authentication in their protocol 62 o) mechanism designers that define new SASL mechanisms 64 o) implementors of clients or servers for those protocols using this 65 specification. 67 The sections "Overview", "Authentication Mechanisms", "Protocol 68 Profile Requirements", "Specific Issues", and "Security 69 Considerations" cover issues that protocol designers need to 70 understand and address in profiling this specification for use in a 71 specific protocol. 73 The sections "Overview", "Authentication Mechanisms", "Mechanism 74 Profile Requirements", "Security Considerations" and "Registration 75 procedure" cover issues that mechanism designers need to understand 76 and address in designing new SASL mechanisms. 78 The sections "Overview", "Authentication Mechanisms", "Protocol 79 profile requirements", "Specific issues" and "Security 80 Considerations" cover issues that implementors of a protocol that 81 uses SASL framework need to understand. The implementors will also 82 need to understand a specification of a profile specific to the 83 protocol, as well as aspects of mechanism specifications they intend 84 to use (regardless of whether they are implementing the mechanisms 85 themselves or using an existing implementation) to understand, for 87 Internet DRAFT SASL 31 March 2004 89 instance, the mechanism specific authentication identity forms, the 90 offered services, and security and other considerations. 92 1.2. Conventions used in this document 94 In examples, "C:" and "S:" indicate lines sent by the client and 95 server respectively. 97 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 98 in this document are to be interpreted as defined in "Key words for 99 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 101 Character names in this document use the notation for code points and 102 names from the Unicode Standard [Unicode]. For example, the letter 103 "a" may be represented as either or . 105 This document uses terms "integrity protection" and "confidentiality 106 protection". The former refers to a security layer designed to detect 107 unauthorized data modification. However, integrity protection 108 doesn't make the data unreadable to an attacker. Confidentiality 109 protection is a security layer that is able to make the data 110 unreadable to an attacker by using encryption. Confidentiality 111 protection usually implies integrity protection. Security layers may 112 offer other kinds of security services. 114 2. Overview 116 The Simple Authentication and Security Layer (SASL) is a method for 117 adding authentication support to connection-based protocols. 119 The SASL specification has three layers, as indicated in the diagram 120 below. At the top, a protocol definition using SASL specifies a 121 profile, including a command for identifying and authenticating a 122 user to a server and for optionally negotiating a security layer for 123 subsequent protocol interactions. At the bottom, a SASL mechanism 124 definition specifies an authentication mechanism. The SASL 125 framework, specified by this document, constrains the behavior of 126 protocol profiles and mechanisms, separating protocol from mechanism 127 and defining how they interact. 129 SMTP Protocol LDAP Protocol Etc 130 Profile Profile . . . 131 \----- | -----/ 132 \ | / 133 SASL framework 134 / | \ 135 /----- | -----\ 137 Internet DRAFT SASL 31 March 2004 139 EXTERNAL DIGEST-MD5 Etc 140 SASL mechanism SASL mechanism . . . 142 This separation between the definition of protocols and the 143 definition of authentication mechanisms is crucial. It permits an 144 authentication mechanism to be defined once, making it usable by any 145 SASL protocol profile. In many implementations, the same SASL 146 mechanism code is used for multiple protocols. 148 3. Authentication mechanisms 150 SASL mechanisms are named by strings, from 1 to 20 characters in 151 length, consisting of ASCII [ASCII] upper-case letters, digits, 152 hyphens, and/or underscores. Names of SASL mechanisms or families of 153 mechanisms must be registered with the Internet Assigned Numbers 154 Authority (IANA) as described in section 8.2. 156 The "sasl-mech" ABNF production below defines the syntax of a SASL 157 mechanism name. This uses the Augmented Backus-Naur Form (ABNF) 158 notation as specified in [ABNF]. 160 sasl-mech = 1*20mech-char 161 mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE 162 ; mech-char is restricted to "A"-"Z", "0"-"9", "-", 163 ; and "_" from ASCII character set. 165 UPPER-ALPHA = %x41-5A 166 ; "A"-"Z" 168 DIGIT = %x30-39 169 ; "0"-"9" 171 HYPHEN = %x2D 172 ; "-" 174 UNDERSCORE = %x5F 175 ; "_" 177 3.1. Authentication protocol exchange 179 A SASL mechanism is responsible for conducting an authentication 180 protocol exchange. This consists of a series of server challenges 181 and client responses, the contents of which are specific to and 182 defined by the mechanism. To the protocol, the challenges and 183 responses are opaque binary tokens of arbitrary length. The 184 protocol's profile then specifies how these binary tokens are then 185 encoded for transfer over the connection. 187 Internet DRAFT SASL 31 March 2004 189 After receiving an authentication command or any client response, a 190 server mechanism may issue a challenge, indicate failure, or indicate 191 completion. The server mechanism may return additional data with a 192 completion indication. The protocol's profile specifies how each of 193 these is then represented over the connection. 195 After receiving a challenge, a client mechanism may issue a response 196 or abort the exchange. The protocol's profile specifies how each of 197 these are then represented over the connection. 199 During the authentication protocol exchange, the mechanism performs 200 authentication, transmits an authorization identity (frequently known 201 as a userid) from the client to server, and negotiates the use of a 202 mechanism-specific security layer. If the use of a security layer is 203 agreed upon, then the mechanism must also define or negotiate the 204 maximum security layer buffer size that each side is able to receive. 206 3.2. Authorization and authentication identities 208 SASL authentication deals with two identities: the authentication 209 identity, derived from the client's authentication credentials; and 210 the authorization identity, which is the result of SASL processing 211 and is used by the server as the primary identity for making access 212 policy decisions. 214 The processing model is as follows. A server, upon completion of the 215 authentication mechanism, uses the results produced by the 216 authentication mechanism, the client-provided authorization identity 217 value (which may be the empty string), and local policy information 218 to derive an authorization identity. The authorization identity is 219 made available to further server processing for use in making access 220 policy decisions. The provision of additional client attributes that 221 may affect access policy is not covered by this specification. 223 The authorization identity may be an empty (zero length) string. In 224 this case, the server derives an authorization identity from the 225 client's authentication identity. 227 A mechanism which is incapable of transmitting an authorization 228 identity must be treated as if it always transmits an authorization 229 identity of an empty string. 231 Any normalization of the authentication identity is defined by a 232 particular SASL mechanism, the protocol profile doesn't influence it. 234 The mechanism MUST preserve Unicode codepoint when transferring 235 authorization identity (e.g. the mechanism cann't apply any form of 236 normalization). 238 Internet DRAFT SASL 31 March 2004 240 3.2.1. Authorization identities and proxy authentication 242 If the authorization identity transmitted during the authentication 243 protocol exchange is not the empty string, this is typically referred 244 to as "proxy authentication". This feature permits agents such as 245 proxy servers to authenticate using their own credentials, yet 246 request the access privileges of the identity for which they are 247 proxying. 249 The server makes an implementation defined policy decision as to 250 whether the authentication identity is permitted to have the access 251 privileges of the authorization identity and whether the 252 authorization identity is permitted to receive service. If it is 253 not, the server indicates failure of the authentication protocol 254 exchange. 256 As a client might not have the same information as the server, 257 clients SHOULD NOT derive authorization identities from 258 authentication identities. Instead, clients SHOULD provide no (or 259 empty) authorization identity when the user has not provided an 260 authorization identity. 262 The server SHOULD verify that a received authorization identity is in 263 the correct form. Protocol profiles whose authorization identities 264 are simple user names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep" 265 profile [SASLprep] of the "stringprep" algorithm [StringPrep] to 266 prepare these names for matching. The profiles MAY use a stringprep 267 profile that is more strict than "SASLprep". If the preparation of 268 the authorization identity fails or results in an empty string, the 269 server MUST fail the authentication exchange. The only exception to 270 this rule is when the received authorization identity is already the 271 empty string. 273 3.2.2. Authorization Identity Format 275 An authorization identity is a string of zero or more Unicode 276 [Unicode] coded characters. The NUL character is not 277 permitted in authorization identities. 279 The character encoding scheme used for transmitting an authorization 280 identity over the protocol is specified in each authentication 281 mechanism. All IETF-defined mechanisms MUST, and all other 282 mechanisms SHOULD, use UTF-8 [UTF-8]. (See [CHARSET-POLICY] for IETF 283 policy regarding character sets and encoding schemes.) 285 Mechanisms are expected to be capable of carrying the entire Unicode 286 repertoire (with the exception of the NUL character). An 287 authorization identity of the empty string and an absent 289 Internet DRAFT SASL 31 March 2004 291 authorization identity MUST be treated as equivalent. A mechanism 292 which provides an optional field for an authorization identity, 293 SHOULD NOT allow that field, when present, to be empty. The meaning 294 of the empty string as an authorization identity is described in the 295 previous section. 297 3.3. Security layers 299 If use of a security layer is negotiated by the authentication 300 protocol exchange, the security layer is applied to all subsequent 301 data sent over the connection (until another security layer is 302 negotiated; see also section 6.3). The security layer takes effect 303 immediately following the last response of the authentication 304 exchange for data sent by the client and the completion indication 305 for data sent by the server. The exact position MUST be defined by 306 the protocol profile (see section 4 part 5). 308 Note that all SASL mechanisms that are unable to negotiate a security 309 layer automatically select no security layer. 311 Once the security layer is in effect the protocol stream is processed 312 by the security layer into buffers of security encoded data. Each 313 buffer of security encoded data is transferred over the connection as 314 a stream of octets prepended with a four octet field in network byte 315 order that represents the length of the following buffer. The length 316 of the security encoded data buffer MUST be no larger than the 317 maximum size that was either defined in the mechanism specification 318 or negotiated by the other side during the authentication protocol 319 exchange. Upon the receipt of a data buffer which is larger than the 320 defined/negotiated maximal buffer size the receiver SHOULD close the 321 connection. This might be a sign of an attack or a buggy 322 implementation. 324 4. Protocol profile requirements 326 In order to use this specification, a protocol definition MUST supply 327 the following information: 329 1) A service name, to be selected from the IANA registry of "service" 330 elements for the GSSAPI host-based service name form [GSSAPI]. This 331 service name is made available to the authentication mechanism. 333 The registry is available at the URL 334 . 336 2) A definition of the command to initiate the authentication 337 protocol exchange. This command must have as a parameter the name of 338 the mechanism being selected by the client. 340 Internet DRAFT SASL 31 March 2004 342 The command SHOULD have an optional parameter giving an initial 343 response. If the protocol allows for the initial response, the 344 protocol profile SHOULD also describe how an empty initial response 345 is encoded. This optional parameter allows the client to avoid a 346 round trip when using a mechanism which is defined to have the client 347 send data first. When this initial response is sent by the client 348 and the selected mechanism is defined to have the server start with 349 an initial challenge, the command fails. See section 6.1 of this 350 document for further information. 352 3) A definition of the method by which the authentication protocol 353 exchange is carried out, including how the challenges and responses 354 are encoded, how the server indicates completion or failure of the 355 exchange, how the client aborts an exchange, and how the exchange 356 method interacts with any line length limits in the protocol. 358 The exchange method SHOULD allow the server to include an optional 359 data ("optional challenge") with a success notification. This allows 360 the server to avoid a round trip when using a mechanism which is 361 defined to have the server send additional data along with the 362 indication of successful completion. See section 6.2 of this 363 document for further information. 365 4) A protocol profile SHOULD specify a mechanism through which a 366 client may obtain the names of the SASL mechanisms available to it. 367 This is typically done through the protocol's extensions or 368 capabilities mechanism. 370 5) Identification of the octet where any negotiated security layer 371 starts to take effect, in both directions. 373 6) Specify if the protocol profile supports "multiple 374 authentications" (see section 6.3). 376 7) If both a Transport Layer Security [TLS] and a SASL security layer 377 are allowed to be negotiated by the protocol, the protocol profile 378 MUST define in which order they are applied to a cleartext data sent 379 over the connection. 381 8) A protocol profile MAY further refine the definition of an 382 authorization identity by adding additional syntactic restrictions 383 and protocol-specific semantics. A protocol profile MUST specify the 384 form of the authorization identity (since it is protocol specific, as 385 opposed to the authentication identity, which is mechanism specific) 386 and how authorization identities are to be compared. Profiles whose 387 authorization identities are simple user names (e.g. IMAP [RFC 3501]) 388 SHOULD use "SASLprep" profile [SASLprep] of the "stringprep" 389 algorithm [StringPrep] to prepare these names for matching. The 391 Internet DRAFT SASL 31 March 2004 393 profiles MAY use a stringprep profile that is more strict than 394 SASLprep. 396 A protocol profile SHOULD NOT attempt to amend the definition of 397 mechanisms or make mechanism-specific encodings. This breaks the 398 separation between protocol and mechanism that is fundamental to the 399 design of SASL. Likewise, SASL mechanisms SHOULD be profile neutral. 401 5. Mechanism profile guidelines 403 Designers of new SASL mechanism should be aware of the following 404 issues: 406 1) Authorization identity 408 While some legacy mechanisms are incapable of transmitting an 409 authorization identity (which means that for these mechanisms the 410 authorization identity is always the empty string), newly defined 411 mechanisms SHOULD be capable of transmitting a non-empty 412 authorization identity. See also section 3.2. 414 2) Character string issues 416 Authentication mechanisms SHOULD encode character strings in UTF-8 417 [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character 418 sets in IETF protocols). In order to avoid interoperability problems 419 due to differing normalizations, when a mechanisms specifies that 420 character data is to be used as input to a cryptographic and/or 421 comparison function, the mechanism specification MUST detail how the 422 data is to be represented, including any normalizations or other 423 preparations, to ensure proper function. Designers of mechanisms 424 SHOULD use the "SASLprep" profile [SASLprep] of the "stringprep" 425 algorithm [StringPrep] where applicable. However it should be noted 426 that this rule doesn't apply to authorization identities, as they are 427 protocol specific. 429 The preparation can be potentially performed on the client end (upon 430 getting user input or retrieving a value from configuration) or on 431 the server end (upon receiving the value from the client, retrieving 432 a value from its authentication database or generating a new value in 433 order to store in in the authentication database). SASL mechanisms 434 must define which entity (or entities) must perform the preparation. 435 If preparation fails or results in an empty string, the entity doing 436 the preparation MUST fail the authentication exchange. 438 Implementation note: A server end can be represented by multiple 439 processes. For example, it may consist of the server process itself 441 Internet DRAFT SASL 31 March 2004 443 that communicated with a client, and a command line utility (a server 444 agent) that is able to store passwords/hashes in a database that can 445 be later used by the server. For the server agent the requirement to 446 "fail the authentication exchange" should be interpreted as a 447 requirement to refuse to store the data in the database. 449 3) If the underlying cryptographic technology used by a mechanism 450 supports data integrity than the mechanism specification MUST 451 integrity protect the transmission of an authorization identity and 452 the negotiation of the security layer. 454 4) <> 462 6. Specific issues 464 6.1. Client sends data first 466 Some mechanisms specify that the first data sent in the 467 authentication protocol exchange is from the client to the server. 469 If a protocol's profile permits the command which initiates an 470 authentication protocol exchange to contain an initial client 471 response, this parameter SHOULD be used with such mechanisms. 473 If the initial client response parameter is not given, or if a 474 protocol's profile does not permit the command which initiates an 475 authentication protocol exchange to contain an initial client 476 response, then the server issues a challenge with no data. The 477 client's response to this challenge is then used as the initial 478 client response. (The server then proceeds to send the next 479 challenge, indicates completion, or indicates failure.) 481 6.1.1. Client sends data first examples 483 The following are two examples of an SECURID authentication [SASL- 484 SECURID] in the SMTP protocol [SMTP]. In the first example below, 485 the client is trying fast reauthentication by sending the initial 486 response: 488 S: 220-smtp.example.com ESMTP Server 490 Internet DRAFT SASL 31 March 2004 492 C: EHLO client.example.com 493 S: 250-smtp.example.com Welcome client.example.com 494 S: 250-AUTH GSSAPI SECURID 495 S: 250 DSN 496 C: AUTH SECURID AG1hZ251cwAxMjM0NTY3OAA= 497 S: 235 Authentication successful 499 The example below is almost identical to the previous, but here the 500 client chooses not to use the initial response parameter. 502 S: 220-smtp.example.com ESMTP Server 503 C: EHLO client.example.com 504 S: 250-smtp.example.com Welcome client.example.com 505 S: 250-AUTH GSSAPI SECURID 506 S: 250 DSN 507 C: AUTH SECURID 508 S: 334 509 C: AG1hZ251cwAxMjM0NTY3OAA= 510 S: 235 Authentication successful 512 Additonal examples that show usage of initial response can be found 513 in section 7.2. 515 6.2. Server returns success with additional data 517 Some mechanisms may specify that additional data be sent to the 518 client along with an indication of successful completion of the 519 exchange. This data would, for example, authenticate the server to 520 the client. 522 If a protocol's profile does not permit this additional data to be 523 returned with a success indication, then the server issues the data 524 as a server challenge, without an indication of successful 525 completion. The client then responds with no data. After receiving 526 this empty response, the server then indicates successful completion 527 (with no additional data). 529 Client implementors should be aware of an additional failure case 530 that might occur when the profile supports sending the additional 531 data with success. Imagine that an active attacker is trying to 532 impersonate the server and sends faked data, which should be used to 533 authenticate the server to the client, with success. (A similar 534 situation can happen when either the server and/or the client has a 535 bug and they calculate different responses.) After checking the data, 536 the client will think that the authentication exchange has failed, 537 however the server will think that the authentication exchange has 538 completed successfully. At this point the client can not abort the 540 Internet DRAFT SASL 31 March 2004 542 authentication exchange; it SHOULD close the connection instead. 543 However, if the profile did not support sending of additional data 544 with success, the client could have aborted the exchange at the very 545 last step of the authentication exchange. 547 6.2.1. Server returns success with additional data examples 549 The following are two examples of a DIGEST-MD5 authentication [SASL- 550 DIGEST] in the Extensible Messaging and Presence Protocol [XMPP]. In 551 the first example below, the server is sending mutual authentication 552 data with success. 554 C: 559 S: 565 S: 566 567 DIGEST-MD5 568 CRAM-MD5 569 570 571 C: 573 S: 574 cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9 575 ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== 576 577 C: 578 dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i 579 T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw 580 MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i 581 LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo 582 YXJzZXQ9dXRmLTgK 583 584 S: 585 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= 586 588 The example below is almost identical to the previous, but here 590 Internet DRAFT SASL 31 March 2004 592 the server chooses not to use the additional data with success. 594 C: 599 S: 605 S: 606 607 DIGEST-MD5 608 CRAM-MD5 609 610 611 C: 613 S: 614 cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9 615 ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== 616 617 C: 618 dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i 619 T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw 620 MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i 621 LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo 622 YXJzZXQ9dXRmLTgK 623 624 S: 625 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= 626 627 C: 628 S: 630 6.3. Multiple authentications 632 Unless otherwise stated by the protocol's profile, only one 633 successful SASL negotiation may occur in a protocol session. In this 634 case, once an authentication protocol exchange has successfully 635 completed, further attempts to initiate an authentication protocol 636 exchange fail. 638 If a profile explicitly permits multiple successful SASL negotiations 639 to occur, then in no case may multiple security layers be 641 Internet DRAFT SASL 31 March 2004 643 simultaneously in effect. If a security layer is in effect and a 644 subsequent SASL negotiation selects a second security layer, then the 645 second security layer replaces the first. If a security layer is in 646 effect and a subsequent SASL negotiation selects no security layer, 647 the original security layer remains in effect. 649 Where a protocol profile permits multiple successful SASL 650 negotiations, the profile MUST detail the effect of a failed SASL 651 negotiation upon the previously established authentication state. 652 In particular, it MUST state whether the previously established 653 authenticated state remain in force or whether the connection is to 654 revert to an non-authenticated state. Regardless of the specified 655 effect upon authentication state, the previously negotiated security 656 layer remains in effect. 658 7. The EXTERNAL mechanism 660 The mechanism name associated with external authentication is 661 "EXTERNAL". 663 The client sends an initial response with the UTF-8 encoding of the 664 authorization identity. The form of the authorization identity is 665 further restricted by the application-level protocol's SASL profile. 667 The server uses information, external to SASL, to determine whether 668 the client is permitted to authenticate as the authorization 669 identity. If the client is so authorized, the server indicates 670 successful completion of the authentication exchange; otherwise the 671 server indicates failure. 673 The system providing this external information may be, for example, 674 IPSec [IPSec] or TLS [TLS]. However, the client can make no 675 assumptions as to what information the server can use in determining 676 client authorization. For example, just because TLS was established, 677 doesn't mean that the server will use the information provided by 678 TLS. 680 If the client sends the empty string as the authorization identity, 681 the authorization identity is to be derived from authentication 682 credentials which exist in the system that is providing the external 683 authentication. 685 7.1. Formal syntax 687 The following syntax specification uses the augmented Backus-Naur 688 Form (BNF) notation as specified in [ABNF]. Non-terminals referenced 689 but not defined below are as defined by [UTF-8]. 691 Internet DRAFT SASL 31 March 2004 693 The "extern-init-resp" rule below defines the initial response sent 694 from client to server. 696 extern-init-resp = *( UTF8-char-no-nul ) 698 UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4 700 UTF8-1-no-nul = %x01-7F 702 7.2. Examples of SASL EXTERNAL 704 The following is an example of an EXTERNAL authentication in the SMTP 705 protocol [SMTP]. In this example, the client is proxy authenticating, 706 sending the authorization identity "fred" using in the (optional) 707 initial response. The server has obtained the client's 708 (authentication) identity from an external service, such as IPsec, 709 and has a security policy that permits that identity to assume the 710 identity of the asserted authorization identity. 712 To the protocol profile, the four octet sequence "fred" is an opaque 713 binary data. The SASL protocol profile for SMTP [SMTP-AUTH] specifies 714 that server challenges and client responses are encoded in BASE64 715 [BASE64, section 3]; the BASE64 encoding of "fred" is "ZnJlZA==". 717 S: 220 smtp.example.com ESMTP server ready 718 C: EHLO jgm.example.com 719 S: 250-smtp.example.com 720 S: 250 AUTH DIGEST-MD5 EXTERNAL 721 C: AUTH EXTERNAL ZnJlZA== 722 S: 235 Authentication successful. 724 The following example is almost identical to the one above, but the 725 client doesn't request proxy authentication. 727 S: 220 smtp.example.com ESMTP server ready 728 C: EHLO jgm.example.com 729 S: 250-smtp.example.com 730 S: 250 AUTH DIGEST-MD5 EXTERNAL 731 C: AUTH EXTERNAL 732 S: 235 Authentication successful. 734 8. IANA Considerations 736 Internet DRAFT SASL 31 March 2004 738 8.1. Guidelines for IANA 740 It is requested that IANA updates the SASL mechanisms registry as 741 follows: 743 Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism 744 registrations to OBSOLETE. Change the "Published specification" 745 of the EXTERNAL mechanism to this document. Updated registration 746 information is provided in Section 8.6. 748 8.2. Registration procedure 750 Registration of a SASL mechanism is done by filling in the template 751 in section 8.5 and sending it via electronic mail to . 752 IANA has the right to reject obviously bogus registrations, but will 753 perform no review of claims made in the registration form. SASL 754 mechanism registrations are currently available at the URL 755 . 757 There is no naming convention for SASL mechanisms; any name that 758 conforms to the syntax of a SASL mechanism name can be registered. 759 However an IETF Standards Track document may reserve a portion of the 760 SASL mechanism namespace ("family of SASL mechanisms") for its own 761 use, amending the registration rules for that portion of the 762 namespace. Each family of SASL mechanisms MUST be identified by a 763 prefix. 765 While the registration procedures do not require it, authors of SASL 766 mechanisms are encouraged to seek community review and comment 767 whenever that is feasible. Authors may seek community review by 768 posting a specification of their proposed mechanism as an Internet- 769 Draft. SASL mechanisms intended for widespread use should be 770 standardized through the normal IETF process, when appropriate. 772 8.3. Comments on SASL mechanism registrations 774 Comments on registered SASL mechanisms should first be sent to the 775 "owner" of the mechanism and/or to the SASL WG mailing list. 776 Submitters of comments may, after a reasonable attempt to contact the 777 owner, request IANA to attach their comment to the SASL mechanism 778 registration itself. If IANA approves of this, the comment will be 779 made accessible in conjunction with the SASL mechanism registration 780 itself. 782 Internet DRAFT SASL 31 March 2004 784 8.4. Change control 786 Once a SASL mechanism registration has been published by IANA, the 787 author may request a change to its definition. The change request 788 follows the same procedure as the registration request. 790 The owner of a SASL mechanism may pass responsibility for the SASL 791 mechanism to another person or agency by informing IANA; this can be 792 done without discussion or review. 794 The IESG may reassign responsibility for a SASL mechanism. The most 795 common case of this will be to enable changes to be made to 796 mechanisms where the author of the registration has died, moved out 797 of contact or is otherwise unable to make changes that are important 798 to the community. 800 SASL mechanism registrations may not be deleted; mechanisms which are 801 no longer believed appropriate for use can be declared OBSOLETE by a 802 change to their "intended use" field; such SASL mechanisms will be 803 clearly marked in the lists published by IANA. 805 The IESG is considered to be the owner of all SASL mechanisms which 806 are on the IETF standards track. 808 8.5. Registration template 810 Subject: Registration of SASL mechanism X 812 Family of SASL mechanisms: (YES or NO) 814 SASL mechanism name (or prefix for the family): 816 Security considerations: 818 Published specification (optional, recommended): 820 Person & email address to contact for further information: 822 Intended usage: 824 (One of COMMON, LIMITED USE or OBSOLETE) 826 Owner/Change controller: 828 (Any other information that the author deems interesting may be 829 added below this line.) 831 Internet DRAFT SASL 31 March 2004 833 8.6. The EXTERNAL mechanism registration 835 It is requested that the SASL Mechanism registry [IANA-SASL] entry 836 for the EXTERNAL mechanism be updated to reflect that this document 837 now provides its technical specification. 839 Subject: Updated Registration of SASL mechanism EXTERNAL 841 Family of SASL mechanisms: NO 843 SASL mechanism name: EXTERNAL 845 Security considerations: See RFC XXXX, section 9. 847 Published specification (optional, recommended): RFC XXXX 849 Person & email address to contact for further information: 850 Alexey Melnikov 852 Intended usage: COMMON 854 Owner/Change controller: IESG 856 Note: Updates existing entry for EXTERNAL 858 9. Security considerations 860 Security issues are discussed throughout this memo. 862 When the client selects a security layer with at least integrity 863 protection, this protects against an active attacker hijacking the 864 connection and modifying the authentication exchange to negotiate a 865 plaintext connection. 867 When a server or client supports multiple authentication mechanisms, 868 each of which has a different security strength, it is possible for 869 an active attacker to cause a party to use the least secure mechanism 870 supported. To protect against this sort of attack, a client or 871 server which supports mechanisms of different strengths should have a 872 configurable minimum strength that it will use. It is not sufficient 873 for this minimum strength check to only be on the server, since an 874 active attacker can change which mechanisms the client sees as being 875 supported, causing the client to send authentication credentials for 876 its weakest supported mechanism. 878 The client's selection of a SASL mechanism is done in the clear and 879 may be modified by an active attacker. It is important for any new 881 Internet DRAFT SASL 31 March 2004 883 SASL mechanisms to be designed such that an active attacker cannot 884 obtain an authentication with weaker security properties by modifying 885 the SASL mechanism name and/or the challenges and responses. 887 In order to detect Man-in-the-middle (MITM) attacks the client MAY 888 list available SASL mechanisms both before and after the SASL 889 security layer is negotiated. This allows the client to detect 890 active attacks that remove mechanisms from the server's list of 891 supported mechanisms, and allows the client to ensure that it is 892 using the best mechanism supported by both client and server. New 893 protocol profiles SHOULD require servers to make the list of SASL 894 mechanisms available for the initial authentication available to the 895 client after security layers are established. Some older protocols 896 do not require this (or don't support listing of SASL mechanisms once 897 authentication is complete); for these protocols clients MUST NOT 898 treat an empty list of SASL mechanisms after authentication as a MITM 899 attack. 901 Any protocol interactions prior to authentication are performed in 902 the clear and may be modified by an active attacker. In the case 903 where a client selects integrity protection, it is important that any 904 security-sensitive protocol negotiations be performed after 905 authentication is complete. Protocols should be designed such that 906 negotiations performed prior to authentication should be either 907 ignored or revalidated once authentication is complete. 909 When use of a security layer is negotiated by the authentication 910 protocol exchange, the receiver should handle gracefully any security 911 encoded data buffer larger than the defined/negotiated maximal size. 912 In particular, it must not blindly allocate the amount of memory 913 specified in the buffer size field, as this might cause the "out of 914 memory" condition. If the receiver detects a large block, it SHOULD 915 close the connection. 917 Distributed server implementations need to be careful in how they 918 trust other parties and, in particular, authentication secrets should 919 only be disclosed to other parties that are trusted to manage and use 920 those secrets in manner acceptable to disclosing party. It should be 921 noted that, where those secrets are used to provide data 922 confidentiality protections, if a third party (other than the 923 discloser/disclosee) has knowledge of some portion of the protected 924 information, it can use this knowledge in an attack upon other 925 portions of the protected information. 927 <
> 931 Internet DRAFT SASL 31 March 2004 933 "stringprep" and Unicode security considerations apply to 934 authentication identities, authorization identities and passwords. 936 The EXTERNAL mechanism provides no security protection; it is 937 vulnerable to spoofing by either client or server, active attack, and 938 eavesdropping. It should only be used when external security 939 mechanisms are present and have sufficient strength. 941 10. References 943 10.1. Normative References 945 [ABNF] Crocker, D. (Ed.), Overell, P., "Augmented BNF for Syntax 946 Specifications: ABNF", RFC 2234, November 1997 948 [ASCII] American National Standards Institute, "Code Extension 949 Techniques for Use with the 7-bit Coded Character Set of American 950 National Standard Code (ASCII) for Information Interchange", FIPS PUB 951 35, 1974 953 [CHARSET-POLICY] Alvestrand, H., "IETF Policy on Character Sets and 954 Languages", RFC 2277, BCP 18, January 1998 956 [GSSAPI] Linn, J., "Generic Security Service Application Program 957 Interface, Version 2, Update 1", RFC 2743, January 2000 959 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 960 Requirement Levels", RFC 2119, BCP 19, March 1997 962 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 963 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, 964 MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the 965 "Unicode Standard Annex #27: Unicode 3.1" 966 (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard 967 Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/). 969 [Stringprep] Hoffman, P., Blanchet, M., "Preparation of 970 Internationalized Strings ("stringprep")", RFC 3454, December 2002. 972 [SASLprep] Zeilenga, K., "SASLprep: Stringprep profile for user names 973 and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt. 975 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 976 RFC 3629, STD 63, November 2003. 978 Internet DRAFT SASL 31 March 2004 980 10.2. Informative References 982 [SASL-GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", work in 983 progress, draft-ietf-sasl-gssapi-XX.txt, November 2003 985 [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest 986 Authentication as a SASL Mechanism", work in progress, draft-ietf- 987 sasl-rfc2831bis-XX.txt, replaces RFC 2831 989 [SASL-OTP] Newman, C., "The One-Time-Password SASL Mechanism", RFC 990 2444, October 1998. 992 [SASL-SECURID] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 993 2808, April 2000. 995 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 996 2001. 998 [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", 999 RFC 2554, March 1999. 1001 Being revised by Siemborski, R., "SMTP Service Extension for 1002 Authentication", work in progress, draft-siemborski-rfc2554bis- 1003 XX.txt. 1005 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol 1006 (XMPP): Core", work in progress, draft-ietf-xmpp-core-XX.txt. 1008 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 1009 Encodings", RFC 3548, July 2003. 1011 [RFC-INSTRUCTIONS] Postel, J., Reynolds, J., "Instructions to RFC 1012 Authors", RFC 2223, October 1997. 1014 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) 1015 MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms. 1017 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1018 2246, January 1999. 1020 [IPSec] Kent, S., and R. Atkinson, "Security Architecture for the 1021 Internet Protocol", RFC 2401, November 1998. 1023 Internet DRAFT SASL 31 March 2004 1025 11. Editor's Address 1027 Alexey Melnikov 1028 Isode Limited 1029 5 Castle Business Village 1030 36 Station Road 1031 Hampton, Middlesex, 1032 TW12 2BX, United Kingdom 1034 Email: Alexey.Melnikov@isode.com 1035 URI: http://www.melnikov.ca/ 1037 12. Acknowledgments 1039 This document is a revision of RFC 2222 written by John G. Myers. He 1040 also contributed significantly to this revision. 1042 <> 1045 Contributions of many members of the SASL mailing list are gratefully 1046 acknowledged, in particular Kurt Zeilenga, Peter Saint-Andre, Rob 1047 Siemborski, Jeffrey Hutzelman, Hallvard B Furuseth, Tony Hansen, 1048 Simon Josefsson, Abhijit Menon-Sen, RL 'Bob' Morgan and Tim Alsop for 1049 proofreading the document and various editorial suggestions. 1051 13. Full Copyright Statement 1053 Copyright (C) The Internet Society (2004). All Rights Reserved. 1055 This document and translations of it may be copied and furnished to 1056 others, and derivative works that comment on or otherwise explain it 1057 or assist in its implementation may be prepared, copied, published 1058 and distributed, in whole or in part, without restriction of any 1059 kind, provided that the above copyright notice and this paragraph are 1060 included on all such copies and derivative works. However, this 1061 document itself may not be modified in any way, such as by removing 1062 the copyright notice or references to the Internet Society or other 1063 Internet organizations, except as needed for the purpose of 1064 developing Internet standards in which case the procedures for 1065 copyrights defined in the Internet Standards process must be 1066 followed, or as required to translate it into languages other than 1067 English. 1069 The limited permissions granted above are perpetual and will not be 1070 revoked by the Internet Society or its successors or assigns. 1072 Internet DRAFT SASL 31 March 2004 1074 This document and the information contained herein is provided on an 1075 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1076 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1077 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1078 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1079 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1081 Acknowledgement 1083 Funding for the RFC Editor function is currently provided by the 1084 Internet Society. 1086 14. Intellectual Property 1088 The IETF takes no position regarding the validity or scope of any 1089 Intellectual Property Rights or other rights that might be claimed to 1090 pertain to the implementation or use of the technology described in 1091 this document or the extent to which any license under such rights 1092 might or might not be available; nor does it represent that it has 1093 made any independent effort to identify any such rights. Information 1094 on the procedures with respect to rights in RFC documents can be 1095 found in BCP 78 and BCP 79. 1097 Copies of IPR disclosures made to the IETF Secretariat and any 1098 assurances of licenses to be made available, or the result of an 1099 attempt made to obtain a general license or permission for the use of 1100 such proprietary rights by implementers or users of this 1101 specification can be obtained from the IETF on-line IPR repository at 1102 http://www.ietf.org/ipr. 1104 The IETF invites any interested party to bring to its attention any 1105 copyrights, patents or patent applications, or other proprietary 1106 rights that may cover technology that may be required to implement 1107 this standard. Please address the information to the IETF at ietf- 1108 ipr@ietf.org. 1110 Appendix A. Relation of SASL to transport security 1112 Questions have been raised about the relationship between SASL and 1113 various services (such as IPsec and TLS) which provide a secured 1114 connection. 1116 Two of the key features of SASL are: 1118 The separation of the authorization identity from the identity in 1119 the client's credentials. This permits agents such as proxy 1120 servers to authenticate using their own credentials, yet request 1121 the access privileges of the identity for which they are proxying. 1123 Internet DRAFT SASL 31 March 2004 1125 Upon successful completion of an authentication exchange, the 1126 server knows the authorization identity the client wishes to use. 1127 This allows servers to move to a "user is authenticated" state in 1128 the protocol. 1130 These features are extremely important to some application protocols, 1131 yet Transport Security services do not always provide them. To 1132 define SASL mechanisms based on these services would be a very messy 1133 task, as the framing of these services would be redundant with the 1134 framing of SASL and some method of providing these important SASL 1135 features would have to be devised. 1137 Sometimes it is desired to enable within an existing connection the 1138 use of a security service which does not fit the SASL model. (TLS is 1139 an example of such a service.) This can be done by adding a command, 1140 for example "STARTTLS", to the protocol. Such a command is outside 1141 the scope of SASL, and should be different from the command which 1142 starts a SASL authentication protocol exchange. 1144 In certain situations, it is reasonable to use SASL underneath one of 1145 these Transport Security services. The transport service would 1146 secure the connection, either service would authenticate the client, 1147 and SASL would negotiate the authorization identity. The SASL 1148 negotiation would be what moves the protocol from "unauthenticated" 1149 to "authenticated" state. The "EXTERNAL" SASL mechanism is 1150 explicitly intended to handle the case where the transport service 1151 secures the connection and authenticates the client and SASL 1152 negotiates the authorization identity. 1154 Appendix B. Relationship to other documents 1156 This document obsoletes RFC 2222. It replaces all portions of RFC 1157 2222 excepting sections 7.1 (Kerberos version 4 mechanism), 7.2 1158 (GSSAPI mechanism), 7.3 (S/Key mechanism). The Kerberos version 4 1159 (KERBEROS_IV) and S/Key (SKEY) mechanisms are now viewed as obsolete. 1160 The GSSAPI mechanism is now separately specified [SASL-GSSAPI]. 1162 Appendix C. Changes since RFC 2222 1164 The GSSAPI mechanism was removed. It is now specified in a separate 1165 document [SASL-GSSAPI]. 1167 The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has 1168 been removed. 1170 The "SKEY" mechanism described in RFC 2222 is obsolete and has been 1171 removed. It has been replaced by the OTP mechanism [SASL-OTP]. 1173 Internet DRAFT SASL 31 March 2004 1175 The overview has been substantially reorganized and clarified. 1177 Clarified the definition and semantics of the authorization identity. 1179 Prohibited the NUL character in authorization identities. 1181 Added a section on character string issues. 1183 The word "must" in the first paragraph of the "Protocol profile 1184 requirements" section was changed to "MUST". 1186 Specified that protocol profiles SHOULD provide a way for clients to 1187 discover available SASL mechanisms. 1189 Made the requirement that protocol profiles specify the semantics of 1190 the authorization identity optional to the protocol profile. 1191 Clarified that such a specification is a refinement of the definition 1192 in the base SASL spec. 1194 Added a requirement discouraging protocol profiles from breaking the 1195 separation between protocol and mechanism. 1197 Mentioned that standards track documents may carve out their own 1198 portions of the SASL mechanism namespace and may amend registration 1199 rules for the portion. However registration of individual SASL 1200 mechanisms is still required. 1202 Specified that the authorization identity in the EXTERNAL mechanism 1203 is encoded in UTF-8. 1205 Added a statement that a protocol profile SHOULD allow challenge data 1206 to be sent with a success indication. 1208 Added a security consideration for the EXTERNAL mechanism. 1210 Clarified sections concerning success with additional data. 1212 Cleaned up IANA considerations/registrations and assembled them in 1213 one place. 1215 Updated references and split them into Informative and Normative. 1217 Added text to the Security Considerations section regarding handling 1218 of extremely large SASL blocks. 1220 Replaced UTF-8 ABNF with the reference to the UTF-8 document. 1222 Added text about SASLprep for authentication identities and 1224 Internet DRAFT SASL 31 March 2004 1226 passwords. Described where SASLprep preparation should take place. 1228 Added paragraph about verifying authorization identities. 1230 Added a protocol profile requirement to specify interaction between 1231 SASL and TLS security layers. 1233 Added a protocol profile requirement to specify if it supports 1234 reauthentication. 1236 Removed the text that seemed to suggest that SASL security layer must 1237 not be used when TLS is available. 1239 Created two subsections in 3.2 to talk separately about proxy 1240 authorization and format of the authorization identities. 1242 Made requirement to verify that an authorization identity is correct 1243 by performing SASLprep a SHOULD, instead of a MUST. 1245 Clarified that each SASL mechanism must decide where SASLprep is 1246 taking place. 1248 Added 4 new examples for initial response and additional data with 1249 success. 1251 Added text on checking the list of available SASL mechanisms after 1252 negotiating a security layer. 1254 Added definition of "integrity protection" and "confidentiality 1255 protection". 1257 Added warning about negotiating no layer once a security layer is 1258 negotiated. 1260 Added new section with guidelines to a SASL mechanism designer. 1262 Added a requirement to specify how an empty initial challenge is 1263 encoded if initial response is supported by a protocol. 1265 Appendix D. ToDo 1267 This section will be deleted before publication. 1269 1) Clean up definition of different terms like integrity protection 1270 and check if RFC 2828 (Security Glossary) can be used. 1272 2) Kurt is going to do a new description of what SASL is. 1274 Internet DRAFT SASL 31 March 2004 1276 3) Sam is going to propose new text that replaces "multiple 1277 authentication" attack. 1279 4) Reorganize sections 1 & 2 as per recent Kurt suggestion (as 1280 modified by Alexey). 1282 5) Clarify empty versa missing "additional data with success". 1284 Internet DRAFT SASL 31 March 2004 1286 Status of this Memo .......................................... i 1287 Abstract ..................................................... 2 1288 1. Organization of this document .......................... 2 1289 1.1. How to read this document .............................. 2 1290 1.2. Conventions used in this document ...................... 3 1291 2. Overview ............................................... 3 1292 3. Authentication mechanisms .............................. 4 1293 3.1. Authentication protocol exchange ....................... 4 1294 3.2. Authorization and authentication identities ............ 5 1295 3.2.1. Authorization identities and proxy authentication .... 6 1296 3.2.2. Authorization Identity Format ........................ 6 1297 3.3. Security layers ........................................ 7 1298 4. Protocol profile requirements .......................... 7 1299 5. Mechanism profile guidelines ........................... 9 1300 6. Specific issues ....................................... 10 1301 6.1. Client sends data first ............................... 10 1302 6.1.1. Client sends data first examples .................... 10 1303 6.2. Server returns success with additional data ........... 11 1304 6.2.1. Server returns success with additional data examples 12 1305 6.3. Multiple authentications .............................. 13 1306 7. The EXTERNAL mechanism ................................ 14 1307 7.1. Formal syntax ......................................... 14 1308 7.2. Examples of SASL EXTERNAL ............................. 15 1309 8. IANA Considerations ................................... 15 1310 8.1. Guidelines for IANA ................................... 16 1311 8.2. Registration procedure ................................ 16 1312 8.3. Comments on SASL mechanism registrations .............. 16 1313 8.4. Change control ........................................ 17 1314 8.5. Registration template ................................. 17 1315 8.6. The EXTERNAL mechanism registration ................... 18 1316 9. Security considerations ................................ 18 1317 10. References ........................................... 20 1318 10.1. Normative References ................................. 20 1319 10.2. Informative References ............................... 21 1320 11. Editor's Address ...................................... 22 1321 12. Acknowledgments ....................................... 22 1322 13. Full Copyright Statement .............................. 22 1323 14. Intellectual Property ................................. 23 1324 Appendix A. Relation of SASL to transport security .......... 23 1325 Appendix B. Relationship to other documents ................. 24 1326 Appendix C. Changes since RFC 2222 .......................... 24 1327 Appendix D. ToDo ............................................ 26