idnits 2.17.1 draft-ietf-sasl-rfc2222bis-08.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 3978, Section 5.5 on line 1129. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1145. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1152. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1158. ** 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. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 28 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 29 pages -- Found 29 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 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == 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 (June 2004) is 7255 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 412, but not defined ** Obsolete undefined reference: RFC 3501 (Obsoleted by RFC 9051) == Missing Reference: 'StringPrep' is mentioned on line 455, but not defined == Missing Reference: 'IMAP' is mentioned on line 766, but not defined == Unused Reference: 'Stringprep' is defined on line 1014, but no explicit reference was found in the text == Unused Reference: 'BASE64' is defined on line 1053, but no explicit reference was found in the text == Unused Reference: 'RFC-INSTRUCTIONS' is defined on line 1056, 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) -- Obsolete informational reference (is this intentional?): RFC 2828 (ref. 'Sec-Glossary') (Obsoleted by RFC 4949) Summary: 12 errors (**), 0 flaws (~~), 12 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Melnikov 2 Internet Draft Editor 3 Document: draft-ietf-sasl-rfc2222bis-08.txt June 2004 4 Obsoletes: RFC 2222 Expires in six months 6 Simple Authentication and Security Layer (SASL) 8 Status of this Memo 10 This document is an Internet Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its Areas, and its Working Groups. Note that 15 other groups may also distribute working documents as Internet 16 Drafts. Internet Drafts are draft documents valid for a maximum of 17 six months. Internet Drafts may be updated, replaced, or obsoleted 18 by other documents at any time. It is not appropriate to use 19 Internet Drafts as reference material or to cite them other than as 20 ``work in progress''. 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 A revised version of this draft document will be submitted to the RFC 29 editor as a Standards Track RFC for the Internet Community. 30 Discussion and suggestions for improvement are requested. 31 Distribution of this draft is unlimited. 33 When published as an RFC this document will obsolete RFC 2222. 35 Internet DRAFT SASL 28 June 2004 37 Abstract 39 The Simple Authentication and Security Layer (SASL) is a framework 40 for providing authentication and data security services in 41 connection-oriented protocols via replaceable mechanisms. It 42 provides structured interface between protocols and mechanisms. The 43 resulting framework allows new protocols to reuse existing mechanisms 44 and allows old protocols to make use of new mechanisms. The 45 framework also provides a protocol for securing subsequent protocol 46 exchanges within a data security layer. 48 This document describes how a SASL mechanism is structured, describes 49 how protocols add support for SASL, and defines the protocol for 50 carrying a data security layer over a connection. Additionally, this 51 document defines one SASL mechanism, the EXTERNAL mechanism. 53 1. Conventions used in this document 55 In examples, "C:" and "S:" indicate lines sent by the client and 56 server respectively. 58 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 59 in this document are to be interpreted as defined in "Key words for 60 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 62 Character names in this document use the notation for code points and 63 names from the Unicode Standard [Unicode]. For example, the letter 64 "a" may be represented as either or . 66 This document uses terms "integrity protection" and "confidentiality 67 protection". The former refers to a security layer (see Section 68 "Introduction" below for the definition) designed to provide "data 69 integrity service" as defined in [Sec-Glossary]. Confidentiality 70 protection is a security layer that provides "data confidentiality 71 service" as defined in [Sec-Glossary]. The term "confidentiality 72 protection" usually implies "integrity protection". Security layers 73 may offer other kinds of security services. 75 2. Introduction 77 The Simple Authentication and Security Layer (SASL) is a framework 78 for providing authentication and data security services in 79 connection-oriented protocols via replaceable mechanisms. SASL 80 provides a structured interface between protocols and mechanisms. 81 SASL also provides a protocol for securing subsequent protocol 82 exchanges within a data security layer. 84 Internet DRAFT SASL 28 June 2004 86 SASL design is intended to allow new protocols to reuse existing 87 mechanisms without requiring redesign of the mechanisms and allows 88 existing protocols to make use of new mechanisms without redesign of 89 protocols. 91 The SASL is conceptually a framework which provides a layer between 92 protocols and mechanisms, as illustrated in the following diagram. 94 SMTP Protocol LDAP Protocol Other Protocols 95 Profile Profile . . . 96 \----- | -----/ 97 \ | / 98 SASL framework 99 / | \ 100 /----- | -----\ 101 DIGEST-MD5 EXTERNAL Other Mechanisms 102 SASL mechanism SASL mechanism . . . 104 It is through the interfaces of this layer that the framework allows 105 any protocol to be utilized with any mechanism. While the layer does 106 generally hide the particulars of protocols from mechanisms, the 107 layer does not generally hide the particulars of mechanisms from 108 protocols. For example, different mechanisms require different 109 information to operate, some of them use password based 110 authentication, other make use of Kerberos tickets, certificates, 111 etc. Also, in order to perform authorization step server 112 implementations have to implement mapping from a mechanism specific 113 authentication identity format to a protocol specific format. 115 It is noted that it is possible to design and implement this 116 framework in ways which do abstract away particulars of similar 117 mechanisms. Such implementation could also be designed to be shared 118 by multiple implementations of various protocols. 120 As illustrated above, the SASL framework interfaces with both 121 protocols and mechanisms. 123 To use SASL, a protocol includes a command for identifying and 124 authenticating a user to a server and for optionally negotiating a 125 security layer for subsequent protocol interactions. If the use of a 126 security layer is negotiated, that security layer is inserted between 127 the protocol and the connection. Section 4 ("Protocol profile 128 requirements") profiles the requirements that a protocol 129 specification must fulfill to make use of SASL. 131 A SASL mechanism is a series of server challenges and client 132 responses specific to the mechanism. Each SASL mechanism are 134 Internet DRAFT SASL 28 June 2004 136 identity by a registered name. Section 5. ("Mechanism profile 137 guidelines") profiles the requirements that a mechanism specification 138 must fulfill to define a SASL mechanism. 140 This document is written to serve several different audiences: 142 o) protocol designers using this specification to support 143 authentication in their protocol 145 o) mechanism designers that define new SASL mechanisms 147 o) implementors of clients or servers for those protocols using this 148 specification. 150 The sections "Authentication Mechanisms", "Protocol Profile 151 Requirements", "Specific Issues", and "Security Considerations" cover 152 issues that protocol designers need to understand and address in 153 profiling this specification for use in a specific protocol. 155 The sections "Authentication Mechanisms", "Mechanism Profile 156 Requirements", "Security Considerations" and "Registration procedure" 157 cover issues that mechanism designers need to understand and address 158 in designing new SASL mechanisms. 160 The sections "Authentication Mechanisms", "Protocol profile 161 requirements", "Specific issues" and "Security Considerations" cover 162 issues that implementors of a protocol that uses SASL framework need 163 to understand. The implementors will also need to understand a 164 specification of a profile specific to the protocol, as well as 165 aspects of mechanism specifications they intend to use (regardless of 166 whether they are implementing the mechanisms themselves or using an 167 existing implementation) to understand, for instance, the mechanism 168 specific authentication identity forms, the offered services, and 169 security and other considerations. 171 3. Authentication mechanisms 173 SASL mechanisms are named by strings, from 1 to 20 characters in 174 length, consisting of ASCII [ASCII] upper-case letters, digits, 175 hyphens, and/or underscores. Names of SASL mechanisms or families of 176 mechanisms must be registered with the Internet Assigned Numbers 177 Authority (IANA) as described in section 8.2. 179 The "sasl-mech" ABNF production below defines the syntax of a SASL 180 mechanism name. This uses the Augmented Backus-Naur Form (ABNF) 181 notation as specified in [ABNF]. 183 Internet DRAFT SASL 28 June 2004 185 sasl-mech = 1*20mech-char 186 mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE 187 ; mech-char is restricted to "A"-"Z", "0"-"9", "-", 188 ; and "_" from ASCII character set. 190 UPPER-ALPHA = %x41-5A 191 ; "A"-"Z" 193 DIGIT = %x30-39 194 ; "0"-"9" 196 HYPHEN = %x2D 197 ; "-" 199 UNDERSCORE = %x5F 200 ; "_" 202 3.1. Authentication protocol exchange 204 A SASL mechanism is responsible for conducting an authentication 205 protocol exchange. This consists of a series of server challenges 206 and client responses, the contents of which are specific to and 207 defined by the mechanism. To the protocol, the challenges and 208 responses are opaque binary tokens of arbitrary length. The 209 protocol's profile then specifies how these binary tokens are then 210 encoded for transfer over the connection. 212 After receiving an authentication command or any client response, a 213 server mechanism may issue a challenge, indicate failure, or indicate 214 completion. The server mechanism may return additional data with a 215 completion indication. The protocol's profile specifies how each of 216 these is then represented over the connection. 218 After receiving a challenge, a client mechanism may issue a response 219 or abort the exchange. The protocol's profile specifies how each of 220 these are then represented over the connection. 222 During the authentication protocol exchange, the mechanism performs 223 authentication, transmits an authorization identity (frequently known 224 as a userid) from the client to server, and negotiates the use of a 225 mechanism-specific security layer. If the use of a security layer is 226 agreed upon, then the mechanism must also define or negotiate the 227 maximum security layer buffer size that each side is able to receive. 229 Internet DRAFT SASL 28 June 2004 231 3.2. Authorization and authentication identities 233 SASL authentication deals with two identities: the authentication 234 identity, derived from the client's authentication credentials; and 235 the authorization identity, which is the result of SASL processing 236 and is used by the server as the primary identity for making access 237 policy decisions. 239 The processing model is as follows. A server, upon completion of the 240 authentication mechanism, uses the results produced by the 241 authentication mechanism, the client-provided authorization identity 242 value (which may be the empty string), and local policy information 243 to derive an authorization identity. The authorization identity is 244 made available to further server processing for use in making access 245 policy decisions. The provision of additional client attributes that 246 may affect access policy is not covered by this specification. 248 The authorization identity may be an empty (zero length) string. In 249 this case, the server derives an authorization identity from the 250 client's authentication identity. 252 A mechanism which is incapable of transmitting an authorization 253 identity must be treated as if it always transmits an authorization 254 identity of an empty string. 256 Any normalization of the authentication identity is defined by a 257 particular SASL mechanism, the protocol profile doesn't influence it. 259 The mechanism MUST preserve Unicode codepoint when transferring 260 authorization identity (e.g. the mechanism cann't apply any form of 261 normalization). 263 3.2.1. Authorization identities and proxy authentication 265 If the authorization identity transmitted during the authentication 266 protocol exchange is not the empty string, this is typically referred 267 to as "proxy authentication". This feature permits agents such as 268 proxy servers to authenticate using their own credentials, yet 269 request the access privileges of the identity for which they are 270 proxying. 272 The server makes an implementation defined policy decision as to 273 whether the authentication identity is permitted to have the access 274 privileges of the authorization identity and whether the 275 authorization identity is permitted to receive service. If it is 276 not, the server indicates failure of the authentication protocol 277 exchange. 279 Internet DRAFT SASL 28 June 2004 281 As a client might not have the same information as the server, 282 clients SHOULD NOT derive authorization identities from 283 authentication identities. Instead, clients SHOULD provide no (or 284 empty) authorization identity when the user has not provided an 285 authorization identity. 287 The server SHOULD verify that a received authorization identity is in 288 the correct form. Protocol profiles whose authorization identities 289 are simple user names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep" 290 profile [SASLprep] of the "stringprep" algorithm [StringPrep] to 291 prepare these names for matching. The profiles MAY use a stringprep 292 profile that is more strict than "SASLprep". If the preparation of 293 the authorization identity fails or results in an empty string, the 294 server MUST fail the authentication exchange. The only exception to 295 this rule is when the received authorization identity is already the 296 empty string. 298 3.2.2. Authorization Identity Format 300 An authorization identity is a string of zero or more Unicode 301 [Unicode] coded characters. The NUL character is not 302 permitted in authorization identities. 304 The character encoding scheme used for transmitting an authorization 305 identity over the protocol is specified in each authentication 306 mechanism. All IETF-defined mechanisms MUST, and all other 307 mechanisms SHOULD, use UTF-8 [UTF-8]. (See [CHARSET-POLICY] for IETF 308 policy regarding character sets and encoding schemes.) 310 Mechanisms are expected to be capable of carrying the entire Unicode 311 repertoire (with the exception of the NUL character). An 312 authorization identity of the empty string and an absent 313 authorization identity MUST be treated as equivalent. A mechanism 314 which provides an optional field for an authorization identity, 315 SHOULD NOT allow that field, when present, to be empty. The meaning 316 of the empty string as an authorization identity is described in the 317 previous section. 319 3.3. Security layers 321 If use of a security layer is negotiated by the authentication 322 protocol exchange, the security layer is applied to all subsequent 323 data sent over the connection (until another security layer is 324 negotiated; see also section 6.3). The security layer takes effect 325 immediately following the last response of the authentication 326 exchange for data sent by the client and the completion indication 327 for data sent by the server. The exact position MUST be defined by 328 the protocol profile (see section 4 part 5). 330 Internet DRAFT SASL 28 June 2004 332 Note that all SASL mechanisms that are unable to negotiate a security 333 layer automatically select no security layer. 335 Once the security layer is in effect the protocol stream is processed 336 by the security layer into buffers of protected data. Each buffer of 337 protected data is transferred over the connection as a stream of 338 octets prepended with a four octet field in network byte order that 339 represents the length of the following buffer. The length of the 340 protected data buffer MUST be no larger than the maximum size that 341 was either defined in the mechanism specification or negotiated by 342 the other side during the authentication protocol exchange. Upon the 343 receipt of a data buffer which is larger than the defined/negotiated 344 maximal buffer size the receiver SHOULD close the connection. This 345 might be a sign of an attack or a buggy implementation. 347 4. Protocol profile requirements 349 In order to use this specification, a protocol definition MUST supply 350 the following information: 352 1) A service name, to be selected from the IANA registry of "service" 353 elements for the GSSAPI host-based service name form [GSSAPI]. This 354 service name is made available to the authentication mechanism. 356 The registry is available at the URL 357 . 359 2) A definition of the command to initiate the authentication 360 protocol exchange. This command must have as a parameter the name of 361 the mechanism being selected by the client. 363 The command SHOULD have an optional parameter giving an initial 364 response. If the protocol allows for the initial response, the 365 protocol profile SHOULD also describe how an empty initial response 366 is encoded. This optional parameter allows the client to avoid a 367 round trip when using a mechanism which is defined to have the client 368 send data first. When this initial response is sent by the client 369 and the selected mechanism is defined to have the server start with 370 an initial challenge, the command fails. See section 6.1 of this 371 document for further information. 373 3) A definition of the method by which the authentication protocol 374 exchange is carried out, including how the challenges and responses 375 are encoded, how the server indicates completion or failure of the 376 exchange, how the client aborts an exchange, and how the exchange 377 method interacts with any line length limits in the protocol. 379 The exchange method SHOULD allow the server to include an optional 381 Internet DRAFT SASL 28 June 2004 383 data ("optional challenge") with a success notification. This allows 384 the server to avoid a round trip when using a mechanism which is 385 defined to have the server send additional data along with the 386 indication of successful completion. Note that an additional data 387 with success can't be empty. See section 6.2 of this document for 388 further information. 390 4) A protocol profile SHOULD specify a mechanism through which a 391 client may obtain the names of the SASL mechanisms available to it. 392 This is typically done through the protocol's extensions or 393 capabilities mechanism. 395 5) Identification of the octet where any negotiated security layer 396 starts to take effect, in both directions. 398 6) Specify if the protocol profile supports "multiple 399 authentications" (see section 6.3). 401 7) If both a Transport Layer Security [TLS] and a SASL security layer 402 are allowed to be negotiated by the protocol, the protocol profile 403 MUST define in which order they are applied to a cleartext data sent 404 over the connection. 406 8) A protocol profile MAY further refine the definition of an 407 authorization identity by adding additional syntactic restrictions 408 and protocol-specific semantics. A protocol profile MUST specify the 409 form of the authorization identity (since it is protocol specific, as 410 opposed to the authentication identity, which is mechanism specific) 411 and how authorization identities are to be compared. Profiles whose 412 authorization identities are simple user names (e.g. IMAP [RFC 3501]) 413 SHOULD use "SASLprep" profile [SASLprep] of the "stringprep" 414 algorithm [StringPrep] to prepare these names for matching. The 415 profiles MAY use a stringprep profile that is more strict than 416 SASLprep. 418 9) Where the application-layer protocol does not precisely state how 419 identities established through SASL relate to identities used 420 elsewhere (e.g., access controls) in the application-layer protocol, 421 it may be useful for the application-layer protocol to provide a 422 facility which the client may use to discover the identity used. 424 A protocol profile SHOULD NOT attempt to amend the definition of 425 mechanisms or make mechanism-specific encodings. This breaks the 426 separation between protocol and mechanism that is fundamental to the 427 design of SASL. Likewise, SASL mechanisms SHOULD be profile neutral. 429 Internet DRAFT SASL 28 June 2004 431 5. Mechanism profile guidelines 433 Designers of new SASL mechanism should be aware of the following 434 issues: 436 1) Authorization identity 438 While some legacy mechanisms are incapable of transmitting an 439 authorization identity (which means that for these mechanisms the 440 authorization identity is always the empty string), newly defined 441 mechanisms SHOULD be capable of transmitting a non-empty 442 authorization identity. See also section 3.2. 444 2) Character string issues 446 Authentication mechanisms SHOULD encode character strings in UTF-8 447 [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character 448 sets in IETF protocols). In order to avoid interoperability problems 449 due to differing normalizations, when a mechanisms specifies that 450 character data is to be used as input to a cryptographic and/or 451 comparison function, the mechanism specification MUST detail how the 452 data is to be represented, including any normalizations or other 453 preparations, to ensure proper function. Designers of mechanisms 454 SHOULD use the "SASLprep" profile [SASLprep] of the "stringprep" 455 algorithm [StringPrep] where applicable. However it should be noted 456 that this rule doesn't apply to authorization identities, as they are 457 protocol specific. 459 The preparation can be potentially performed on the client end (upon 460 getting user input or retrieving a value from configuration) or on 461 the server end (upon receiving the value from the client, retrieving 462 a value from its authentication database or generating a new value in 463 order to store in in the authentication database). SASL mechanisms 464 must define which entity (or entities) must perform the preparation. 465 If preparation fails or results in an empty string, the entity doing 466 the preparation MUST fail the authentication exchange. 468 Implementation note: A server end can be represented by multiple 469 processes. For example, it may consist of the server process itself 470 that communicated with a client, and a command line utility (a server 471 agent) that is able to store passwords/hashes in a database that can 472 be later used by the server. For the server agent the requirement to 473 "fail the authentication exchange" should be interpreted as a 474 requirement to refuse to store the data in the database. 476 3) If the underlying cryptographic technology used by a mechanism 477 supports data integrity than the mechanism specification MUST 479 Internet DRAFT SASL 28 June 2004 481 integrity protect the transmission of an authorization identity and 482 the negotiation of the security layer. 484 4) The mechanism should not use the authorization identity in 485 generation of any long-term cryptographic keys/hashes. The reason is 486 that different protocols (and sometimes even different 487 implementations of the same protocol) may use multiple forms of an 488 authorization identity that are semantically equivalent and some 489 clients may use one form while other clients use a different form. 491 5) SASL mechanisms should be designed to minimize the number of round 492 trips required because SASL can be used with protocols where 493 connections are short-lived. 495 6. Specific issues 497 6.1. Client sends data first 499 Some mechanisms specify that the first data sent in the 500 authentication protocol exchange is from the client to the server. 502 If a protocol's profile permits the command which initiates an 503 authentication protocol exchange to contain an initial client 504 response, this parameter SHOULD be used with such mechanisms. 506 If the initial client response parameter is not given, or if a 507 protocol's profile does not permit the command which initiates an 508 authentication protocol exchange to contain an initial client 509 response, then the server issues a challenge with no data. The 510 client's response to this challenge is then used as the initial 511 client response. (The server then proceeds to send the next 512 challenge, indicates completion, or indicates failure.) 514 6.1.1. Client sends data first examples 516 The following are two examples of an SECURID authentication [SASL- 517 SECURID] in the SMTP protocol [SMTP]. In the first example below, 518 the client is trying fast reauthentication by sending the initial 519 response: 521 S: 220-smtp.example.com ESMTP Server 522 C: EHLO client.example.com 523 S: 250-smtp.example.com Welcome client.example.com 524 S: 250-AUTH GSSAPI SECURID 525 S: 250 DSN 526 C: AUTH SECURID AG1hZ251cwAxMjM0NTY3OAA= 527 S: 235 Authentication successful 529 Internet DRAFT SASL 28 June 2004 531 The example below is almost identical to the previous, but here the 532 client chooses not to use the initial response parameter. 534 S: 220-smtp.example.com ESMTP Server 535 C: EHLO client.example.com 536 S: 250-smtp.example.com Welcome client.example.com 537 S: 250-AUTH GSSAPI SECURID 538 S: 250 DSN 539 C: AUTH SECURID 540 S: 334 541 C: AG1hZ251cwAxMjM0NTY3OAA= 542 S: 235 Authentication successful 544 Additonal examples that show usage of initial response can be found 545 in section 7.2. 547 6.2. Server returns success with additional data 549 Some mechanisms may specify that additional data be sent to the 550 client along with an indication of successful completion of the 551 exchange. This data would, for example, authenticate the server to 552 the client. 554 If a protocol's profile does not permit this additional data to be 555 returned with a success indication, then the server issues the data 556 as a server challenge, without an indication of successful 557 completion. The client then responds with no data. After receiving 558 this empty response, the server then indicates successful completion 559 (with no additional data). 561 Client implementors should be aware of an additional failure case 562 that might occur when the profile supports sending the additional 563 data with success. Imagine that an active attacker is trying to 564 impersonate the server and sends faked data, which should be used to 565 authenticate the server to the client, with success. (A similar 566 situation can happen when either the server and/or the client has a 567 bug and they calculate different responses.) After checking the data, 568 the client will think that the authentication exchange has failed, 569 however the server will think that the authentication exchange has 570 completed successfully. At this point the client can not abort the 571 authentication exchange; it SHOULD close the connection instead. 572 However, if the profile did not support sending of additional data 573 with success, the client could have aborted the exchange at the very 574 last step of the authentication exchange. 576 Internet DRAFT SASL 28 June 2004 578 6.2.1. Server returns success with additional data examples 580 The following are two examples of a DIGEST-MD5 authentication [SASL- 581 DIGEST] in the Extensible Messaging and Presence Protocol [XMPP]. In 582 the first example below, the server is sending mutual authentication 583 data with success. 585 C: 590 S: 596 S: 597 598 DIGEST-MD5 599 CRAM-MD5 600 601 602 C: 604 S: 605 cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9 606 ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== 607 608 C: 609 dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i 610 T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw 611 MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i 612 LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo 613 YXJzZXQ9dXRmLTgK 614 615 S: 616 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= 617 619 The example below is almost identical to the previous, but here 620 the server chooses not to use the additional data with success. 622 C: 630 S: 636 S: 637 638 DIGEST-MD5 639 CRAM-MD5 640 641 642 C: 644 S: 645 cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9 646 ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== 647 648 C: 649 dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i 650 T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw 651 MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i 652 LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo 653 YXJzZXQ9dXRmLTgK 654 655 S: 656 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= 657 658 C: 659 S: 661 6.3. Multiple authentications 663 Unless otherwise stated by the protocol's profile, only one 664 successful SASL negotiation may occur in a protocol session. In this 665 case, once an authentication protocol exchange has successfully 666 completed, further attempts to initiate an authentication protocol 667 exchange fail. 669 If a profile explicitly permits multiple successful SASL negotiations 670 to occur, then in no case may multiple security layers be 671 simultaneously in effect. If a security layer is in effect and a 672 subsequent SASL negotiation selects a second security layer, then the 673 second security layer replaces the first. If a security layer is in 674 effect and a subsequent SASL negotiation selects no security layer, 675 the original security layer remains in effect. 677 Internet DRAFT SASL 28 June 2004 679 Where a protocol profile permits multiple successful SASL 680 negotiations, the profile MUST detail the effect of a failed SASL 681 negotiation upon the previously established authentication state. 682 In particular, it MUST state whether the previously established 683 authenticated state remain in force or whether the connection is to 684 revert to an non-authenticated state. Regardless of the specified 685 effect upon authentication state, the previously negotiated security 686 layer remains in effect. 688 7. The EXTERNAL mechanism 690 The mechanism name associated with external authentication is 691 "EXTERNAL". 693 The client sends a single message containing the UTF-8 encoding of 694 the authorization identity. The message may be empty. The form of the 695 authorization identity is further restricted by the application-level 696 protocol's SASL profile. 698 The server uses information, external to SASL, to determine whether 699 the client is permitted to authenticate as the authorization 700 identity. If the client is so authorized, the server indicates 701 successful completion of the authentication exchange; otherwise the 702 server indicates failure. 704 The system providing this external information may be, for example, 705 IPSec [IPSec] or TLS [TLS]. However, the client can make no 706 assumptions as to what information the server can use in determining 707 client authorization. For example, just because TLS was established, 708 doesn't mean that the server will use the information provided by 709 TLS. 711 If the client sends the empty string as the authorization identity, 712 the authorization identity is to be derived from authentication 713 credentials which exist in the system that is providing the external 714 authentication. 716 7.1. Formal syntax 718 The following syntax specification uses the augmented Backus-Naur 719 Form (BNF) notation as specified in [ABNF]. Non-terminals referenced 720 but not defined below are as defined by [UTF-8]. 722 The "extern-resp" rule below defines the message sent from client to 723 server. 725 extern-resp = *( UTF8-char-no-nul ) 727 Internet DRAFT SASL 28 June 2004 729 UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4 731 UTF8-1-no-nul = %x01-7F 733 7.2. Examples of SASL EXTERNAL 735 The following is an example of an EXTERNAL authentication in the SMTP 736 protocol [SMTP]. In this example, the client is proxy authenticating, 737 sending the authorization identity "fred" using in the (optional) 738 initial response. The server has obtained the client's 739 (authentication) identity from an external service, such as IPsec, 740 and has a security policy that permits that identity to assume the 741 identity of the asserted authorization identity. 743 To the protocol profile, the four octet sequence "fred" is an opaque 744 binary data. The SASL protocol profile for SMTP [SMTP-AUTH] specifies 745 that server challenges and client responses are encoded in BASE64 746 [BASE64, section 3]; the BASE64 encoding of "fred" is "ZnJlZA==". 748 S: 220 smtp.example.com ESMTP server ready 749 C: EHLO jgm.example.com 750 S: 250-smtp.example.com 751 S: 250 AUTH DIGEST-MD5 EXTERNAL 752 C: AUTH EXTERNAL ZnJlZA== 753 S: 235 Authentication successful. 755 The following example is almost identical to the one above, but the 756 client doesn't request proxy authentication. 758 S: 220 smtp.example.com ESMTP server ready 759 C: EHLO jgm.example.com 760 S: 250-smtp.example.com 761 S: 250 AUTH DIGEST-MD5 EXTERNAL 762 C: AUTH EXTERNAL 763 S: 235 Authentication successful. 765 The following is an example of an EXTERNAL authentication in the 766 IMAP4 protocol [IMAP]. IMAP4 doesn't support the initial response 767 feature of SASL. As in the previous example, the client doesn't 768 request proxy authentication. 770 S: * OK IMAP4rev1 Server 771 C: C01 CAPABILITY 772 S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=DIGEST-MD5 AUTH=EXTERNAL 773 [...] 774 C: A01 AUTHENTICATE EXTERNAL 775 (note that there is a space following the "+" in the following line) 777 Internet DRAFT SASL 28 June 2004 779 S: + 780 C: 781 S: A01 OK Success 783 8. IANA Considerations 785 8.1. Guidelines for IANA 787 It is requested that IANA updates the SASL mechanisms registry as 788 follows: 790 Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism 791 registrations to OBSOLETE. Change the "Published specification" 792 of the EXTERNAL mechanism to this document. Updated registration 793 information is provided in Section 8.6. 795 8.2. Registration procedure 797 Registration of a SASL mechanism is done by filling in the template 798 in section 8.5 and sending it via electronic mail to . 799 IANA has the right to reject obviously bogus registrations, but will 800 perform no review of claims made in the registration form. SASL 801 mechanism registrations are currently available at the URL 802 . 804 There is no naming convention for SASL mechanisms; any name that 805 conforms to the syntax of a SASL mechanism name can be registered. 806 However an IETF Standards Track document may reserve a portion of the 807 SASL mechanism namespace ("family of SASL mechanisms") for its own 808 use, amending the registration rules for that portion of the 809 namespace. Each family of SASL mechanisms MUST be identified by a 810 prefix. 812 While the registration procedures do not require it, authors of SASL 813 mechanisms are encouraged to seek community review and comment 814 whenever that is feasible. Authors may seek community review by 815 posting a specification of their proposed mechanism as an Internet- 816 Draft. SASL mechanisms intended for widespread use should be 817 standardized through the normal IETF process, when appropriate. 819 Internet DRAFT SASL 28 June 2004 821 8.3. Comments on SASL mechanism registrations 823 Comments on registered SASL mechanisms should first be sent to the 824 "owner" of the mechanism and/or to the SASL WG mailing list. 825 Submitters of comments may, after a reasonable attempt to contact the 826 owner, request IANA to attach their comment to the SASL mechanism 827 registration itself. If IANA approves of this, the comment will be 828 made accessible in conjunction with the SASL mechanism registration 829 itself. 831 8.4. Change control 833 Once a SASL mechanism registration has been published by IANA, the 834 author may request a change to its definition. The change request 835 follows the same procedure as the registration request. 837 The owner of a SASL mechanism may pass responsibility for the SASL 838 mechanism to another person or agency by informing IANA; this can be 839 done without discussion or review. 841 The IESG may reassign responsibility for a SASL mechanism. The most 842 common case of this will be to enable changes to be made to 843 mechanisms where the author of the registration has died, moved out 844 of contact or is otherwise unable to make changes that are important 845 to the community. 847 SASL mechanism registrations may not be deleted; mechanisms which are 848 no longer believed appropriate for use can be declared OBSOLETE by a 849 change to their "intended usage" field; such SASL mechanisms will be 850 clearly marked in the lists published by IANA. 852 The IESG is considered to be the owner of all SASL mechanisms which 853 are on the IETF standards track. 855 8.5. Registration template 857 Subject: Registration of SASL mechanism X 859 Family of SASL mechanisms: (YES or NO) 861 SASL mechanism name (or prefix for the family): 863 Security considerations: 865 Published specification (optional, recommended): 867 Person & email address to contact for further information: 869 Internet DRAFT SASL 28 June 2004 871 Intended usage: 873 (One of COMMON, LIMITED USE or OBSOLETE) 875 Owner/Change controller: 877 (Any other information that the author deems interesting may be 878 added below this line.) 880 8.6. The EXTERNAL mechanism registration 882 It is requested that the SASL Mechanism registry [IANA-SASL] entry 883 for the EXTERNAL mechanism be updated to reflect that this document 884 now provides its technical specification. 886 Subject: Updated Registration of SASL mechanism EXTERNAL 888 Family of SASL mechanisms: NO 890 SASL mechanism name: EXTERNAL 892 Security considerations: See RFC XXXX, section 9. 894 Published specification (optional, recommended): RFC XXXX 896 Person & email address to contact for further information: 897 Alexey Melnikov 899 Intended usage: COMMON 901 Owner/Change controller: IESG 903 Note: Updates existing entry for EXTERNAL 905 9. Security considerations 907 Security issues are discussed throughout this memo. 909 When the client selects a security layer with at least integrity 910 protection, this protects against an active attacker hijacking the 911 connection and modifying the authentication exchange to negotiate a 912 plaintext connection. 914 When a server or client supports multiple authentication mechanisms, 915 each of which has a different security strength, it is possible for 916 an active attacker to cause a party to use the least secure mechanism 918 Internet DRAFT SASL 28 June 2004 920 supported. To protect against this sort of attack, a client or 921 server which supports mechanisms of different strengths should have a 922 configurable minimum strength that it will use. It is not sufficient 923 for this minimum strength check to only be on the server, since an 924 active attacker can change which mechanisms the client sees as being 925 supported, causing the client to send authentication credentials for 926 its weakest supported mechanism. 928 The client's selection of a SASL mechanism is done in the clear and 929 may be modified by an active attacker. It is important for any new 930 SASL mechanisms to be designed such that an active attacker cannot 931 obtain an authentication with weaker security properties by modifying 932 the SASL mechanism name and/or the challenges and responses. 934 In order to detect Man-in-the-middle (MITM) attacks the client MAY 935 list available SASL mechanisms both before and after the SASL 936 security layer is negotiated. This allows the client to detect 937 active attacks that remove mechanisms from the server's list of 938 supported mechanisms, and allows the client to ensure that it is 939 using the best mechanism supported by both client and server. New 940 protocol profiles SHOULD require servers to make the list of SASL 941 mechanisms available for the initial authentication available to the 942 client after security layers are established. Some older protocols 943 do not require this (or don't support listing of SASL mechanisms once 944 authentication is complete); for these protocols clients MUST NOT 945 treat an empty list of SASL mechanisms after authentication as a MITM 946 attack. 948 Any protocol interactions prior to authentication are performed in 949 the clear and may be modified by an active attacker. In the case 950 where a client selects integrity protection, it is important that any 951 security-sensitive protocol negotiations be performed after 952 authentication is complete. Protocols should be designed such that 953 negotiations performed prior to authentication should be either 954 ignored or revalidated once authentication is complete. 956 When use of a security layer is negotiated by the authentication 957 protocol exchange, the receiver should handle gracefully any 958 protected data buffer larger than the defined/negotiated maximal 959 size. In particular, it must not blindly allocate the amount of 960 memory specified in the buffer size field, as this might cause the 961 "out of memory" condition. If the receiver detects a large block, it 962 SHOULD close the connection. 964 Distributed server implementations need to be careful in how they 965 trust other parties. In particular, authentication secrets should 966 only be disclosed to other parties that are trusted to manage and use 967 those secrets in manner acceptable to disclosing party. Applications 969 Internet DRAFT SASL 28 June 2004 971 using SASL assume that SASL security layers providing data 972 confidentiality are secure even when an attacker chooses the text to 973 be protected by the security layer. Similarly applications assume 974 that the SASL security layer is secure even if the attacker can 975 manipulate the ciphertext output of the security layer. New SASL 976 mechanisms MUST meet these assumptions. 978 "stringprep" and Unicode security considerations apply to 979 authentication identities, authorization identities and passwords. 981 The EXTERNAL mechanism provides no security protection; it is 982 vulnerable to spoofing by either client or server, active attack, and 983 eavesdropping. It should only be used when external security 984 mechanisms are present and have sufficient strength. 986 10. References 988 10.1. Normative References 990 [ABNF] Crocker, D. (Ed.), Overell, P., "Augmented BNF for Syntax 991 Specifications: ABNF", RFC 2234, November 1997 993 [ASCII] American National Standards Institute, "Code Extension 994 Techniques for Use with the 7-bit Coded Character Set of American 995 National Standard Code (ASCII) for Information Interchange", FIPS PUB 996 35, 1974 998 [CHARSET-POLICY] Alvestrand, H., "IETF Policy on Character Sets and 999 Languages", RFC 2277, BCP 18, January 1998 1001 [GSSAPI] Linn, J., "Generic Security Service Application Program 1002 Interface, Version 2, Update 1", RFC 2743, January 2000 1004 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1005 Requirement Levels", RFC 2119, BCP 19, March 1997 1007 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 1008 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, 1009 MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the 1010 "Unicode Standard Annex #27: Unicode 3.1" 1011 (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard 1012 Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/). 1014 [Stringprep] Hoffman, P., Blanchet, M., "Preparation of 1015 Internationalized Strings ("stringprep")", RFC 3454, December 2002. 1017 [SASLprep] Zeilenga, K., "SASLprep: Stringprep profile for user names 1018 and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt. 1020 Internet DRAFT SASL 28 June 2004 1022 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1023 RFC 3629, STD 63, November 2003. 1025 10.2. Informative References 1027 [SASL-GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", work in 1028 progress, draft-ietf-sasl-gssapi-XX.txt, November 2003 1030 [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest 1031 Authentication as a SASL Mechanism", work in progress, draft-ietf- 1032 sasl-rfc2831bis-XX.txt, replaces RFC 2831 1034 [SASL-OTP] Newman, C., "The One-Time-Password SASL Mechanism", RFC 1035 2444, October 1998. 1037 [SASL-SECURID] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 1038 2808, April 2000. 1040 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 1041 2001. 1043 [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", 1044 RFC 2554, March 1999. 1046 Being revised by Siemborski, R., "SMTP Service Extension for 1047 Authentication", work in progress, draft-siemborski-rfc2554bis- 1048 XX.txt. 1050 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol 1051 (XMPP): Core", work in progress, draft-ietf-xmpp-core-XX.txt. 1053 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 1054 Encodings", RFC 3548, July 2003. 1056 [RFC-INSTRUCTIONS] Postel, J., Reynolds, J., "Instructions to RFC 1057 Authors", RFC 2223, October 1997. 1059 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) 1060 MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms. 1062 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1063 2246, January 1999. 1065 [IPSec] Kent, S., and R. Atkinson, "Security Architecture for the 1066 Internet Protocol", RFC 2401, November 1998. 1068 [Sec-Glossary] Shirey, R., "Internet Security Glossary", RFC 2828, 1070 Internet DRAFT SASL 28 June 2004 1072 May 2000. 1074 11. Editor's Address 1076 Alexey Melnikov 1077 Isode Limited 1078 5 Castle Business Village 1079 36 Station Road 1080 Hampton, Middlesex, 1081 TW12 2BX, United Kingdom 1083 Email: Alexey.Melnikov@isode.com 1084 URI: http://www.melnikov.ca/ 1086 12. Acknowledgments 1088 This document is a revision of RFC 2222 written by John G. Myers. He 1089 also contributed significantly to this revision. 1091 Contributions of many members of the SASL mailing list are gratefully 1092 acknowledged, in particular Kurt Zeilenga, Peter Saint-Andre, Rob 1093 Siemborski, Magnus Nystrom, Jeffrey Hutzelman, Hallvard B Furuseth, 1094 Tony Hansen, Simon Josefsson, Abhijit Menon-Sen, RL 'Bob' Morgan, Sam 1095 Hartman, Tim Alsop and Luke Howard for proofreading the document and 1096 various editorial suggestions. 1098 13. Full Copyright Statement 1100 Copyright (C) The Internet Society (2004). This document is subject 1101 to the rights, licenses and restrictions contained in BCP 78, and 1102 except as set forth therein, the authors retain all their rights. 1104 This document and translations of it may be copied and furnished to 1105 others, and derivative works that comment on or otherwise explain it 1106 or assist in its implementation may be prepared, copied, published 1107 and distributed, in whole or in part, without restriction of any 1108 kind, provided that the above copyright notice and this paragraph are 1109 included on all such copies and derivative works. However, this 1110 document itself may not be modified in any way, such as by removing 1111 the copyright notice or references to the Internet Society or other 1112 Internet organizations, except as needed for the purpose of 1113 developing Internet standards in which case the procedures for 1114 copyrights defined in the Internet Standards process must be 1115 followed, or as required to translate it into languages other than 1116 English. 1118 Internet DRAFT SASL 28 June 2004 1120 The limited permissions granted above are perpetual and will not be 1121 revoked by the Internet Society or its successors or assigns. 1123 This document and the information contained herein are provided on an 1124 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1125 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1126 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1127 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1128 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1129 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1131 Acknowledgement 1133 Funding for the RFC Editor function is currently provided by the 1134 Internet Society. 1136 14. Intellectual Property 1138 The IETF takes no position regarding the validity or scope of any 1139 Intellectual Property Rights or other rights that might be claimed to 1140 pertain to the implementation or use of the technology described in 1141 this document or the extent to which any license under such rights 1142 might or might not be available; nor does it represent that it has 1143 made any independent effort to identify any such rights. Information 1144 on the procedures with respect to rights in RFC documents can be 1145 found in BCP 78 and BCP 79. 1147 Copies of IPR disclosures made to the IETF Secretariat and any 1148 assurances of licenses to be made available, or the result of an 1149 attempt made to obtain a general license or permission for the use of 1150 such proprietary rights by implementers or users of this 1151 specification can be obtained from the IETF on-line IPR repository at 1152 http://www.ietf.org/ipr. 1154 The IETF invites any interested party to bring to its attention any 1155 copyrights, patents or patent applications, or other proprietary 1156 rights that may cover technology that may be required to implement 1157 this standard. Please address the information to the IETF at ietf- 1158 ipr@ietf.org. 1160 Appendix A. Relation of SASL to transport security 1162 Questions have been raised about the relationship between SASL and 1163 various services (such as IPsec and TLS) which provide a secured 1164 connection. 1166 Two of the key features of SASL are: 1168 Internet DRAFT SASL 28 June 2004 1170 The separation of the authorization identity from the identity in 1171 the client's credentials. This permits agents such as proxy 1172 servers to authenticate using their own credentials, yet request 1173 the access privileges of the identity for which they are proxying. 1175 Upon successful completion of an authentication exchange, the 1176 server knows the authorization identity the client wishes to use. 1177 This allows servers to move to a "user is authenticated" state in 1178 the protocol. 1180 These features are extremely important to some application protocols, 1181 yet Transport Security services do not always provide them. To 1182 define SASL mechanisms based on these services would be a very messy 1183 task, as the framing of these services would be redundant with the 1184 framing of SASL and some method of providing these important SASL 1185 features would have to be devised. 1187 Sometimes it is desired to enable within an existing connection the 1188 use of a security service which does not fit the SASL model. (TLS is 1189 an example of such a service.) This can be done by adding a command, 1190 for example "STARTTLS", to the protocol. Such a command is outside 1191 the scope of SASL, and should be different from the command which 1192 starts a SASL authentication protocol exchange. 1194 In certain situations, it is reasonable to use SASL underneath one of 1195 these Transport Security services. The transport service would 1196 secure the connection, either service would authenticate the client, 1197 and SASL would negotiate the authorization identity. The SASL 1198 negotiation would be what moves the protocol from "unauthenticated" 1199 to "authenticated" state. The "EXTERNAL" SASL mechanism is 1200 explicitly intended to handle the case where the transport service 1201 secures the connection and authenticates the client and SASL 1202 negotiates the authorization identity. 1204 Appendix B. Relationship to other documents 1206 This document obsoletes RFC 2222. It replaces all portions of RFC 1207 2222 excepting sections 7.1 (Kerberos version 4 mechanism), 7.2 1208 (GSSAPI mechanism), 7.3 (S/Key mechanism). The Kerberos version 4 1209 (KERBEROS_IV) and S/Key (SKEY) mechanisms are now viewed as obsolete. 1210 The GSSAPI mechanism is now separately specified [SASL-GSSAPI]. 1212 Appendix C. Changes since RFC 2222 1214 The GSSAPI mechanism was removed. It is now specified in a separate 1215 document [SASL-GSSAPI]. 1217 The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has 1219 Internet DRAFT SASL 28 June 2004 1221 been removed. 1223 The "SKEY" mechanism described in RFC 2222 is obsolete and has been 1224 removed. It has been replaced by the OTP mechanism [SASL-OTP]. 1226 The introduction has been substantially reorganized and clarified. 1228 Clarified the definition and semantics of the authorization identity. 1230 Prohibited the NUL character in authorization identities. 1232 Added a section on character string issues. 1234 The word "must" in the first paragraph of the "Protocol profile 1235 requirements" section was changed to "MUST". 1237 Specified that protocol profiles SHOULD provide a way for clients to 1238 discover available SASL mechanisms. 1240 Made the requirement that protocol profiles specify the semantics of 1241 the authorization identity optional to the protocol profile. 1242 Clarified that such a specification is a refinement of the definition 1243 in the base SASL spec. 1245 Added a requirement discouraging protocol profiles from breaking the 1246 separation between protocol and mechanism. 1248 Mentioned that standards track documents may carve out their own 1249 portions of the SASL mechanism namespace and may amend registration 1250 rules for the portion. However registration of individual SASL 1251 mechanisms is still required. 1253 Specified that the authorization identity in the EXTERNAL mechanism 1254 is encoded in UTF-8. 1256 Added a statement that a protocol profile SHOULD allow challenge data 1257 to be sent with a success indication. 1259 Added a security consideration for the EXTERNAL mechanism. 1261 Clarified sections concerning success with additional data. 1263 Cleaned up IANA considerations/registrations and assembled them in 1264 one place. 1266 Updated references and split them into Informative and Normative. 1268 Added text to the Security Considerations section regarding handling 1270 Internet DRAFT SASL 28 June 2004 1272 of extremely large SASL blocks. 1274 Replaced UTF-8 ABNF with the reference to the UTF-8 document. 1276 Added text about SASLprep for authentication identities and 1277 passwords. Described where SASLprep preparation should take place. 1279 Added paragraph about verifying authorization identities. 1281 Added a protocol profile requirement to specify interaction between 1282 SASL and TLS security layers. 1284 Added a protocol profile requirement to specify if it supports 1285 reauthentication. 1287 Removed the text that seemed to suggest that SASL security layer must 1288 not be used when TLS is available. 1290 Created two subsections in 3.2 to talk separately about proxy 1291 authorization and format of the authorization identities. 1293 Made requirement to verify that an authorization identity is correct 1294 by performing SASLprep a SHOULD, instead of a MUST. 1296 Clarified that each SASL mechanism must decide where SASLprep is 1297 taking place. 1299 Added 4 new examples for initial response and additional data with 1300 success. 1302 Added text on checking the list of available SASL mechanisms after 1303 negotiating a security layer. 1305 Added definition of "integrity protection" and "confidentiality 1306 protection". 1308 Added warning about negotiating no layer once a security layer is 1309 negotiated. 1311 Added new section with guidelines to a SASL mechanism designer. 1313 Added a requirement to specify how an empty initial challenge is 1314 encoded if initial response is supported by a protocol. 1316 Clarified that empty "additional data with success" is not allowed. 1318 Replaced "buffers of security encoded data" with "buffers of 1319 protected data" for clarity. 1321 Internet DRAFT SASL 28 June 2004 1323 Clarified that SASL EXTERNAL can be used even with SASL profiles that 1324 don't support initial data with success. 1326 Internet DRAFT SASL 28 June 2004 1328 Status of this Memo .......................................... i 1329 Abstract ..................................................... 2 1330 1. Conventions used in this document ........................ 2 1331 2. Introduction ........................................... 2 1332 3. Authentication mechanisms .............................. 4 1333 3.1. Authentication protocol exchange ....................... 5 1334 3.2. Authorization and authentication identities ............ 6 1335 3.2.1. Authorization identities and proxy authentication .... 6 1336 3.2.2. Authorization Identity Format ........................ 7 1337 3.3. Security layers ........................................ 7 1338 4. Protocol profile requirements .......................... 8 1339 5. Mechanism profile guidelines .......................... 10 1340 6. Specific issues ....................................... 11 1341 6.1. Client sends data first ............................... 11 1342 6.1.1. Client sends data first examples .................... 11 1343 6.2. Server returns success with additional data ........... 12 1344 6.2.1. Server returns success with additional data examples 13 1345 6.3. Multiple authentications .............................. 14 1346 7. The EXTERNAL mechanism ................................ 15 1347 7.1. Formal syntax ......................................... 15 1348 7.2. Examples of SASL EXTERNAL ............................. 16 1349 8. IANA Considerations ................................... 17 1350 8.1. Guidelines for IANA ................................... 17 1351 8.2. Registration procedure ................................ 17 1352 8.3. Comments on SASL mechanism registrations .............. 18 1353 8.4. Change control ........................................ 18 1354 8.5. Registration template ................................. 18 1355 8.6. The EXTERNAL mechanism registration ................... 19 1356 9. Security considerations ................................ 19 1357 10. References ........................................... 21 1358 10.1. Normative References ................................. 21 1359 10.2. Informative References ............................... 22 1360 11. Editor's Address ...................................... 23 1361 12. Acknowledgments ....................................... 23 1362 13. Full Copyright Statement .............................. 23 1363 14. Intellectual Property ................................. 24 1364 Appendix A. Relation of SASL to transport security .......... 24 1365 Appendix B. Relationship to other documents ................. 25 1366 Appendix C. Changes since RFC 2222 .......................... 25