imapext-2007

annotate docs/rfc/rfc4422.txt @ 0:ada5e610ab86

find changesets by author, revision, files, or words in the commit message
imap-2007e
author yuuji@gentei.org
date Mon, 14 Sep 2009 15:17:45 +0900
parents
children
rev   line source
yuuji@0 1
yuuji@0 2
yuuji@0 3
yuuji@0 4
yuuji@0 5
yuuji@0 6
yuuji@0 7 Network Working Group A. Melnikov, Ed.
yuuji@0 8 Request for Comments: 4422 Isode Limited
yuuji@0 9 Obsoletes: 2222 K. Zeilenga, Ed.
yuuji@0 10 Category: Standards Track OpenLDAP Foundation
yuuji@0 11 June 2006
yuuji@0 12
yuuji@0 13
yuuji@0 14 Simple Authentication and Security Layer (SASL)
yuuji@0 15
yuuji@0 16 Status of This Memo
yuuji@0 17
yuuji@0 18 This document specifies an Internet standards track protocol for the
yuuji@0 19 Internet community, and requests discussion and suggestions for
yuuji@0 20 improvements. Please refer to the current edition of the "Internet
yuuji@0 21 Official Protocol Standards" (STD 1) for the standardization state
yuuji@0 22 and status of this protocol. Distribution of this memo is unlimited.
yuuji@0 23
yuuji@0 24 Copyright Notice
yuuji@0 25
yuuji@0 26 Copyright (C) The Internet Society (2006).
yuuji@0 27
yuuji@0 28 Abstract
yuuji@0 29
yuuji@0 30 The Simple Authentication and Security Layer (SASL) is a framework
yuuji@0 31 for providing authentication and data security services in
yuuji@0 32 connection-oriented protocols via replaceable mechanisms. It
yuuji@0 33 provides a structured interface between protocols and mechanisms.
yuuji@0 34 The resulting framework allows new protocols to reuse existing
yuuji@0 35 mechanisms and allows old protocols to make use of new mechanisms.
yuuji@0 36 The framework also provides a protocol for securing subsequent
yuuji@0 37 protocol exchanges within a data security layer.
yuuji@0 38
yuuji@0 39 This document describes how a SASL mechanism is structured, describes
yuuji@0 40 how protocols include support for SASL, and defines the protocol for
yuuji@0 41 carrying a data security layer over a connection. In addition, this
yuuji@0 42 document defines one SASL mechanism, the EXTERNAL mechanism.
yuuji@0 43
yuuji@0 44 This document obsoletes RFC 2222.
yuuji@0 45
yuuji@0 46
yuuji@0 47
yuuji@0 48
yuuji@0 49
yuuji@0 50
yuuji@0 51
yuuji@0 52
yuuji@0 53
yuuji@0 54
yuuji@0 55
yuuji@0 56
yuuji@0 57
yuuji@0 58 Melnikov & Zeilenga Standards Track [Page 1]
yuuji@0 59
yuuji@0 60 RFC 4422 SASL June 2006
yuuji@0 61
yuuji@0 62
yuuji@0 63 Table of Contents
yuuji@0 64
yuuji@0 65 1. Introduction ....................................................3
yuuji@0 66 1.1. Document Audiences .........................................4
yuuji@0 67 1.2. Relationship to Other Documents ............................4
yuuji@0 68 1.3. Conventions ................................................5
yuuji@0 69 2. Identity Concepts ...............................................5
yuuji@0 70 3. The Authentication Exchange .....................................6
yuuji@0 71 3.1. Mechanism Naming ...........................................8
yuuji@0 72 3.2. Mechanism Negotiation ......................................9
yuuji@0 73 3.3. Request Authentication Exchange ............................9
yuuji@0 74 3.4. Challenges and Responses ...................................9
yuuji@0 75 3.4.1. Authorization Identity String ......................10
yuuji@0 76 3.5. Aborting Authentication Exchanges .........................10
yuuji@0 77 3.6. Authentication Outcome ....................................11
yuuji@0 78 3.7. Security Layers ...........................................12
yuuji@0 79 3.8. Multiple Authentications ..................................12
yuuji@0 80 4. Protocol Requirements ..........................................13
yuuji@0 81 5. Mechanism Requirements .........................................16
yuuji@0 82 6. Security Considerations ........................................18
yuuji@0 83 6.1. Active Attacks ............................................19
yuuji@0 84 6.1.1. Hijack Attacks .....................................19
yuuji@0 85 6.1.2. Downgrade Attacks ..................................19
yuuji@0 86 6.1.3. Replay Attacks .....................................20
yuuji@0 87 6.1.4. Truncation Attacks .................................20
yuuji@0 88 6.1.5. Other Active Attacks ...............................20
yuuji@0 89 6.2. Passive Attacks ...........................................20
yuuji@0 90 6.3. Re-keying .................................................21
yuuji@0 91 6.4. Other Considerations ......................................21
yuuji@0 92 7. IANA Considerations ............................................22
yuuji@0 93 7.1. SASL Mechanism Registry ...................................22
yuuji@0 94 7.2. Registration Changes ......................................26
yuuji@0 95 8. References .....................................................26
yuuji@0 96 8.1. Normative References ......................................26
yuuji@0 97 8.2. Informative References ....................................27
yuuji@0 98 9. Acknowledgements ...............................................28
yuuji@0 99 Appendix A. The SASL EXTERNAL Mechanism ..........................29
yuuji@0 100 A.1. EXTERNAL Technical Specification ..........................29
yuuji@0 101 A.2. SASL EXTERNAL Examples ....................................30
yuuji@0 102 A.3. Security Considerations ...................................31
yuuji@0 103 Appendix B. Changes since RFC 2222 ...............................31
yuuji@0 104
yuuji@0 105
yuuji@0 106
yuuji@0 107
yuuji@0 108
yuuji@0 109
yuuji@0 110
yuuji@0 111
yuuji@0 112
yuuji@0 113
yuuji@0 114 Melnikov & Zeilenga Standards Track [Page 2]
yuuji@0 115
yuuji@0 116 RFC 4422 SASL June 2006
yuuji@0 117
yuuji@0 118
yuuji@0 119 1. Introduction
yuuji@0 120
yuuji@0 121 The Simple Authentication and Security Layer (SASL) is a framework
yuuji@0 122 for providing authentication and data security services in
yuuji@0 123 connection-oriented protocols via replaceable mechanisms. SASL
yuuji@0 124 provides a structured interface between protocols and mechanisms.
yuuji@0 125 SASL also provides a protocol for securing subsequent protocol
yuuji@0 126 exchanges within a data security layer. The data security layer can
yuuji@0 127 provide data integrity, data confidentiality, and other services.
yuuji@0 128
yuuji@0 129 SASL's design is intended to allow new protocols to reuse existing
yuuji@0 130 mechanisms without requiring redesign of the mechanisms and allows
yuuji@0 131 existing protocols to make use of new mechanisms without redesign of
yuuji@0 132 protocols.
yuuji@0 133
yuuji@0 134 SASL is conceptually a framework that provides an abstraction layer
yuuji@0 135 between protocols and mechanisms as illustrated in the following
yuuji@0 136 diagram.
yuuji@0 137
yuuji@0 138 SMTP LDAP XMPP Other protocols ...
yuuji@0 139 \ | | /
yuuji@0 140 \ | | /
yuuji@0 141 SASL abstraction layer
yuuji@0 142 / | | \
yuuji@0 143 / | | \
yuuji@0 144 EXTERNAL GSSAPI PLAIN Other mechanisms ...
yuuji@0 145
yuuji@0 146 It is through the interfaces of this abstraction layer that the
yuuji@0 147 framework allows any protocol to utilize any mechanism. While this
yuuji@0 148 layer does generally hide the particulars of protocols from
yuuji@0 149 mechanisms and the particulars of mechanisms from protocols, this
yuuji@0 150 layer does not generally hide the particulars of mechanisms from
yuuji@0 151 protocol implementations. For example, different mechanisms require
yuuji@0 152 different information to operate, some of them use password-based
yuuji@0 153 authentication, some of then require realm information, others make
yuuji@0 154 use of Kerberos tickets, certificates, etc. Also, in order to
yuuji@0 155 perform authorization, server implementations generally have to
yuuji@0 156 implement identity mapping between authentication identities, whose
yuuji@0 157 form is mechanism specific, and authorization identities, whose form
yuuji@0 158 is application protocol specific. Section 2 discusses identity
yuuji@0 159 concepts.
yuuji@0 160
yuuji@0 161 It is possible to design and implement this framework in ways that do
yuuji@0 162 abstract away particulars of similar mechanisms. Such a framework
yuuji@0 163 implementation, as well as mechanisms implementations, could be
yuuji@0 164 designed not only to be shared by multiple implementations of a
yuuji@0 165 particular protocol but to be shared by implementations of multiple
yuuji@0 166 protocols.
yuuji@0 167
yuuji@0 168
yuuji@0 169
yuuji@0 170 Melnikov & Zeilenga Standards Track [Page 3]
yuuji@0 171
yuuji@0 172 RFC 4422 SASL June 2006
yuuji@0 173
yuuji@0 174
yuuji@0 175 The framework incorporates interfaces with both protocols and
yuuji@0 176 mechanisms in which authentication exchanges are carried out.
yuuji@0 177 Section 3 discusses SASL authentication exchanges.
yuuji@0 178
yuuji@0 179 To use SASL, each protocol (amongst other items) provides a method
yuuji@0 180 for identifying which mechanism is to be used, a method for exchange
yuuji@0 181 of mechanism-specific server-challenges and client-responses, and a
yuuji@0 182 method for communicating the outcome of the authentication exchange.
yuuji@0 183 Section 4 discusses SASL protocol requirements.
yuuji@0 184
yuuji@0 185 Each SASL mechanism defines (amongst other items) a series of
yuuji@0 186 server-challenges and client-responses that provide authentication
yuuji@0 187 services and negotiate data security services. Section 5 discusses
yuuji@0 188 SASL mechanism requirements.
yuuji@0 189
yuuji@0 190 Section 6 discusses security considerations. Section 7 discusses
yuuji@0 191 IANA considerations. Appendix A defines the SASL EXTERNAL mechanism.
yuuji@0 192
yuuji@0 193 1.1. Document Audiences
yuuji@0 194
yuuji@0 195 This document is written to serve several different audiences:
yuuji@0 196
yuuji@0 197 - protocol designers using this specification to support
yuuji@0 198 authentication in their protocol,
yuuji@0 199
yuuji@0 200 - mechanism designers that define new SASL mechanisms, and
yuuji@0 201
yuuji@0 202 - implementors of clients or servers for those protocols that
yuuji@0 203 support SASL.
yuuji@0 204
yuuji@0 205 While the document organization is intended to allow readers to focus
yuuji@0 206 on details relevant to their engineering, readers are encouraged to
yuuji@0 207 read and understand all aspects of this document.
yuuji@0 208
yuuji@0 209 1.2. Relationship to Other Documents
yuuji@0 210
yuuji@0 211 This document obsoletes RFC 2222. It replaces all portions of RFC
yuuji@0 212 2222 excepting sections 7.1 (the KERBEROS_IV mechanism), 7.2 (the
yuuji@0 213 GSSAPI mechanism), 7.3 (the SKEY mechanism). The KERBEROS_IV and
yuuji@0 214 SKEY mechanisms are now viewed as obsolete and their specifications
yuuji@0 215 provided in RFC 2222 are Historic. The GSSAPI mechanism is now
yuuji@0 216 separately specified [SASL-GSSAPI].
yuuji@0 217
yuuji@0 218 Appendix B provides a summary of changes since RFC 2222.
yuuji@0 219
yuuji@0 220
yuuji@0 221
yuuji@0 222
yuuji@0 223
yuuji@0 224
yuuji@0 225
yuuji@0 226 Melnikov & Zeilenga Standards Track [Page 4]
yuuji@0 227
yuuji@0 228 RFC 4422 SASL June 2006
yuuji@0 229
yuuji@0 230
yuuji@0 231 1.3. Conventions
yuuji@0 232
yuuji@0 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
yuuji@0 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
yuuji@0 235 document are to be interpreted as described in BCP 14 [RFC2119].
yuuji@0 236
yuuji@0 237 Character names in this document use the notation for code points and
yuuji@0 238 names from the Unicode Standard [Unicode]. For example, the letter
yuuji@0 239 "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
yuuji@0 240
yuuji@0 241 Note: a glossary of terms used in Unicode can be found in [Glossary].
yuuji@0 242 Information on the Unicode character encoding model can be found in
yuuji@0 243 [CharModel].
yuuji@0 244
yuuji@0 245 In examples, "C:" and "S:" indicate lines of data to be sent by the
yuuji@0 246 client and server, respectively. Lines have been wrapped for
yuuji@0 247 improved readability.
yuuji@0 248
yuuji@0 249 2. Identity Concepts
yuuji@0 250
yuuji@0 251 In practice, authentication and authorization may involve multiple
yuuji@0 252 identities, possibly in different forms (simple username, Kerberos
yuuji@0 253 principal, X.500 Distinguished Name, etc.), possibly with different
yuuji@0 254 representations (e.g., ABNF-described UTF-8 encoded Unicode character
yuuji@0 255 string, BER-encoded Distinguished Name). While technical
yuuji@0 256 specifications often prescribe both the identity form and
yuuji@0 257 representation used on the network, different identity forms and/or
yuuji@0 258 representations may be (and often are) used within implementations.
yuuji@0 259 How identities of different forms relate to each other is, generally,
yuuji@0 260 a local matter. In addition, the forms and representations used
yuuji@0 261 within an implementation are a local matter.
yuuji@0 262
yuuji@0 263 However, conceptually, the SASL framework involves two identities:
yuuji@0 264
yuuji@0 265 1) an identity associated with the authentication credentials
yuuji@0 266 (termed the authentication identity), and
yuuji@0 267
yuuji@0 268 2) an identity to act as (termed the authorization identity).
yuuji@0 269
yuuji@0 270 SASL mechanism specifications describe the credential form(s) (e.g.,
yuuji@0 271 X.509 certificates, Kerberos tickets, simple username/password) used
yuuji@0 272 to authenticate the client, including (where appropriate) the syntax
yuuji@0 273 and semantics of authentication identities carried in the
yuuji@0 274 credentials. SASL protocol specifications describe the identity
yuuji@0 275 form(s) used in authorization and, in particular, prescribe the
yuuji@0 276 syntax and semantics of the authorization identity character string
yuuji@0 277 to be transferred by mechanisms.
yuuji@0 278
yuuji@0 279
yuuji@0 280
yuuji@0 281
yuuji@0 282 Melnikov & Zeilenga Standards Track [Page 5]
yuuji@0 283
yuuji@0 284 RFC 4422 SASL June 2006
yuuji@0 285
yuuji@0 286
yuuji@0 287 The client provides its credentials (which include or imply an
yuuji@0 288 authentication identity) and, optionally, a character string
yuuji@0 289 representing the requested authorization identity as part of the SASL
yuuji@0 290 exchange. When this character string is omitted or empty, the client
yuuji@0 291 is requesting to act as the identity associated with the credentials
yuuji@0 292 (e.g., the user is requesting to act as the authentication identity).
yuuji@0 293
yuuji@0 294 The server is responsible for verifying the client's credentials and
yuuji@0 295 verifying that the identity it associates with the client's
yuuji@0 296 credentials (e.g., the authentication identity) is allowed to act as
yuuji@0 297 the authorization identity. A SASL exchange fails if either (or
yuuji@0 298 both) of these verifications fails. (The SASL exchange may fail for
yuuji@0 299 other reasons, such as service authorization failure.)
yuuji@0 300
yuuji@0 301 However, the precise form(s) of the authentication identities (used
yuuji@0 302 within the server in its verifications, or otherwise) and the precise
yuuji@0 303 form(s) of the authorization identities (used in making authorization
yuuji@0 304 decisions, or otherwise) are beyond the scope of SASL and this
yuuji@0 305 specification. In some circumstances, the precise identity forms
yuuji@0 306 used in some context outside of the SASL exchange may be dictated by
yuuji@0 307 other specifications. For instance, an identity assumption
yuuji@0 308 authorization (proxy authorization) policy specification may dictate
yuuji@0 309 how authentication and authorization identities are represented in
yuuji@0 310 policy statements.
yuuji@0 311
yuuji@0 312 3. The Authentication Exchange
yuuji@0 313
yuuji@0 314 Each authentication exchange consists of a message from the client to
yuuji@0 315 the server requesting authentication via a particular mechanism,
yuuji@0 316 followed by one or more pairs of challenges from the server and
yuuji@0 317 responses from the client, followed by a message from the server
yuuji@0 318 indicating the outcome of the authentication exchange. (Note:
yuuji@0 319 exchanges may also be aborted as discussed in Section 3.5.)
yuuji@0 320
yuuji@0 321 The following illustration provides a high-level overview of an
yuuji@0 322 authentication exchange.
yuuji@0 323
yuuji@0 324 C: Request authentication exchange
yuuji@0 325 S: Initial challenge
yuuji@0 326 C: Initial response
yuuji@0 327 <additional challenge/response messages>
yuuji@0 328 S: Outcome of authentication exchange
yuuji@0 329
yuuji@0 330 If the outcome is successful and a security layer was negotiated,
yuuji@0 331 this layer is then installed (see Section 3.7). This also applies to
yuuji@0 332 the following illustrations.
yuuji@0 333
yuuji@0 334
yuuji@0 335
yuuji@0 336
yuuji@0 337
yuuji@0 338 Melnikov & Zeilenga Standards Track [Page 6]
yuuji@0 339
yuuji@0 340 RFC 4422 SASL June 2006
yuuji@0 341
yuuji@0 342
yuuji@0 343 Some mechanisms specify that the first data sent in the
yuuji@0 344 authentication exchange is from the client to the server. Protocols
yuuji@0 345 may provide an optional initial response field in the request message
yuuji@0 346 to carry this data. Where the mechanism specifies that the first
yuuji@0 347 data sent in the exchange is from the client to the server, the
yuuji@0 348 protocol provides an optional initial response field, and the client
yuuji@0 349 uses this field, the exchange is shortened by one round-trip:
yuuji@0 350
yuuji@0 351 C: Request authentication exchange + Initial response
yuuji@0 352 <additional challenge/response messages>
yuuji@0 353 S: Outcome of authentication exchange
yuuji@0 354
yuuji@0 355 Where the mechanism specifies that the first data sent in the
yuuji@0 356 exchange is from the client to the server and this field is
yuuji@0 357 unavailable or unused, the client request is followed by an empty
yuuji@0 358 challenge.
yuuji@0 359
yuuji@0 360 C: Request authentication exchange
yuuji@0 361 S: Empty Challenge
yuuji@0 362 C: Initial Response
yuuji@0 363 <additional challenge/response messages>
yuuji@0 364 S: Outcome of authentication exchange
yuuji@0 365
yuuji@0 366 Should a client include an initial response in its request where the
yuuji@0 367 mechanism does not allow the client to send data first, the
yuuji@0 368 authentication exchange fails.
yuuji@0 369
yuuji@0 370 Some mechanisms specify that the server is to send additional data to
yuuji@0 371 the client when indicating a successful outcome. Protocols may
yuuji@0 372 provide an optional additional data field in the outcome message to
yuuji@0 373 carry this data. Where the mechanism specifies that the server is to
yuuji@0 374 return additional data with the successful outcome, the protocol
yuuji@0 375 provides an optional additional data field in the outcome message,
yuuji@0 376 and the server uses this field, the exchange is shortened by one
yuuji@0 377 round-trip:
yuuji@0 378
yuuji@0 379 C: Request authentication exchange
yuuji@0 380 S: Initial challenge
yuuji@0 381 C: Initial response
yuuji@0 382 <additional challenge/response messages>
yuuji@0 383 S: Outcome of authentication exchange with
yuuji@0 384 additional data with success
yuuji@0 385
yuuji@0 386 Where the mechanism specifies that the server is to return additional
yuuji@0 387 data to the client with a successful outcome and this field is
yuuji@0 388 unavailable or unused, the additional data is sent as a challenge
yuuji@0 389 whose response is empty. After receiving this response, the server
yuuji@0 390 then indicates the successful outcome.
yuuji@0 391
yuuji@0 392
yuuji@0 393
yuuji@0 394 Melnikov & Zeilenga Standards Track [Page 7]
yuuji@0 395
yuuji@0 396 RFC 4422 SASL June 2006
yuuji@0 397
yuuji@0 398
yuuji@0 399 C: Request authentication exchange
yuuji@0 400 S: Initial challenge
yuuji@0 401 C: Initial response
yuuji@0 402 <additional challenge/response messages>
yuuji@0 403 S: Additional data challenge
yuuji@0 404 C: Empty Response
yuuji@0 405 S: Outcome of authentication exchange
yuuji@0 406
yuuji@0 407 Where mechanisms specify that the first data sent in the exchange is
yuuji@0 408 from the client to the server and additional data is sent to the
yuuji@0 409 client along with indicating a successful outcome, and the protocol
yuuji@0 410 provides fields supporting both, then the exchange takes two fewer
yuuji@0 411 round-trips:
yuuji@0 412
yuuji@0 413 C: Request authentication exchange + Initial response
yuuji@0 414 <additional challenge/response messages>
yuuji@0 415 S: Outcome of authentication exchange
yuuji@0 416 with additional data with success
yuuji@0 417
yuuji@0 418 instead of:
yuuji@0 419
yuuji@0 420 C: Request authentication exchange
yuuji@0 421 S: Empty Challenge
yuuji@0 422 C: Initial Response
yuuji@0 423 <additional challenge/response messages>
yuuji@0 424 S: Additional data challenge
yuuji@0 425 C: Empty Response
yuuji@0 426 S: Outcome of authentication exchange
yuuji@0 427
yuuji@0 428 3.1. Mechanism Naming
yuuji@0 429
yuuji@0 430 SASL mechanisms are named by character strings, from 1 to 20
yuuji@0 431 characters in length, consisting of ASCII [ASCII] uppercase letters,
yuuji@0 432 digits, hyphens, and/or underscores. In the following Augmented
yuuji@0 433 Backus-Naur Form (ABNF) [RFC4234] grammar, the <sasl-mech> production
yuuji@0 434 defines the syntax of a SASL mechanism name.
yuuji@0 435
yuuji@0 436 sasl-mech = 1*20mech-char
yuuji@0 437 mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
yuuji@0 438 ; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _
yuuji@0 439 ; from ASCII character set.
yuuji@0 440
yuuji@0 441 UPPER-ALPHA = %x41-5A ; A-Z (uppercase only)
yuuji@0 442 DIGIT = %x30-39 ; 0-9
yuuji@0 443 HYPHEN = %x2D ; hyphen (-)
yuuji@0 444 UNDERSCORE = %x5F ; underscore (_)
yuuji@0 445
yuuji@0 446 SASL mechanism names are registered as discussed in Section 7.1.
yuuji@0 447
yuuji@0 448
yuuji@0 449
yuuji@0 450 Melnikov & Zeilenga Standards Track [Page 8]
yuuji@0 451
yuuji@0 452 RFC 4422 SASL June 2006
yuuji@0 453
yuuji@0 454
yuuji@0 455 3.2. Mechanism Negotiation
yuuji@0 456
yuuji@0 457 Mechanism negotiation is protocol specific.
yuuji@0 458
yuuji@0 459 Commonly, a protocol will specify that the server advertises
yuuji@0 460 supported and available mechanisms to the client via some facility
yuuji@0 461 provided by the protocol, and the client will then select the "best"
yuuji@0 462 mechanism from this list that it supports and finds suitable.
yuuji@0 463
yuuji@0 464 Note that the mechanism negotiation is not protected by the
yuuji@0 465 subsequent authentication exchange and hence is subject to downgrade
yuuji@0 466 attacks if not protected by other means.
yuuji@0 467
yuuji@0 468 To detect downgrade attacks, a protocol can allow the client to
yuuji@0 469 discover available mechanisms subsequent to the authentication
yuuji@0 470 exchange and installation of data security layers with at least data
yuuji@0 471 integrity protection. This allows the client to detect changes to
yuuji@0 472 the list of mechanisms supported by the server.
yuuji@0 473
yuuji@0 474 3.3. Request Authentication Exchange
yuuji@0 475
yuuji@0 476 The authentication exchange is initiated by the client by requesting
yuuji@0 477 authentication via a mechanism it specifies. The client sends a
yuuji@0 478 message that contains the name of the mechanism to the server. The
yuuji@0 479 particulars of the message are protocol specific.
yuuji@0 480
yuuji@0 481 Note that the name of the mechanism is not protected by the
yuuji@0 482 mechanism, and hence is subject to alteration by an attacker if not
yuuji@0 483 integrity protected by other means.
yuuji@0 484
yuuji@0 485 Where the mechanism is defined to allow the client to send data
yuuji@0 486 first, and the protocol's request message includes an optional
yuuji@0 487 initial response field, the client may include the response to the
yuuji@0 488 initial challenge in the authentication request message.
yuuji@0 489
yuuji@0 490 3.4. Challenges and Responses
yuuji@0 491
yuuji@0 492 The authentication exchange involves one or more pairs of server-
yuuji@0 493 challenges and client-responses, the particulars of which are
yuuji@0 494 mechanism specific. These challenges and responses are enclosed in
yuuji@0 495 protocol messages, the particulars of which are protocol specific.
yuuji@0 496
yuuji@0 497 Through these challenges and responses, the mechanism may:
yuuji@0 498
yuuji@0 499 - authenticate the client to the server,
yuuji@0 500
yuuji@0 501 - authenticate the server to the client,
yuuji@0 502
yuuji@0 503
yuuji@0 504
yuuji@0 505
yuuji@0 506 Melnikov & Zeilenga Standards Track [Page 9]
yuuji@0 507
yuuji@0 508 RFC 4422 SASL June 2006
yuuji@0 509
yuuji@0 510
yuuji@0 511 - transfer an authorization identity string,
yuuji@0 512
yuuji@0 513 - negotiate a security layer, and
yuuji@0 514
yuuji@0 515 - provide other services.
yuuji@0 516
yuuji@0 517 The negotiation of the security layer may involve negotiation of the
yuuji@0 518 security services to be provided in the layer, how these services
yuuji@0 519 will be provided, and negotiation of a maximum cipher-text buffer
yuuji@0 520 size each side is able to receive in the layer (see Section 3.6).
yuuji@0 521
yuuji@0 522 After receiving an authentication request or any client response, the
yuuji@0 523 server may issue a challenge, abort the exchange, or indicate the
yuuji@0 524 outcome of an exchange. After receiving a challenge, a client
yuuji@0 525 mechanism may issue a response or abort the exchange.
yuuji@0 526
yuuji@0 527 3.4.1. Authorization Identity String
yuuji@0 528
yuuji@0 529 The authorization identity string is a sequence of zero or more
yuuji@0 530 Unicode [Unicode] characters, excluding the NUL (U+0000) character,
yuuji@0 531 representing the identity to act as.
yuuji@0 532
yuuji@0 533 If the authorization identity string is absent, the client is
yuuji@0 534 requesting to act as the identity the server associates with the
yuuji@0 535 client's credentials. An empty string is equivalent to an absent
yuuji@0 536 authorization identity.
yuuji@0 537
yuuji@0 538 A non-empty authorization identity string indicates that the client
yuuji@0 539 wishes to act as the identity represented by the string. In this
yuuji@0 540 case, the form of identity represented by the string, as well as the
yuuji@0 541 precise syntax and semantics of the string, is protocol specific.
yuuji@0 542
yuuji@0 543 While the character encoding schema used to transfer the
yuuji@0 544 authorization identity string in the authentication exchange is
yuuji@0 545 mechanism specific, mechanisms are expected to be capable of carrying
yuuji@0 546 the entire Unicode repertoire (with the exception of the NUL
yuuji@0 547 character).
yuuji@0 548
yuuji@0 549 3.5. Aborting Authentication Exchanges
yuuji@0 550
yuuji@0 551 A client or server may desire to abort an authentication exchange if
yuuji@0 552 it is unwilling or unable to continue (or enter into).
yuuji@0 553
yuuji@0 554 A client may abort the authentication exchange by sending a message,
yuuji@0 555 the particulars of which are protocol specific, to the server,
yuuji@0 556 indicating that the exchange is aborted. The server may be required
yuuji@0 557 by the protocol to return a message in response to the client's abort
yuuji@0 558 message.
yuuji@0 559
yuuji@0 560
yuuji@0 561
yuuji@0 562 Melnikov & Zeilenga Standards Track [Page 10]
yuuji@0 563
yuuji@0 564 RFC 4422 SASL June 2006
yuuji@0 565
yuuji@0 566
yuuji@0 567 Likewise, a server may abort the authentication exchange by sending a
yuuji@0 568 message, the particulars of which are protocol specific, to the
yuuji@0 569 client, indicating that the exchange is aborted.
yuuji@0 570
yuuji@0 571 3.6. Authentication Outcome
yuuji@0 572
yuuji@0 573 At the conclusion of the authentication exchange, the server sends a
yuuji@0 574 message, the particulars of which are protocol specific, to the
yuuji@0 575 client indicating the outcome of the exchange.
yuuji@0 576
yuuji@0 577 The outcome is not successful if
yuuji@0 578
yuuji@0 579 - the authentication exchange failed for any reason,
yuuji@0 580
yuuji@0 581 - the client's credentials could not be verified,
yuuji@0 582
yuuji@0 583 - the server cannot associate an identity with the client's
yuuji@0 584 credentials,
yuuji@0 585
yuuji@0 586 - the client-provided authorization identity string is malformed,
yuuji@0 587
yuuji@0 588 - the identity associated with the client's credentials is not
yuuji@0 589 authorized to act as the requested authorization identity,
yuuji@0 590
yuuji@0 591 - the negotiated security layer (or lack thereof) is not
yuuji@0 592 suitable, or
yuuji@0 593
yuuji@0 594 - the server is not willing to provide service to the client for
yuuji@0 595 any reason.
yuuji@0 596
yuuji@0 597 The protocol may include an optional additional data field in this
yuuji@0 598 outcome message. This field can only include additional data when
yuuji@0 599 the outcome is successful.
yuuji@0 600
yuuji@0 601 If the outcome is successful and a security layer was negotiated,
yuuji@0 602 this layer is then installed. If the outcome is unsuccessful, or a
yuuji@0 603 security layer was not negotiated, any existing security is left in
yuuji@0 604 place.
yuuji@0 605
yuuji@0 606 The outcome message provided by the server can provide a way for the
yuuji@0 607 client to distinguish between errors that are best dealt with by re-
yuuji@0 608 prompting the user for her credentials, errors that are best dealt
yuuji@0 609 with by telling the user to try again later, and errors where the
yuuji@0 610 user must contact a system administrator for resolution (see the SYS
yuuji@0 611 and AUTH POP Response Codes [RFC3206] specification for an example).
yuuji@0 612 This distinction is particularly useful during scheduled server
yuuji@0 613 maintenance periods as it reduces support costs. It is also
yuuji@0 614 important that the server can be configured such that the outcome
yuuji@0 615
yuuji@0 616
yuuji@0 617
yuuji@0 618 Melnikov & Zeilenga Standards Track [Page 11]
yuuji@0 619
yuuji@0 620 RFC 4422 SASL June 2006
yuuji@0 621
yuuji@0 622
yuuji@0 623 message will not distinguish between a valid user with invalid
yuuji@0 624 credentials and an invalid user.
yuuji@0 625
yuuji@0 626 3.7. Security Layers
yuuji@0 627
yuuji@0 628 SASL mechanisms may offer a wide range of services in security
yuuji@0 629 layers. Typical services include data integrity and data
yuuji@0 630 confidentiality. SASL mechanisms that do not provide a security
yuuji@0 631 layer are treated as negotiating no security layer.
yuuji@0 632
yuuji@0 633 If use of a security layer is negotiated in the authentication
yuuji@0 634 protocol exchange, the layer is installed by the server after
yuuji@0 635 indicating the outcome of the authentication exchange and installed
yuuji@0 636 by the client upon receipt of the outcome indication. In both cases,
yuuji@0 637 the layer is installed before transfer of further protocol data. The
yuuji@0 638 precise position upon which the layer takes effect in the protocol
yuuji@0 639 data stream is protocol specific.
yuuji@0 640
yuuji@0 641 Once the security layer is in effect in the protocol data stream, it
yuuji@0 642 remains in effect until either a subsequently negotiated security
yuuji@0 643 layer is installed or the underlying transport connection is closed.
yuuji@0 644
yuuji@0 645 When in effect, the security layer processes protocol data into
yuuji@0 646 buffers of protected data. If at any time the security layer is
yuuji@0 647 unable or unwilling to continue producing buffers protecting protocol
yuuji@0 648 data, the underlying transport connection MUST be closed. If the
yuuji@0 649 security layer is not able to decode a received buffer, the
yuuji@0 650 underlying connection MUST be closed. In both cases, the underlying
yuuji@0 651 transport connection SHOULD be closed gracefully.
yuuji@0 652
yuuji@0 653 Each buffer of protected data is transferred over the underlying
yuuji@0 654 transport connection as a sequence of octets prepended with a four-
yuuji@0 655 octet field in network byte order that represents the length of the
yuuji@0 656 buffer. The length of the protected data buffer MUST be no larger
yuuji@0 657 than the maximum size that the other side expects. Upon the receipt
yuuji@0 658 of a length field whose value is greater than the maximum size, the
yuuji@0 659 receiver SHOULD close the connection, as this might be a sign of an
yuuji@0 660 attack.
yuuji@0 661
yuuji@0 662 The maximum size that each side expects is fixed by the mechanism,
yuuji@0 663 either through negotiation or by its specification.
yuuji@0 664
yuuji@0 665 3.8. Multiple Authentications
yuuji@0 666
yuuji@0 667 Unless explicitly permitted in the protocol (as stated in the
yuuji@0 668 protocol's technical specification), only one successful SASL
yuuji@0 669 authentication exchange may occur in a protocol session. In this
yuuji@0 670
yuuji@0 671
yuuji@0 672
yuuji@0 673
yuuji@0 674 Melnikov & Zeilenga Standards Track [Page 12]
yuuji@0 675
yuuji@0 676 RFC 4422 SASL June 2006
yuuji@0 677
yuuji@0 678
yuuji@0 679 case, once an authentication exchange has successfully completed,
yuuji@0 680 further attempts to initiate an authentication exchange fail.
yuuji@0 681
yuuji@0 682 Where multiple successful SASL authentication exchanges are permitted
yuuji@0 683 in the protocol, then in no case may multiple SASL security layers be
yuuji@0 684 simultaneously in effect. If a security layer is in effect and a
yuuji@0 685 subsequent SASL negotiation selects a second security layer, then the
yuuji@0 686 second security layer replaces the first. If a security layer is in
yuuji@0 687 effect and a subsequent SASL negotiation selects no security layer,
yuuji@0 688 the original security layer remains in effect.
yuuji@0 689
yuuji@0 690 Where multiple successful SASL negotiations are permitted in the
yuuji@0 691 protocol, the effect of a failed SASL authentication exchange upon
yuuji@0 692 the previously established authentication and authorization state is
yuuji@0 693 protocol specific. The protocol's technical specification should be
yuuji@0 694 consulted to determine whether the previous authentication and
yuuji@0 695 authorization state remains in force, or changed to an anonymous
yuuji@0 696 state, or otherwise was affected. Regardless of the protocol-
yuuji@0 697 specific effect upon previously established authentication and
yuuji@0 698 authorization state, the previously negotiated security layer remains
yuuji@0 699 in effect.
yuuji@0 700
yuuji@0 701 4. Protocol Requirements
yuuji@0 702
yuuji@0 703 In order for a protocol to offer SASL services, its specification
yuuji@0 704 MUST supply the following information:
yuuji@0 705
yuuji@0 706 1) A service name, to be selected from registry of "service" elements
yuuji@0 707 for the Generic Security Service Application Program Interface
yuuji@0 708 (GSSAPI) host-based service name form, as described in Section 4.1
yuuji@0 709 of [RFC2743]. Note that this registry is shared by all GSSAPI and
yuuji@0 710 SASL mechanisms.
yuuji@0 711
yuuji@0 712 2) Detail any mechanism negotiation facility that the protocol
yuuji@0 713 provides (see Section 3.2).
yuuji@0 714
yuuji@0 715 A protocol SHOULD specify a facility through which the client may
yuuji@0 716 discover, both before initiation of the SASL exchange and after
yuuji@0 717 installing security layers negotiated by the exchange, the names
yuuji@0 718 of the SASL mechanisms that the server makes available to the
yuuji@0 719 client. The latter is important to allow the client to detect
yuuji@0 720 downgrade attacks. This facility is typically provided through
yuuji@0 721 the protocol's extensions or capabilities discovery facility.
yuuji@0 722
yuuji@0 723 3) Definition of the messages necessary for authentication exchange,
yuuji@0 724 including the following:
yuuji@0 725
yuuji@0 726
yuuji@0 727
yuuji@0 728
yuuji@0 729
yuuji@0 730 Melnikov & Zeilenga Standards Track [Page 13]
yuuji@0 731
yuuji@0 732 RFC 4422 SASL June 2006
yuuji@0 733
yuuji@0 734
yuuji@0 735 a) A message to initiate the authentication exchange (see Section
yuuji@0 736 3.3).
yuuji@0 737
yuuji@0 738 This message MUST contain a field for carrying the name of the
yuuji@0 739 mechanism selected by the client.
yuuji@0 740
yuuji@0 741 This message SHOULD contain an optional field for carrying an
yuuji@0 742 initial response. If the message is defined with this field,
yuuji@0 743 the specification MUST describe how messages with an empty
yuuji@0 744 initial response are distinguished from messages with no
yuuji@0 745 initial response. This field MUST be capable of carrying
yuuji@0 746 arbitrary sequences of octets (including zero-length sequences
yuuji@0 747 and sequences containing zero-valued octets).
yuuji@0 748
yuuji@0 749 b) Messages to transfer server challenges and client responses
yuuji@0 750 (see Section 3.4).
yuuji@0 751
yuuji@0 752 Each of these messages MUST be capable of carrying arbitrary
yuuji@0 753 sequences of octets (including zero-length sequences and
yuuji@0 754 sequences containing zero-valued octets).
yuuji@0 755
yuuji@0 756 c) A message to indicate the outcome of the authentication
yuuji@0 757 exchange (see Section 3.6).
yuuji@0 758
yuuji@0 759 This message SHOULD contain an optional field for carrying
yuuji@0 760 additional data with a successful outcome. If the message is
yuuji@0 761 defined with this field, the specification MUST describe how
yuuji@0 762 messages with an empty additional data are distinguished from
yuuji@0 763 messages with no additional data. This field MUST be capable
yuuji@0 764 of carrying arbitrary sequences of octets (including zero-
yuuji@0 765 length sequences and sequences containing zero-valued octets).
yuuji@0 766
yuuji@0 767 4) Prescribe the syntax and semantics of non-empty authorization
yuuji@0 768 identity strings (see Section 3.4.1).
yuuji@0 769
yuuji@0 770 In order to avoid interoperability problems due to differing
yuuji@0 771 normalizations, the protocol specification MUST detail precisely
yuuji@0 772 how and where (client or server) non-empty authorization identity
yuuji@0 773 strings are prepared, including all normalizations, for comparison
yuuji@0 774 and other applicable functions to ensure proper function.
yuuji@0 775
yuuji@0 776 Specifications are encouraged to prescribe use of existing
yuuji@0 777 authorization identity forms as well as existing string
yuuji@0 778 representations, such as simple user names [RFC4013].
yuuji@0 779
yuuji@0 780 Where the specification does not precisely prescribe how
yuuji@0 781 identities in SASL relate to identities used elsewhere in the
yuuji@0 782 protocol, for instance, in access control policy statements, it
yuuji@0 783
yuuji@0 784
yuuji@0 785
yuuji@0 786 Melnikov & Zeilenga Standards Track [Page 14]
yuuji@0 787
yuuji@0 788 RFC 4422 SASL June 2006
yuuji@0 789
yuuji@0 790
yuuji@0 791 may be appropriate for the protocol to provide a facility by which
yuuji@0 792 the client can discover information (such as the representation of
yuuji@0 793 the identity used in making access control decisions) about
yuuji@0 794 established identities for these uses.
yuuji@0 795
yuuji@0 796 5) Detail any facility the protocol provides that allows the client
yuuji@0 797 and/or server to abort authentication exchange (see Section 3.5).
yuuji@0 798
yuuji@0 799 Protocols that support multiple authentications typically allow a
yuuji@0 800 client to abort an ongoing authentication exchange by initiating a
yuuji@0 801 new authentication exchange. Protocols that do not support
yuuji@0 802 multiple authentications may require the client to close the
yuuji@0 803 connection and start over to abort an ongoing authentication
yuuji@0 804 exchange.
yuuji@0 805
yuuji@0 806 Protocols typically allow the server to abort ongoing
yuuji@0 807 authentication exchanges by returning a non-successful outcome
yuuji@0 808 message.
yuuji@0 809
yuuji@0 810 6) Identify precisely where newly negotiated security layers start to
yuuji@0 811 take effect, in both directions (see Section 3.7).
yuuji@0 812
yuuji@0 813 Typically, specifications require security layers to start taking
yuuji@0 814 effect on the first octet following the outcome message in data
yuuji@0 815 being sent by the server and on the first octet sent after receipt
yuuji@0 816 of the outcome message in data being sent by the client.
yuuji@0 817
yuuji@0 818 7) If the protocol supports other layered security services, such as
yuuji@0 819 Transport Layer Security (TLS) [RFC4346], the specification MUST
yuuji@0 820 prescribe the order in which security layers are applied to
yuuji@0 821 protocol data.
yuuji@0 822
yuuji@0 823 For instance, where a protocol supports both TLS and SASL security
yuuji@0 824 layers, the specification could prescribe any of the following:
yuuji@0 825
yuuji@0 826 a) SASL security layer is always applied first to data being sent
yuuji@0 827 and, hence, applied last to received data,
yuuji@0 828
yuuji@0 829 b) SASL security layer is always applied last to data being sent
yuuji@0 830 and, hence, applied first to received data,
yuuji@0 831
yuuji@0 832 c) Layers are applied in the order in which they were installed,
yuuji@0 833
yuuji@0 834 d) Layers are applied in the reverse order in which they were
yuuji@0 835 installed, or
yuuji@0 836
yuuji@0 837 e) Both TLS and SASL security layers cannot be installed.
yuuji@0 838
yuuji@0 839
yuuji@0 840
yuuji@0 841
yuuji@0 842 Melnikov & Zeilenga Standards Track [Page 15]
yuuji@0 843
yuuji@0 844 RFC 4422 SASL June 2006
yuuji@0 845
yuuji@0 846
yuuji@0 847 8) Indicate whether the protocol supports multiple authentications
yuuji@0 848 (see Section 3.8). If so, the protocol MUST detail the effect a
yuuji@0 849 failed SASL authentication exchange will have upon a previously
yuuji@0 850 established authentication and authorization state.
yuuji@0 851
yuuji@0 852 Protocol specifications SHOULD avoid stating implementation
yuuji@0 853 requirements that would hinder replacement of applicable mechanisms.
yuuji@0 854 In general, protocol specifications SHOULD be mechanism neutral.
yuuji@0 855 There are a number of reasonable exceptions to this recommendation,
yuuji@0 856 including
yuuji@0 857
yuuji@0 858 - detailing how credentials (which are mechanism specific) are
yuuji@0 859 managed in the protocol,
yuuji@0 860
yuuji@0 861 - detailing how authentication identities (which are mechanism
yuuji@0 862 specific) and authorization identities (which are protocol
yuuji@0 863 specific) relate to each other, and
yuuji@0 864
yuuji@0 865 - detailing which mechanisms are applicable to the protocol.
yuuji@0 866
yuuji@0 867 5. Mechanism Requirements
yuuji@0 868
yuuji@0 869 SASL mechanism specifications MUST supply the following information:
yuuji@0 870
yuuji@0 871 1) The name of the mechanism (see Section 3.1). This name MUST be
yuuji@0 872 registered as discussed in Section 7.1.
yuuji@0 873
yuuji@0 874 2) A definition of the server-challenges and client-responses of the
yuuji@0 875 authentication exchange, as well as the following:
yuuji@0 876
yuuji@0 877 a) An indication of whether the mechanism is client-first,
yuuji@0 878 variable, or server-first. If a SASL mechanism is defined as
yuuji@0 879 client-first and the client does not send an initial response
yuuji@0 880 in the authentication request, then the first server challenge
yuuji@0 881 MUST be empty (the EXTERNAL mechanism is an example of this
yuuji@0 882 case). If a SASL mechanism is defined as variable, then the
yuuji@0 883 specification needs to state how the server behaves when the
yuuji@0 884 initial client response in the authentication request is
yuuji@0 885 omitted (the DIGEST-MD5 mechanism [DIGEST-MD5] is an example of
yuuji@0 886 this case). If a SASL mechanism is defined as server-first,
yuuji@0 887 then the client MUST NOT send an initial client response in the
yuuji@0 888 authentication request (the CRAM-MD5 mechanism [CRAM-MD5] is an
yuuji@0 889 example of this case).
yuuji@0 890
yuuji@0 891 b) An indication of whether the server is expected to provide
yuuji@0 892 additional data when indicating a successful outcome. If so,
yuuji@0 893 if the server sends the additional data as a challenge, the
yuuji@0 894
yuuji@0 895
yuuji@0 896
yuuji@0 897
yuuji@0 898 Melnikov & Zeilenga Standards Track [Page 16]
yuuji@0 899
yuuji@0 900 RFC 4422 SASL June 2006
yuuji@0 901
yuuji@0 902
yuuji@0 903 specification MUST indicate that the response to this challenge
yuuji@0 904 is an empty response.
yuuji@0 905
yuuji@0 906 SASL mechanisms SHOULD be designed to minimize the number of
yuuji@0 907 challenges and responses necessary to complete the exchange.
yuuji@0 908
yuuji@0 909 3) An indication of whether the mechanism is capable of transferring
yuuji@0 910 authorization identity strings (see Section 3.4.1). While some
yuuji@0 911 legacy mechanisms are incapable of transmitting an authorization
yuuji@0 912 identity (which means that for these mechanisms, the authorization
yuuji@0 913 identity is always the empty string), newly defined mechanisms
yuuji@0 914 SHOULD be capable of transferring authorization identity strings.
yuuji@0 915 The mechanism SHOULD NOT be capable of transferring both no
yuuji@0 916 authorization identity string and an empty authorization identity.
yuuji@0 917
yuuji@0 918 Mechanisms that are capable of transferring an authorization
yuuji@0 919 identity string MUST be capable of transferring arbitrary non-
yuuji@0 920 empty sequences of Unicode characters, excluding those that
yuuji@0 921 contain the NUL (U+0000) character. Mechanisms SHOULD use the
yuuji@0 922 UTF-8 [RFC3629] transformation format. The specification MUST
yuuji@0 923 detail how any Unicode code points special to the mechanism that
yuuji@0 924 might appear in the authorization identity string are escaped to
yuuji@0 925 avoid ambiguity during decoding of the authorization identity
yuuji@0 926 string. Typically, mechanisms that have special characters
yuuji@0 927 require these special characters to be escaped or encoded in the
yuuji@0 928 character string (after encoding it in a particular Unicode
yuuji@0 929 transformation format) using a data encoding scheme such as Base64
yuuji@0 930 [RFC3548].
yuuji@0 931
yuuji@0 932 4) The specification MUST detail whether the mechanism offers a
yuuji@0 933 security layer. If the mechanism does, the specification MUST
yuuji@0 934 detail the security and other services offered in the layer as
yuuji@0 935 well as how these services are to be implemented.
yuuji@0 936
yuuji@0 937 5) If the underlying cryptographic technology used by a mechanism
yuuji@0 938 supports data integrity, then the mechanism specification MUST
yuuji@0 939 integrity protect the transmission of an authorization identity
yuuji@0 940 and the negotiation of the security layer.
yuuji@0 941
yuuji@0 942 SASL mechanisms SHOULD be protocol neutral.
yuuji@0 943
yuuji@0 944 SASL mechanisms SHOULD reuse existing credential and identity forms,
yuuji@0 945 as well as associated syntaxes and semantics.
yuuji@0 946
yuuji@0 947 SASL mechanisms SHOULD use the UTF-8 transformation format [RFC3629]
yuuji@0 948 for encoding Unicode [Unicode] code points for transfer.
yuuji@0 949
yuuji@0 950
yuuji@0 951
yuuji@0 952
yuuji@0 953
yuuji@0 954 Melnikov & Zeilenga Standards Track [Page 17]
yuuji@0 955
yuuji@0 956 RFC 4422 SASL June 2006
yuuji@0 957
yuuji@0 958
yuuji@0 959 In order to avoid interoperability problems due to differing
yuuji@0 960 normalizations, when a mechanism calls for character data (other than
yuuji@0 961 the authorization identity string) to be used as input to a
yuuji@0 962 cryptographic and/or comparison function, the specification MUST
yuuji@0 963 detail precisely how and where (client or server) the character data
yuuji@0 964 is to be prepared, including all normalizations, for input into the
yuuji@0 965 function to ensure proper operation.
yuuji@0 966
yuuji@0 967 For simple user names and/or passwords in authentication credentials,
yuuji@0 968 SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation
yuuji@0 969 algorithm), SHOULD be specified as the preparation algorithm.
yuuji@0 970
yuuji@0 971 The mechanism SHOULD NOT use the authorization identity string in
yuuji@0 972 generation of any long-term cryptographic keys or hashes as there is
yuuji@0 973 no requirement that the authorization identity string be canonical.
yuuji@0 974 Long-term, here, means a term longer than the duration of the
yuuji@0 975 authentication exchange in which they were generated. That is, as
yuuji@0 976 different clients (of the same or different protocol) may provide
yuuji@0 977 different authorization identity strings that are semantically
yuuji@0 978 equivalent, use of authorization identity strings in generation of
yuuji@0 979 cryptographic keys and hashes will likely lead to interoperability
yuuji@0 980 and other problems.
yuuji@0 981
yuuji@0 982 6. Security Considerations
yuuji@0 983
yuuji@0 984 Security issues are discussed throughout this memo.
yuuji@0 985
yuuji@0 986 Many existing SASL mechanisms do not provide adequate protection
yuuji@0 987 against passive attacks, let alone active attacks, in the
yuuji@0 988 authentication exchange. Many existing SASL mechanisms do not offer
yuuji@0 989 security layers. It is hoped that future SASL mechanisms will
yuuji@0 990 provide strong protection against passive and active attacks in the
yuuji@0 991 authentication exchange, as well as security layers with strong basic
yuuji@0 992 data security features (e.g., data integrity and data
yuuji@0 993 confidentiality) services. It is also hoped that future mechanisms
yuuji@0 994 will provide more advanced data security services like re-keying (see
yuuji@0 995 Section 6.3).
yuuji@0 996
yuuji@0 997 Regardless, the SASL framework is susceptible to downgrade attacks.
yuuji@0 998 Section 6.1.2 offers a variety of approaches for preventing or
yuuji@0 999 detecting these attacks. In some cases, it is appropriate to use
yuuji@0 1000 data integrity protective services external to SASL (e.g., TLS) to
yuuji@0 1001 protect against downgrade attacks in SASL. Use of external
yuuji@0 1002 protective security services is also important when the mechanisms
yuuji@0 1003 available do not themselves offer adequate integrity and/or
yuuji@0 1004 confidentiality protection of the authentication exchange and/or
yuuji@0 1005 protocol data.
yuuji@0 1006
yuuji@0 1007
yuuji@0 1008
yuuji@0 1009
yuuji@0 1010 Melnikov & Zeilenga Standards Track [Page 18]
yuuji@0 1011
yuuji@0 1012 RFC 4422 SASL June 2006
yuuji@0 1013
yuuji@0 1014
yuuji@0 1015 6.1. Active Attacks
yuuji@0 1016
yuuji@0 1017 6.1.1. Hijack Attacks
yuuji@0 1018
yuuji@0 1019 When the client selects a SASL security layer with at least integrity
yuuji@0 1020 protection, this protection serves as a counter-measure against an
yuuji@0 1021 active attacker hijacking the connection and modifying protocol data
yuuji@0 1022 sent after establishment of the security layer. Implementations
yuuji@0 1023 SHOULD close the connection when the security services in a SASL
yuuji@0 1024 security layer report protocol data report lack of data integrity.
yuuji@0 1025
yuuji@0 1026 6.1.2. Downgrade Attacks
yuuji@0 1027
yuuji@0 1028 It is important that any security-sensitive protocol negotiations be
yuuji@0 1029 performed after installation of a security layer with data integrity
yuuji@0 1030 protection. Protocols should be designed such that negotiations
yuuji@0 1031 performed prior to this installation should be revalidated after
yuuji@0 1032 installation is complete. Negotiation of the SASL mechanism is
yuuji@0 1033 security sensitive.
yuuji@0 1034
yuuji@0 1035 When a client negotiates the authentication mechanism with the server
yuuji@0 1036 and/or other security features, it is possible for an active attacker
yuuji@0 1037 to cause a party to use the least secure security services available.
yuuji@0 1038 For instance, an attacker can modify the server-advertised mechanism
yuuji@0 1039 list or can modify the client-advertised security feature list within
yuuji@0 1040 a mechanism response. To protect against this sort of attack,
yuuji@0 1041 implementations SHOULD NOT advertise mechanisms and/or features that
yuuji@0 1042 cannot meet their minimum security requirements, SHOULD NOT enter
yuuji@0 1043 into or continue authentication exchanges that cannot meet their
yuuji@0 1044 minimum security requirements, and SHOULD verify that completed
yuuji@0 1045 authentication exchanges result in security services that meet their
yuuji@0 1046 minimum security requirements. Note that each endpoint needs to
yuuji@0 1047 independently verify that its security requirements are met.
yuuji@0 1048
yuuji@0 1049 In order to detect downgrade attacks to the least (or less) secure
yuuji@0 1050 mechanism supported, the client can discover the SASL mechanisms that
yuuji@0 1051 the server makes available both before the SASL authentication
yuuji@0 1052 exchange and after the negotiated SASL security layer (with at least
yuuji@0 1053 data integrity protection) has been installed through the protocol's
yuuji@0 1054 mechanism discovery facility. If the client finds that the
yuuji@0 1055 integrity-protected list (the list obtained after the security layer
yuuji@0 1056 was installed) contains a stronger mechanism than those in the
yuuji@0 1057 previously obtained list, the client should assume that the
yuuji@0 1058 previously obtained list was modified by an attacker and SHOULD close
yuuji@0 1059 the underlying transport connection.
yuuji@0 1060
yuuji@0 1061 The client's initiation of the SASL exchange, including the selection
yuuji@0 1062 of a SASL mechanism, is done in the clear and may be modified by an
yuuji@0 1063
yuuji@0 1064
yuuji@0 1065
yuuji@0 1066 Melnikov & Zeilenga Standards Track [Page 19]
yuuji@0 1067
yuuji@0 1068 RFC 4422 SASL June 2006
yuuji@0 1069
yuuji@0 1070
yuuji@0 1071 active attacker. It is important for any new SASL mechanisms to be
yuuji@0 1072 designed such that an active attacker cannot obtain an authentication
yuuji@0 1073 with weaker security properties by modifying the SASL mechanism name
yuuji@0 1074 and/or the challenges and responses.
yuuji@0 1075
yuuji@0 1076 Multi-level negotiation of security features is prone to downgrade
yuuji@0 1077 attack. Protocol designers should avoid offering higher-level
yuuji@0 1078 negotiation of security features in protocols (e.g., above SASL
yuuji@0 1079 mechanism negotiation) and mechanism designers should avoid lower-
yuuji@0 1080 level negotiation of security features in mechanisms (e.g., below
yuuji@0 1081 SASL mechanism negotiation).
yuuji@0 1082
yuuji@0 1083 6.1.3. Replay Attacks
yuuji@0 1084
yuuji@0 1085 Some mechanisms may be subject to replay attacks unless protected by
yuuji@0 1086 external data security services (e.g., TLS).
yuuji@0 1087
yuuji@0 1088 6.1.4. Truncation Attacks
yuuji@0 1089
yuuji@0 1090 Most existing SASL security layers do not themselves offer protection
yuuji@0 1091 against truncation attack. In a truncation attack, the active
yuuji@0 1092 attacker causes the protocol session to be closed, causing a
yuuji@0 1093 truncation of the possibly integrity-protected data stream that leads
yuuji@0 1094 to behavior of one or both the protocol peers that inappropriately
yuuji@0 1095 benefits the attacker. Truncation attacks are fairly easy to defend
yuuji@0 1096 against in connection-oriented application-level protocols. A
yuuji@0 1097 protocol can defend against these attacks by ensuring that each
yuuji@0 1098 information exchange has a clear final result and that each protocol
yuuji@0 1099 session has a graceful closure mechanism, and that these are
yuuji@0 1100 integrity protected.
yuuji@0 1101
yuuji@0 1102 6.1.5. Other Active Attacks
yuuji@0 1103
yuuji@0 1104 When use of a security layer is negotiated by the authentication
yuuji@0 1105 protocol exchange, the receiver SHOULD handle gracefully any
yuuji@0 1106 protected data buffer larger than the defined/negotiated maximal
yuuji@0 1107 size. In particular, it MUST NOT blindly allocate the amount of
yuuji@0 1108 memory specified in the buffer size field, as this might cause the
yuuji@0 1109 "out of memory" condition. If the receiver detects a large block, it
yuuji@0 1110 SHOULD close the connection.
yuuji@0 1111
yuuji@0 1112 6.2. Passive Attacks
yuuji@0 1113
yuuji@0 1114 Many mechanisms are subject to various passive attacks, including
yuuji@0 1115 simple eavesdropping of unprotected credential information as well as
yuuji@0 1116 online and offline dictionary attacks of protected credential
yuuji@0 1117 information.
yuuji@0 1118
yuuji@0 1119
yuuji@0 1120
yuuji@0 1121
yuuji@0 1122 Melnikov & Zeilenga Standards Track [Page 20]
yuuji@0 1123
yuuji@0 1124 RFC 4422 SASL June 2006
yuuji@0 1125
yuuji@0 1126
yuuji@0 1127 6.3. Re-keying
yuuji@0 1128
yuuji@0 1129 The secure or administratively permitted lifetimes of SASL
yuuji@0 1130 mechanisms' security layers are finite. Cryptographic keys weaken as
yuuji@0 1131 they are used and as time passes; the more time and/or cipher-text
yuuji@0 1132 that a cryptanalyst has after the first use of the a key, the easier
yuuji@0 1133 it is for the cryptanalyst to mount attacks on the key.
yuuji@0 1134
yuuji@0 1135 Administrative limits on a security layer's lifetime may take the
yuuji@0 1136 form of time limits expressed in X.509 certificates, in Kerberos V
yuuji@0 1137 tickets, or in directories, and are often desired. In practice, one
yuuji@0 1138 likely effect of administrative lifetime limits is that applications
yuuji@0 1139 may find that security layers stop working in the middle of
yuuji@0 1140 application protocol operation, such as, perhaps, during large data
yuuji@0 1141 transfers. As the result of this, the connection will be closed (see
yuuji@0 1142 Section 3.7), which will result in an unpleasant user experience.
yuuji@0 1143
yuuji@0 1144 Re-keying (key renegotiation process) is a way of addressing the
yuuji@0 1145 weakening of cryptographic keys. The SASL framework does not itself
yuuji@0 1146 provide for re-keying; SASL mechanisms may. Designers of future SASL
yuuji@0 1147 mechanisms should consider providing re-keying services.
yuuji@0 1148
yuuji@0 1149 Implementations that wish to re-key SASL security layers where the
yuuji@0 1150 mechanism does not provide for re-keying SHOULD reauthenticate the
yuuji@0 1151 same IDs and replace the expired or soon-to-expire security layers.
yuuji@0 1152 This approach requires support for reauthentication in the
yuuji@0 1153 application protocols (see Section 3.8).
yuuji@0 1154
yuuji@0 1155 6.4. Other Considerations
yuuji@0 1156
yuuji@0 1157 Protocol designers and implementors should understand the security
yuuji@0 1158 considerations of mechanisms so they may select mechanisms that are
yuuji@0 1159 applicable to their needs.
yuuji@0 1160
yuuji@0 1161 Distributed server implementations need to be careful in how they
yuuji@0 1162 trust other parties. In particular, authentication secrets should
yuuji@0 1163 only be disclosed to other parties that are trusted to manage and use
yuuji@0 1164 those secrets in a manner acceptable to the disclosing party.
yuuji@0 1165 Applications using SASL assume that SASL security layers providing
yuuji@0 1166 data confidentiality are secure even when an attacker chooses the
yuuji@0 1167 text to be protected by the security layer. Similarly, applications
yuuji@0 1168 assume that the SASL security layer is secure even if the attacker
yuuji@0 1169 can manipulate the cipher-text output of the security layer. New
yuuji@0 1170 SASL mechanisms are expected to meet these assumptions.
yuuji@0 1171
yuuji@0 1172
yuuji@0 1173
yuuji@0 1174
yuuji@0 1175
yuuji@0 1176
yuuji@0 1177
yuuji@0 1178 Melnikov & Zeilenga Standards Track [Page 21]
yuuji@0 1179
yuuji@0 1180 RFC 4422 SASL June 2006
yuuji@0 1181
yuuji@0 1182
yuuji@0 1183 Unicode security considerations [UTR36] apply to authorization
yuuji@0 1184 identity strings, as well as UTF-8 [RFC3629] security considerations
yuuji@0 1185 where UTF-8 is used. SASLprep [RFC4013] and StringPrep [RFC3454]
yuuji@0 1186 security considerations also apply where used.
yuuji@0 1187
yuuji@0 1188 7. IANA Considerations
yuuji@0 1189
yuuji@0 1190 7.1. SASL Mechanism Registry
yuuji@0 1191
yuuji@0 1192 The SASL mechanism registry is maintained by IANA. The registry is
yuuji@0 1193 currently available at <http://www.iana.org/assignments/sasl-
yuuji@0 1194 mechanisms>.
yuuji@0 1195
yuuji@0 1196 The purpose of this registry is not only to ensure uniqueness of
yuuji@0 1197 values used to name SASL mechanisms, but also to provide a definitive
yuuji@0 1198 reference to technical specifications detailing each SASL mechanism
yuuji@0 1199 available for use on the Internet.
yuuji@0 1200
yuuji@0 1201 There is no naming convention for SASL mechanisms; any name that
yuuji@0 1202 conforms to the syntax of a SASL mechanism name can be registered.
yuuji@0 1203
yuuji@0 1204 The procedure detailed in Section 7.1.1 is to be used for
yuuji@0 1205 registration of a value naming a specific individual mechanism.
yuuji@0 1206
yuuji@0 1207 The procedure detailed in Section 7.1.2 is to be used for
yuuji@0 1208 registration of a value naming a family of related mechanisms.
yuuji@0 1209
yuuji@0 1210 Comments may be included in the registry as discussed in Section
yuuji@0 1211 7.1.3 and may be changed as discussed in Section 7.1.4.
yuuji@0 1212
yuuji@0 1213 The SASL mechanism registry has been updated to reflect that this
yuuji@0 1214 document provides the definitive technical specification for SASL and
yuuji@0 1215 that this section provides the registration procedures for this
yuuji@0 1216 registry.
yuuji@0 1217
yuuji@0 1218
yuuji@0 1219
yuuji@0 1220
yuuji@0 1221
yuuji@0 1222
yuuji@0 1223
yuuji@0 1224
yuuji@0 1225
yuuji@0 1226
yuuji@0 1227
yuuji@0 1228
yuuji@0 1229
yuuji@0 1230
yuuji@0 1231
yuuji@0 1232
yuuji@0 1233
yuuji@0 1234 Melnikov & Zeilenga Standards Track [Page 22]
yuuji@0 1235
yuuji@0 1236 RFC 4422 SASL June 2006
yuuji@0 1237
yuuji@0 1238
yuuji@0 1239 7.1.1. Mechanism Name Registration Procedure
yuuji@0 1240
yuuji@0 1241 IANA will register new SASL mechanism names on a First Come First
yuuji@0 1242 Served basis, as defined in BCP 26 [RFC2434]. IANA has the right to
yuuji@0 1243 reject obviously bogus registration requests, but will perform no
yuuji@0 1244 review of claims made in the registration form.
yuuji@0 1245
yuuji@0 1246 Registration of a SASL mechanism is requested by filling in the
yuuji@0 1247 following template:
yuuji@0 1248
yuuji@0 1249 Subject: Registration of SASL mechanism X
yuuji@0 1250
yuuji@0 1251 SASL mechanism name (or prefix for the family):
yuuji@0 1252
yuuji@0 1253 Security considerations:
yuuji@0 1254
yuuji@0 1255 Published specification (recommended):
yuuji@0 1256
yuuji@0 1257 Person & email address to contact for further information:
yuuji@0 1258
yuuji@0 1259 Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
yuuji@0 1260
yuuji@0 1261 Owner/Change controller:
yuuji@0 1262
yuuji@0 1263 Note: (Any other information that the author deems relevant may be
yuuji@0 1264 added here.)
yuuji@0 1265
yuuji@0 1266 and sending it via electronic mail to IANA at <iana@iana.org>.
yuuji@0 1267
yuuji@0 1268 While this registration procedure does not require expert review,
yuuji@0 1269 authors of SASL mechanisms are encouraged to seek community review
yuuji@0 1270 and comment whenever that is feasible. Authors may seek community
yuuji@0 1271 review by posting a specification of their proposed mechanism as an
yuuji@0 1272 Internet-Draft. SASL mechanisms intended for widespread use should
yuuji@0 1273 be standardized through the normal IETF process, when appropriate.
yuuji@0 1274
yuuji@0 1275
yuuji@0 1276
yuuji@0 1277
yuuji@0 1278
yuuji@0 1279
yuuji@0 1280
yuuji@0 1281
yuuji@0 1282
yuuji@0 1283
yuuji@0 1284
yuuji@0 1285
yuuji@0 1286
yuuji@0 1287
yuuji@0 1288
yuuji@0 1289
yuuji@0 1290 Melnikov & Zeilenga Standards Track [Page 23]
yuuji@0 1291
yuuji@0 1292 RFC 4422 SASL June 2006
yuuji@0 1293
yuuji@0 1294
yuuji@0 1295 7.1.2. Family Name Registration Procedure
yuuji@0 1296
yuuji@0 1297 As noted above, there is no general naming convention for SASL
yuuji@0 1298 mechanisms. However, specifications may reserve a portion of the
yuuji@0 1299 SASL mechanism namespace for a set of related SASL mechanisms, a
yuuji@0 1300 "family" of SASL mechanisms. Each family of SASL mechanisms is
yuuji@0 1301 identified by a unique prefix, such as X-. Registration of new SASL
yuuji@0 1302 mechanism family names requires expert review as defined in BCP 26
yuuji@0 1303 [RFC2434].
yuuji@0 1304
yuuji@0 1305 Registration of a SASL family name is requested by filling in the
yuuji@0 1306 following template:
yuuji@0 1307
yuuji@0 1308 Subject: Registration of SASL mechanism family X
yuuji@0 1309
yuuji@0 1310 SASL family name (or prefix for the family):
yuuji@0 1311
yuuji@0 1312 Security considerations:
yuuji@0 1313
yuuji@0 1314 Published specification (recommended):
yuuji@0 1315
yuuji@0 1316 Person & email address to contact for further information:
yuuji@0 1317
yuuji@0 1318 Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
yuuji@0 1319
yuuji@0 1320 Owner/Change controller:
yuuji@0 1321
yuuji@0 1322 Note: (Any other information that the author deems relevant may be
yuuji@0 1323 added here.)
yuuji@0 1324
yuuji@0 1325 and sending it via electronic mail to the IETF SASL mailing list at
yuuji@0 1326 <ietf-sasl@imc.org> and carbon copying IANA at <iana@iana.org>.
yuuji@0 1327 After allowing two weeks for community input on the IETF SASL mailing
yuuji@0 1328 list, the expert will determine the appropriateness of the
yuuji@0 1329 registration request and either approve or disapprove the request
yuuji@0 1330 with notice to the requestor, the mailing list, and IANA.
yuuji@0 1331
yuuji@0 1332 The review should focus on the appropriateness of the requested
yuuji@0 1333 family name for the proposed use and the appropriateness of the
yuuji@0 1334 proposed naming and registration plan for existing and future
yuuji@0 1335 mechanism names in the family. The scope of this request review may
yuuji@0 1336 entail consideration of relevant aspects of any provided technical
yuuji@0 1337 specification, such as their IANA Considerations section. However,
yuuji@0 1338 this review is narrowly focused on the appropriateness of the
yuuji@0 1339 requested registration and not on the overall soundness of any
yuuji@0 1340 provided technical specification.
yuuji@0 1341
yuuji@0 1342
yuuji@0 1343
yuuji@0 1344
yuuji@0 1345
yuuji@0 1346 Melnikov & Zeilenga Standards Track [Page 24]
yuuji@0 1347
yuuji@0 1348 RFC 4422 SASL June 2006
yuuji@0 1349
yuuji@0 1350
yuuji@0 1351 Authors are encouraged to pursue community review by posting the
yuuji@0 1352 technical specification as an Internet-Draft and soliciting comment
yuuji@0 1353 by posting to appropriate IETF mailing lists.
yuuji@0 1354
yuuji@0 1355 7.1.3. Comments on SASL Mechanism Registrations
yuuji@0 1356
yuuji@0 1357 Comments on a registered SASL mechanism/family should first be sent
yuuji@0 1358 to the "owner" of the mechanism/family and/or to the <ietf-
yuuji@0 1359 sasl@imc.org> mailing list.
yuuji@0 1360
yuuji@0 1361 Submitters of comments may, after a reasonable attempt to contact the
yuuji@0 1362 owner, request IANA to attach their comment to the SASL mechanism
yuuji@0 1363 registration itself by sending mail to <iana@iana.org>. At IANA's
yuuji@0 1364 sole discretion, IANA may attach the comment to the SASL mechanism's
yuuji@0 1365 registration.
yuuji@0 1366
yuuji@0 1367 7.1.4. Change Control
yuuji@0 1368
yuuji@0 1369 Once a SASL mechanism registration has been published by IANA, the
yuuji@0 1370 author may request a change to its definition. The change request
yuuji@0 1371 follows the same procedure as the registration request.
yuuji@0 1372
yuuji@0 1373 The owner of a SASL mechanism may pass responsibility for the SASL
yuuji@0 1374 mechanism to another person or agency by informing IANA; this can be
yuuji@0 1375 done without discussion or review.
yuuji@0 1376
yuuji@0 1377 The IESG may reassign responsibility for a SASL mechanism. The most
yuuji@0 1378 common case of this will be to enable changes to be made to
yuuji@0 1379 mechanisms where the author of the registration has died, has moved
yuuji@0 1380 out of contact, or is otherwise unable to make changes that are
yuuji@0 1381 important to the community.
yuuji@0 1382
yuuji@0 1383 SASL mechanism registrations may not be deleted; mechanisms that are
yuuji@0 1384 no longer believed appropriate for use can be declared OBSOLETE by a
yuuji@0 1385 change to their "intended usage" field; such SASL mechanisms will be
yuuji@0 1386 clearly marked in the lists published by IANA.
yuuji@0 1387
yuuji@0 1388 The IESG is considered to be the owner of all SASL mechanisms that
yuuji@0 1389 are on the IETF standards track.
yuuji@0 1390
yuuji@0 1391
yuuji@0 1392
yuuji@0 1393
yuuji@0 1394
yuuji@0 1395
yuuji@0 1396
yuuji@0 1397
yuuji@0 1398
yuuji@0 1399
yuuji@0 1400
yuuji@0 1401
yuuji@0 1402 Melnikov & Zeilenga Standards Track [Page 25]
yuuji@0 1403
yuuji@0 1404 RFC 4422 SASL June 2006
yuuji@0 1405
yuuji@0 1406
yuuji@0 1407 7.2. Registration Changes
yuuji@0 1408
yuuji@0 1409 The IANA has updated the SASL mechanisms registry as follows:
yuuji@0 1410
yuuji@0 1411 1) Changed the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
yuuji@0 1412 registrations to OBSOLETE.
yuuji@0 1413
yuuji@0 1414 2) Changed the "Published specification" of the EXTERNAL mechanism to
yuuji@0 1415 this document as indicated below:
yuuji@0 1416
yuuji@0 1417 Subject: Updated Registration of SASL mechanism EXTERNAL
yuuji@0 1418 Family of SASL mechanisms: NO
yuuji@0 1419 SASL mechanism name: EXTERNAL
yuuji@0 1420 Security considerations: See A.3 of RFC 4422
yuuji@0 1421 Published specification (optional, recommended): RFC 4422
yuuji@0 1422 Person & email address to contact for further information:
yuuji@0 1423 Alexey Melnikov <Alexey.Melnikov@isode.com>
yuuji@0 1424 Intended usage: COMMON
yuuji@0 1425 Owner/Change controller: IESG <iesg@ietf.org>
yuuji@0 1426 Note: Updates existing entry for EXTERNAL
yuuji@0 1427
yuuji@0 1428 8. References
yuuji@0 1429
yuuji@0 1430 8.1. Normative References
yuuji@0 1431
yuuji@0 1432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
yuuji@0 1433 Requirement Levels", BCP 14, RFC 2119, March 1997.
yuuji@0 1434
yuuji@0 1435 [RFC2244] Newman, C. and J. G. Myers, "ACAP -- Application
yuuji@0 1436 Configuration Access Protocol", RFC 2244, November
yuuji@0 1437 1997.
yuuji@0 1438
yuuji@0 1439 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
yuuji@0 1440 an IANA Considerations Section in RFCs", BCP 26, RFC
yuuji@0 1441 2434, October 1998.
yuuji@0 1442
yuuji@0 1443 [RFC2743] Linn, J., "Generic Security Service Application Program
yuuji@0 1444 Interface Version 2, Update 1", RFC 2743, January 2000.
yuuji@0 1445
yuuji@0 1446 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
yuuji@0 1447 Internationalized Strings ("stringprep")", RFC 3454,
yuuji@0 1448 December 2002.
yuuji@0 1449
yuuji@0 1450 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
yuuji@0 1451 10646", STD 63, RFC 3629, November 2003.
yuuji@0 1452
yuuji@0 1453 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
yuuji@0 1454 Names and Passwords", RFC 4013, February 2005.
yuuji@0 1455
yuuji@0 1456
yuuji@0 1457
yuuji@0 1458 Melnikov & Zeilenga Standards Track [Page 26]
yuuji@0 1459
yuuji@0 1460 RFC 4422 SASL June 2006
yuuji@0 1461
yuuji@0 1462
yuuji@0 1463 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
yuuji@0 1464 Specifications: ABNF", RFC 4234, October 2005.
yuuji@0 1465
yuuji@0 1466 [ASCII] Coded Character Set--7-bit American Standard Code for
yuuji@0 1467 Information Interchange, ANSI X3.4-1986.
yuuji@0 1468
yuuji@0 1469 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
yuuji@0 1470 3.2.0" is defined by "The Unicode Standard, Version
yuuji@0 1471 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
yuuji@0 1472 61633-5), as amended by the "Unicode Standard Annex
yuuji@0 1473 #27: Unicode 3.1"
yuuji@0 1474 (http://www.unicode.org/reports/tr27/) and by the
yuuji@0 1475 "Unicode Standard Annex #28: Unicode 3.2"
yuuji@0 1476 (http://www.unicode.org/reports/tr28/).
yuuji@0 1477
yuuji@0 1478 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
yuuji@0 1479 #17, Character Encoding Model", UTR17,
yuuji@0 1480 <http://www.unicode.org/unicode/reports/tr17/>, August
yuuji@0 1481 2000.
yuuji@0 1482
yuuji@0 1483 [Glossary] The Unicode Consortium, "Unicode Glossary",
yuuji@0 1484 <http://www.unicode.org/glossary/>.
yuuji@0 1485
yuuji@0 1486 8.2. Informative References
yuuji@0 1487
yuuji@0 1488 [RFC3206] Gellens, R., "The SYS and AUTH POP Response Codes", RFC
yuuji@0 1489 3206, February 2002.
yuuji@0 1490
yuuji@0 1491 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
yuuji@0 1492 Encodings", RFC 3548, July 2003.
yuuji@0 1493
yuuji@0 1494 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
yuuji@0 1495 Internet Protocol", RFC 4301, December 2005.
yuuji@0 1496
yuuji@0 1497 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer
yuuji@0 1498 Security (TLS) Protocol Version 1.1", RFC 4346, April
yuuji@0 1499 2006.
yuuji@0 1500
yuuji@0 1501 [SASL-GSSAPI] Melnikov, A. (Editor), "The Kerberos V5 ("GSSAPI") SASL
yuuji@0 1502 Mechanism", Work in Progress, May 2006.
yuuji@0 1503
yuuji@0 1504 [UTR36] Davis, M., "(Draft) Unicode Technical Report #36,
yuuji@0 1505 Character Encoding Model", UTR17,
yuuji@0 1506 <http://www.unicode.org/unicode/reports/tr36/>,
yuuji@0 1507 February 2005.
yuuji@0 1508
yuuji@0 1509 [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in
yuuji@0 1510 Progress.
yuuji@0 1511
yuuji@0 1512
yuuji@0 1513
yuuji@0 1514 Melnikov & Zeilenga Standards Track [Page 27]
yuuji@0 1515
yuuji@0 1516 RFC 4422 SASL June 2006
yuuji@0 1517
yuuji@0 1518
yuuji@0 1519 [DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest
yuuji@0 1520 Authentication as a SASL Mechanism", Work in Progress,
yuuji@0 1521 March 2006.
yuuji@0 1522
yuuji@0 1523 9. Acknowledgements
yuuji@0 1524
yuuji@0 1525 This document is a revision of RFC 2222 written by John Myers.
yuuji@0 1526
yuuji@0 1527 This revision is a product of the IETF Simple Authentication and
yuuji@0 1528 Security Layer (SASL) Working Group.
yuuji@0 1529
yuuji@0 1530 The following individuals contributed significantly to this revision:
yuuji@0 1531 Abhijit Menon-Sen, Hallvard Furuseth, Jeffrey Hutzelman, John Myers,
yuuji@0 1532 Luke Howard, Magnus Nystrom, Nicolas Williams, Peter Saint-Andre, RL
yuuji@0 1533 'Bob' Morgan, Rob Siemborski, Sam Hartman, Simon Josefsson, Tim
yuuji@0 1534 Alsop, and Tony Hansen.
yuuji@0 1535
yuuji@0 1536
yuuji@0 1537
yuuji@0 1538
yuuji@0 1539
yuuji@0 1540
yuuji@0 1541
yuuji@0 1542
yuuji@0 1543
yuuji@0 1544
yuuji@0 1545
yuuji@0 1546
yuuji@0 1547
yuuji@0 1548
yuuji@0 1549
yuuji@0 1550
yuuji@0 1551
yuuji@0 1552
yuuji@0 1553
yuuji@0 1554
yuuji@0 1555
yuuji@0 1556
yuuji@0 1557
yuuji@0 1558
yuuji@0 1559
yuuji@0 1560
yuuji@0 1561
yuuji@0 1562
yuuji@0 1563
yuuji@0 1564
yuuji@0 1565
yuuji@0 1566
yuuji@0 1567
yuuji@0 1568
yuuji@0 1569
yuuji@0 1570 Melnikov & Zeilenga Standards Track [Page 28]
yuuji@0 1571
yuuji@0 1572 RFC 4422 SASL June 2006
yuuji@0 1573
yuuji@0 1574
yuuji@0 1575 Appendix A. The SASL EXTERNAL Mechanism
yuuji@0 1576
yuuji@0 1577 This appendix is normative.
yuuji@0 1578
yuuji@0 1579 The EXTERNAL mechanism allows a client to request the server to use
yuuji@0 1580 credentials established by means external to the mechanism to
yuuji@0 1581 authenticate the client. The external means may be, for instance, IP
yuuji@0 1582 Security [RFC4301] or TLS [RFC4346] services. In absence of some a
yuuji@0 1583 priori agreement between the client and the server, the client cannot
yuuji@0 1584 make any assumption as to what external means the server has used to
yuuji@0 1585 obtain the client's credentials, nor make an assumption as to the
yuuji@0 1586 form of credentials. For example, the client cannot assume that the
yuuji@0 1587 server will use the credentials the client has established via TLS.
yuuji@0 1588
yuuji@0 1589 A.1. EXTERNAL Technical Specification
yuuji@0 1590
yuuji@0 1591 The name of this mechanism is "EXTERNAL".
yuuji@0 1592
yuuji@0 1593 The mechanism does not provide a security layer.
yuuji@0 1594
yuuji@0 1595 The mechanism is capable of transferring an authorization identity
yuuji@0 1596 string. If empty, the client is requesting to act as the identity
yuuji@0 1597 the server has associated with the client's credentials. If non-
yuuji@0 1598 empty, the client is requesting to act as the identity represented by
yuuji@0 1599 the string.
yuuji@0 1600
yuuji@0 1601 The client is expected to send data first in the authentication
yuuji@0 1602 exchange. Where the client does not provide an initial response data
yuuji@0 1603 in its request to initiate the authentication exchange, the server is
yuuji@0 1604 to respond to the request with an empty initial challenge and then
yuuji@0 1605 the client is to provide its initial response.
yuuji@0 1606
yuuji@0 1607 The client sends the initial response containing the UTF-8 [RFC3629]
yuuji@0 1608 encoding of the requested authorization identity string. This
yuuji@0 1609 response is non-empty when the client is requesting to act as the
yuuji@0 1610 identity represented by the (non-empty) string. This response is
yuuji@0 1611 empty when the client is requesting to act as the identity the server
yuuji@0 1612 associated with its authentication credentials.
yuuji@0 1613
yuuji@0 1614 The syntax of the initial response is specified as a value of the
yuuji@0 1615 <extern-initial-resp> production detailed below using the Augmented
yuuji@0 1616 Backus-Naur Form (ABNF) [RFC4234] notation.
yuuji@0 1617
yuuji@0 1618 external-initial-resp = authz-id-string
yuuji@0 1619 authz-id-string = *( UTF8-char-no-nul )
yuuji@0 1620 UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
yuuji@0 1621 UTF8-1-no-nul = %x01-7F
yuuji@0 1622
yuuji@0 1623
yuuji@0 1624
yuuji@0 1625
yuuji@0 1626 Melnikov & Zeilenga Standards Track [Page 29]
yuuji@0 1627
yuuji@0 1628 RFC 4422 SASL June 2006
yuuji@0 1629
yuuji@0 1630
yuuji@0 1631 where the <UTF8-2>, <UTF8-3>, and <UTF8-4> productions are as defined
yuuji@0 1632 in [RFC3629].
yuuji@0 1633
yuuji@0 1634 There are no additional challenges and responses.
yuuji@0 1635
yuuji@0 1636 Hence, the server is to return the outcome of the authentication
yuuji@0 1637 exchange.
yuuji@0 1638
yuuji@0 1639 The exchange fails if
yuuji@0 1640
yuuji@0 1641 - the client has not established its credentials via external means,
yuuji@0 1642
yuuji@0 1643 - the client's credentials are inadequate,
yuuji@0 1644
yuuji@0 1645 - the client provided an empty authorization identity string and the
yuuji@0 1646 server is unwilling or unable to associate an authorization
yuuji@0 1647 identity with the client's credentials,
yuuji@0 1648
yuuji@0 1649 - the client provided a non-empty authorization identity string that
yuuji@0 1650 is invalid per the syntax requirements of the applicable
yuuji@0 1651 application protocol specification,
yuuji@0 1652
yuuji@0 1653 - the client provided a non-empty authorization identity string
yuuji@0 1654 representing an identity that the client is not allowed to act as,
yuuji@0 1655 or
yuuji@0 1656
yuuji@0 1657 - the server is unwilling or unable to provide service to the client
yuuji@0 1658 for any other reason.
yuuji@0 1659
yuuji@0 1660 Otherwise the exchange is successful. When indicating a successful
yuuji@0 1661 outcome, additional data is not provided.
yuuji@0 1662
yuuji@0 1663 A.2. SASL EXTERNAL Examples
yuuji@0 1664
yuuji@0 1665 This section provides examples of EXTERNAL authentication exchanges.
yuuji@0 1666 The examples are intended to help the readers understand the above
yuuji@0 1667 text. The examples are not definitive. The Application
yuuji@0 1668 Configuration Access Protocol (ACAP) [RFC2244] is used in the
yuuji@0 1669 examples.
yuuji@0 1670
yuuji@0 1671 The first example shows use of EXTERNAL with an empty authorization
yuuji@0 1672 identity. In this example, the initial response is not sent in the
yuuji@0 1673 client's request to initiate the authentication exchange.
yuuji@0 1674
yuuji@0 1675 S: * ACAP (SASL "DIGEST-MD5")
yuuji@0 1676 C: a001 STARTTLS
yuuji@0 1677 S: a001 OK "Begin TLS negotiation now"
yuuji@0 1678 <TLS negotiation, further commands are under TLS layer>
yuuji@0 1679
yuuji@0 1680
yuuji@0 1681
yuuji@0 1682 Melnikov & Zeilenga Standards Track [Page 30]
yuuji@0 1683
yuuji@0 1684 RFC 4422 SASL June 2006
yuuji@0 1685
yuuji@0 1686
yuuji@0 1687 S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
yuuji@0 1688 C: a002 AUTHENTICATE "EXTERNAL"
yuuji@0 1689 S: + ""
yuuji@0 1690 C: + ""
yuuji@0 1691 S: a002 OK "Authenticated"
yuuji@0 1692
yuuji@0 1693 The second example shows use of EXTERNAL with an authorization
yuuji@0 1694 identity of "fred@example.com". In this example, the initial
yuuji@0 1695 response is sent with the client's request to initiate the
yuuji@0 1696 authentication exchange. This saves a round-trip.
yuuji@0 1697
yuuji@0 1698 S: * ACAP (SASL "DIGEST-MD5")
yuuji@0 1699 C: a001 STARTTLS
yuuji@0 1700 S: a001 OK "Begin TLS negotiation now"
yuuji@0 1701 <TLS negotiation, further commands are under TLS layer>
yuuji@0 1702 S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
yuuji@0 1703 C: a002 AUTHENTICATE "EXTERNAL" {16+}
yuuji@0 1704 C: fred@example.com
yuuji@0 1705 S: a002 NO "Cannot assume requested authorization identity"
yuuji@0 1706
yuuji@0 1707 A.3. Security Considerations
yuuji@0 1708
yuuji@0 1709 The EXTERNAL mechanism provides no security protection; it is
yuuji@0 1710 vulnerable to spoofing by either client or server, active attack, and
yuuji@0 1711 eavesdropping. It should only be used when adequate security
yuuji@0 1712 services have been established.
yuuji@0 1713
yuuji@0 1714 Appendix B. Changes since RFC 2222
yuuji@0 1715
yuuji@0 1716 This appendix is non-normative.
yuuji@0 1717
yuuji@0 1718 The material in RFC 2222 was significantly rewritten in the
yuuji@0 1719 production of this document.
yuuji@0 1720
yuuji@0 1721 RFC 2222, by not stating that the authorization identity string was a
yuuji@0 1722 string of Unicode characters, let alone character data, implied that
yuuji@0 1723 the authorization identity string was a string of octets.
yuuji@0 1724
yuuji@0 1725 - The authorization identity string is now defined as a string of
yuuji@0 1726 Unicode characters. The NUL (U+0000) character is prohibited.
yuuji@0 1727 While protocol specifications are responsible for defining the
yuuji@0 1728 authorization identity form, as well as the Unicode string syntax
yuuji@0 1729 and related semantics, mechanism specifications are responsible
yuuji@0 1730 for defining how the Unicode string is carried in the
yuuji@0 1731 authentication exchange.
yuuji@0 1732
yuuji@0 1733 - Deleted "If so, when the client does not send data first, the
yuuji@0 1734 initial challenge MUST be specified as being an empty challenge."
yuuji@0 1735
yuuji@0 1736
yuuji@0 1737
yuuji@0 1738 Melnikov & Zeilenga Standards Track [Page 31]
yuuji@0 1739
yuuji@0 1740 RFC 4422 SASL June 2006
yuuji@0 1741
yuuji@0 1742
yuuji@0 1743 The following technical change was made to the EXTERNAL mechanism:
yuuji@0 1744
yuuji@0 1745 - The authorization identity string is to be UTF-8 encoded.
yuuji@0 1746
yuuji@0 1747 Note that protocol and mechanism specification requirements have
yuuji@0 1748 been significantly tightened. Existing protocol and mechanism
yuuji@0 1749 specifications will need to be updated to meet these requirements.
yuuji@0 1750
yuuji@0 1751 Editors' Addresses
yuuji@0 1752
yuuji@0 1753 Alexey Melnikov
yuuji@0 1754 Isode Limited
yuuji@0 1755 5 Castle Business Village
yuuji@0 1756 36 Station Road
yuuji@0 1757 Hampton, Middlesex,
yuuji@0 1758 TW12 2BX, United Kingdom
yuuji@0 1759
yuuji@0 1760 EMail: Alexey.Melnikov@isode.com
yuuji@0 1761 URI: http://www.melnikov.ca/
yuuji@0 1762
yuuji@0 1763
yuuji@0 1764 Kurt D. Zeilenga
yuuji@0 1765 OpenLDAP Foundation
yuuji@0 1766
yuuji@0 1767 EMail: Kurt@OpenLDAP.org
yuuji@0 1768
yuuji@0 1769
yuuji@0 1770
yuuji@0 1771
yuuji@0 1772
yuuji@0 1773
yuuji@0 1774
yuuji@0 1775
yuuji@0 1776
yuuji@0 1777
yuuji@0 1778
yuuji@0 1779
yuuji@0 1780
yuuji@0 1781
yuuji@0 1782
yuuji@0 1783
yuuji@0 1784
yuuji@0 1785
yuuji@0 1786
yuuji@0 1787
yuuji@0 1788
yuuji@0 1789
yuuji@0 1790
yuuji@0 1791
yuuji@0 1792
yuuji@0 1793
yuuji@0 1794 Melnikov & Zeilenga Standards Track [Page 32]
yuuji@0 1795
yuuji@0 1796 RFC 4422 SASL June 2006
yuuji@0 1797
yuuji@0 1798
yuuji@0 1799 Full Copyright Statement
yuuji@0 1800
yuuji@0 1801 Copyright (C) The Internet Society (2006).
yuuji@0 1802
yuuji@0 1803 This document is subject to the rights, licenses and restrictions
yuuji@0 1804 contained in BCP 78, and except as set forth therein, the authors
yuuji@0 1805 retain all their rights.
yuuji@0 1806
yuuji@0 1807 This document and the information contained herein are provided on an
yuuji@0 1808 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
yuuji@0 1809 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
yuuji@0 1810 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
yuuji@0 1811 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
yuuji@0 1812 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
yuuji@0 1813 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
yuuji@0 1814
yuuji@0 1815 Intellectual Property
yuuji@0 1816
yuuji@0 1817 The IETF takes no position regarding the validity or scope of any
yuuji@0 1818 Intellectual Property Rights or other rights that might be claimed to
yuuji@0 1819 pertain to the implementation or use of the technology described in
yuuji@0 1820 this document or the extent to which any license under such rights
yuuji@0 1821 might or might not be available; nor does it represent that it has
yuuji@0 1822 made any independent effort to identify any such rights. Information
yuuji@0 1823 on the procedures with respect to rights in RFC documents can be
yuuji@0 1824 found in BCP 78 and BCP 79.
yuuji@0 1825
yuuji@0 1826 Copies of IPR disclosures made to the IETF Secretariat and any
yuuji@0 1827 assurances of licenses to be made available, or the result of an
yuuji@0 1828 attempt made to obtain a general license or permission for the use of
yuuji@0 1829 such proprietary rights by implementers or users of this
yuuji@0 1830 specification can be obtained from the IETF on-line IPR repository at
yuuji@0 1831 http://www.ietf.org/ipr.
yuuji@0 1832
yuuji@0 1833 The IETF invites any interested party to bring to its attention any
yuuji@0 1834 copyrights, patents or patent applications, or other proprietary
yuuji@0 1835 rights that may cover technology that may be required to implement
yuuji@0 1836 this standard. Please address the information to the IETF at
yuuji@0 1837 ietf-ipr@ietf.org.
yuuji@0 1838
yuuji@0 1839 Acknowledgement
yuuji@0 1840
yuuji@0 1841 Funding for the RFC Editor function is provided by the IETF
yuuji@0 1842 Administrative Support Activity (IASA).
yuuji@0 1843
yuuji@0 1844
yuuji@0 1845
yuuji@0 1846
yuuji@0 1847
yuuji@0 1848
yuuji@0 1849
yuuji@0 1850 Melnikov & Zeilenga Standards Track [Page 33]
yuuji@0 1851

UW-IMAP'd extensions by yuuji