1 2 3 4 5 6 7 Network Working Group J. Myers 8 Request for Comments: 2222 Netscape Communications 9 Category: Standards Track October 1997 10 11 12 Simple Authentication and Security Layer (SASL) 13 14 Status of this Memo 15 16 This document specifies an Internet standards track protocol for the 17 Internet community, and requests discussion and suggestions for 18 improvements. Please refer to the current edition of the "Internet 19 Official Protocol Standards" (STD 1) for the standardization state 20 and status of this protocol. Distribution of this memo is unlimited. 21 22 Copyright Notice 23 24 Copyright (C) The Internet Society (1997). All Rights Reserved. 25 26 Table of Contents 27 28 1. Abstract .............................................. 2 29 2. Organization of this Document ......................... 2 30 2.1. How to Read This Document ............................. 2 31 2.2. Conventions Used in this Document ..................... 2 32 2.3. Examples .............................................. 3 33 3. Introduction and Overview ............................. 3 34 4. Profiling requirements ................................ 4 35 5. Specific issues ....................................... 5 36 5.1. Client sends data first ............................... 5 37 5.2. Server returns success with additional data ........... 5 38 5.3. Multiple authentications .............................. 5 39 6. Registration procedures ............................... 6 40 6.1. Comments on SASL mechanism registrations .............. 6 41 6.2. Location of Registered SASL Mechanism List ............ 6 42 6.3. Change Control ........................................ 7 43 6.4. Registration Template ................................. 7 44 7. Mechanism definitions ................................. 8 45 7.1. Kerberos version 4 mechanism .......................... 8 46 7.2. GSSAPI mechanism ...................................... 9 47 7.2.1 Client side of authentication protocol exchange ....... 9 48 7.2.2 Server side of authentication protocol exchange ....... 10 49 7.2.3 Security layer ........................................ 11 50 7.3. S/Key mechanism ....................................... 11 51 7.4. External mechanism .................................... 12 52 8. References ............................................ 13 53 9. Security Considerations ............................... 13 54 10. Author's Address ...................................... 14 55 56 57 58 Myers Standards Track [Page 1] 59 61 RFC 2222 SASL October 1997 62 63 64 Appendix A. Relation of SASL to Transport Security .......... 15 65 Full Copyright Statement .................................... 16 66 67 1. Abstract 68 69 This document describes a method for adding authentication support to 70 connection-based protocols. To use this specification, a protocol 71 includes a command for identifying and authenticating a user to a 72 server and for optionally negotiating protection of subsequent 73 protocol interactions. If its use is negotiated, a security layer is 74 inserted between the protocol and the connection. This document 75 describes how a protocol specifies such a command, defines several 76 mechanisms for use by the command, and defines the protocol used for 77 carrying a negotiated security layer over the connection. 78 79 2. Organization of this Document 80 81 2.1. How to Read This Document 82 83 This document is written to serve two different audiences, protocol 84 designers using this specification to support authentication in their 85 protocol, and implementors of clients or servers for those protocols 86 using this specification. 87 88 The sections "Introduction and Overview", "Profiling requirements", 89 and "Security Considerations" cover issues that protocol designers 90 need to understand and address in profiling this specification for 91 use in a specific protocol. 92 93 Implementors of a protocol using this specification need the 94 protocol-specific profiling information in addition to the 95 information in this document. 96 97 2.2. Conventions Used in this Document 98 99 In examples, "C:" and "S:" indicate lines sent by the client and 100 server respectively. 101 102 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 103 in this document are to be interpreted as defined in "Key words for 104 use in RFCs to Indicate Requirement Levels" [RFC 2119]. 105 106 107 108 109 110 111 112 113 114 115 Myers Standards Track [Page 2] 116 118 RFC 2222 SASL October 1997 119 120 121 2.3. Examples 122 123 Examples in this document are for the IMAP profile [RFC 2060] of this 124 specification. The base64 encoding of challenges and responses, as 125 well as the "+ " preceding the responses are part of the IMAP4 126 profile, not part of the SASL specification itself. 127 128 3. Introduction and Overview 129 130 The Simple Authentication and Security Layer (SASL) is a method for 131 adding authentication support to connection-based protocols. To use 132 this specification, a protocol includes a command for identifying and 133 authenticating a user to a server and for optionally negotiating a 134 security layer for subsequent protocol interactions. 135 136 The command has a required argument identifying a SASL mechanism. 137 SASL mechanisms are named by strings, from 1 to 20 characters in 138 length, consisting of upper-case letters, digits, hyphens, and/or 139 underscores. SASL mechanism names must be registered with the IANA. 140 Procedures for registering new SASL mechanisms are given in the 141 section "Registration procedures" 142 143 If a server supports the requested mechanism, it initiates an 144 authentication protocol exchange. This consists of a series of 145 server challenges and client responses that are specific to the 146 requested mechanism. The challenges and responses are defined by the 147 mechanisms as binary tokens of arbitrary length. The protocol's 148 profile then specifies how these binary tokens are then encoded for 149 transfer over the connection. 150 151 After receiving the authentication command or any client response, a 152 server may issue a challenge, indicate failure, or indicate 153 completion. The protocol's profile specifies how the server 154 indicates which of the above it is doing. 155 156 After receiving a challenge, a client may issue a response or abort 157 the exchange. The protocol's profile specifies how the client 158 indicates which of the above it is doing. 159 160 During the authentication protocol exchange, the mechanism performs 161 authentication, transmits an authorization identity (frequently known 162 as a userid) from the client to server, and negotiates the use of a 163 mechanism-specific security layer. If the use of a security layer is 164 agreed upon, then the mechanism must also define or negotiate the 165 maximum cipher-text buffer size that each side is able to receive. 166 167 168 169 170 171 172 Myers Standards Track [Page 3] 173 175 RFC 2222 SASL October 1997 176 177 178 The transmitted authorization identity may be different than the 179 identity in the client's authentication credentials. This permits 180 agents such as proxy servers to authenticate using their own 181 credentials, yet request the access privileges of the identity for 182 which they are proxying. With any mechanism, transmitting an 183 authorization identity of the empty string directs the server to 184 derive an authorization identity from the client's authentication 185 credentials. 186 187 If use of a security layer is negotiated, it is applied to all 188 subsequent data sent over the connection. The security layer takes 189 effect immediately following the last response of the authentication 190 exchange for data sent by the client and the completion indication 191 for data sent by the server. Once the security layer is in effect, 192 the protocol stream is processed by the security layer into buffers 193 of cipher-text. Each buffer is transferred over the connection as a 194 stream of octets prepended with a four octet field in network byte 195 order that represents the length of the following buffer. The length 196 of the cipher-text buffer must be no larger than the maximum size 197 that was defined or negotiated by the other side. 198 199 4. Profiling requirements 200 201 In order to use this specification, a protocol definition must supply 202 the following information: 203 204 1. A service name, to be selected from the IANA registry of "service" 205 elements for the GSSAPI host-based service name form [RFC 2078]. 206 207 2. A definition of the command to initiate the authentication 208 protocol exchange. This command must have as a parameter the 209 mechanism name being selected by the client. 210 211 The command SHOULD have an optional parameter giving an initial 212 response. This optional parameter allows the client to avoid a 213 round trip when using a mechanism which is defined to have the 214 client send data first. When this initial response is sent by the 215 client and the selected mechanism is defined to have the server 216 start with an initial challenge, the command fails. See section 217 5.1 of this document for further information. 218 219 3. A definition of the method by which the authentication protocol 220 exchange is carried out, including how the challenges and 221 responses are encoded, how the server indicates completion or 222 failure of the exchange, how the client aborts an exchange, and 223 how the exchange method interacts with any line length limits in 224 the protocol. 225 226 227 228 229 Myers Standards Track [Page 4] 230 232 RFC 2222 SASL October 1997 233 234 235 4. Identification of the octet where any negotiated security layer 236 starts to take effect, in both directions. 237 238 5. A specification of how the authorization identity passed from the 239 client to the server is to be interpreted. 240 241 5. Specific issues 242 243 5.1. Client sends data first 244 245 Some mechanisms specify that the first data sent in the 246 authentication protocol exchange is from the client to the server. 247 248 If a protocol's profile permits the command which initiates an 249 authentication protocol exchange to contain an initial client 250 response, this parameter SHOULD be used with such mechanisms. 251 252 If the initial client response parameter is not given, or if a 253 protocol's profile does not permit the command which initiates an 254 authentication protocol exchange to contain an initial client 255 response, then the server issues a challenge with no data. The 256 client's response to this challenge is then used as the initial 257 client response. (The server then proceeds to send the next 258 challenge, indicates completion, or indicates failure.) 259 260 5.2. Server returns success with additional data 261 262 Some mechanisms may specify that server challenge data be sent to the 263 client along with an indication of successful completion of the 264 exchange. This data would, for example, authenticate the server to 265 the client. 266 267 If a protocol's profile does not permit this server challenge to be 268 returned with a success indication, then the server issues the server 269 challenge without an indication of successful completion. The client 270 then responds with no data. After receiving this empty response, the 271 server then indicates successful completion. 272 273 5.3. Multiple authentications 274 275 Unless otherwise stated by the protocol's profile, only one 276 successful SASL negotiation may occur in a protocol session. In this 277 case, once an authentication protocol exchange has successfully 278 completed, further attempts to initiate an authentication protocol 279 exchange fail. 280 281 282 283 284 285 286 Myers Standards Track [Page 5] 287 289 RFC 2222 SASL October 1997 290 291 292 In the case that a profile explicitly permits multiple successful 293 SASL negotiations to occur, then in no case may multiple security 294 layers be simultaneously in effect. If a security layer is in effect 295 and a subsequent SASL negotiation selects no security layer, the 296 original security layer remains in effect. If a security layer is in 297 effect and a subsequent SASL negotiation selects a second security 298 layer, then the second security layer replaces the first. 299 300 6. Registration procedures 301 302 Registration of a SASL mechanism is done by filling in the template 303 in section 6.4 and sending it in to iana (a] isi.edu. IANA has the right 304 to reject obviously bogus registrations, but will perform no review 305 of clams made in the registration form. 306 307 There is no naming convention for SASL mechanisms; any name that 308 conforms to the syntax of a SASL mechanism name can be registered. 309 310 While the registration procedures do not require it, authors of SASL 311 mechanisms are encouraged to seek community review and comment 312 whenever that is feasible. Authors may seek community review by 313 posting a specification of their proposed mechanism as an internet- 314 draft. SASL mechanisms intended for widespread use should be 315 standardized through the normal IETF process, when appropriate. 316 317 6.1. Comments on SASL mechanism registrations 318 319 Comments on registered SASL mechanisms should first be sent to the 320 "owner" of the mechanism. Submitters of comments may, after a 321 reasonable attempt to contact the owner, request IANA to attach their 322 comment to the SASL mechanism registration itself. If IANA approves 323 of this the comment will be made accessible in conjunction with the 324 SASL mechanism registration itself. 325 326 6.2. Location of Registered SASL Mechanism List 327 328 SASL mechanism registrations will be posted in the anonymous FTP 329 directory "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl- 330 mechanisms/" and all registered SASL mechanisms will be listed in the 331 periodically issued "Assigned Numbers" RFC [currently STD 2, RFC 332 1700]. The SASL mechanism description and other supporting material 333 may also be published as an Informational RFC by sending it to "rfc- 334 editor (a] isi.edu" (please follow the instructions to RFC authors [RFC 335 2223]). 336 337 338 339 340 341 342 343 Myers Standards Track [Page 6] 344 346 RFC 2222 SASL October 1997 347 348 349 6.3. Change Control 350 351 Once a SASL mechanism registration has been published by IANA, the 352 author may request a change to its definition. The change request 353 follows the same procedure as the registration request. 354 355 The owner of a SASL mechanism may pass responsibility for the SASL 356 mechanism to another person or agency by informing IANA; this can be 357 done without discussion or review. 358 359 The IESG may reassign responsibility for a SASL mechanism. The most 360 common case of this will be to enable changes to be made to 361 mechanisms where the author of the registration has died, moved out 362 of contact or is otherwise unable to make changes that are important 363 to the community. 364 365 SASL mechanism registrations may not be deleted; mechanisms which are 366 no longer believed appropriate for use can be declared OBSOLETE by a 367 change to their "intended use" field; such SASL mechanisms will be 368 clearly marked in the lists published by IANA. 369 370 The IESG is considered to be the owner of all SASL mechanisms which 371 are on the IETF standards track. 372 373 6.4. Registration Template 374 375 To: iana (a] iana.org 376 Subject: Registration of SASL mechanism X 377 378 SASL mechanism name: 379 380 Security considerations: 381 382 Published specification (optional, recommended): 383 384 Person & email address to contact for further information: 385 386 Intended usage: 387 388 (One of COMMON, LIMITED USE or OBSOLETE) 389 390 Author/Change controller: 391 392 (Any other information that the author deems interesting may be 393 added below this line.) 394 395 396 397 398 399 400 Myers Standards Track [Page 7] 401 403 RFC 2222 SASL October 1997 404 405 406 7. Mechanism definitions 407 408 The following mechanisms are hereby defined. 409 410 7.1. Kerberos version 4 mechanism 411 412 The mechanism name associated with Kerberos version 4 is 413 "KERBEROS_V4". 414 415 The first challenge consists of a random 32-bit number in network 416 byte order. The client responds with a Kerberos ticket and an 417 authenticator for the principal "service.hostname@realm", where 418 "service" is the service name specified in the protocol's profile, 419 "hostname" is the first component of the host name of the server with 420 all letters in lower case, and where "realm" is the Kerberos realm of 421 the server. The encrypted checksum field included within the 422 Kerberos authenticator contains the server provided challenge in 423 network byte order. 424 425 Upon decrypting and verifying the ticket and authenticator, the 426 server verifies that the contained checksum field equals the original 427 server provided random 32-bit number. Should the verification be 428 successful, the server must add one to the checksum and construct 8 429 octets of data, with the first four octets containing the incremented 430 checksum in network byte order, the fifth octet containing a bit-mask 431 specifying the security layers supported by the server, and the sixth 432 through eighth octets containing, in network byte order, the maximum 433 cipher-text buffer size the server is able to receive. The server 434 must encrypt using DES ECB mode the 8 octets of data in the session 435 key and issue that encrypted data in a second challenge. The client 436 considers the server authenticated if the first four octets of the 437 un-encrypted data is equal to one plus the checksum it previously 438 sent. 439 440 The client must construct data with the first four octets containing 441 the original server-issued checksum in network byte order, the fifth 442 octet containing the bit-mask specifying the selected security layer, 443 the sixth through eighth octets containing in network byte order the 444 maximum cipher-text buffer size the client is able to receive, and 445 the following octets containing the authorization identity. The 446 client must then append from one to eight zero-valued octets so that 447 the length of the data is a multiple of eight octets. The client must 448 then encrypt using DES PCBC mode the data with the session key and 449 respond with the encrypted data. The server decrypts the data and 450 verifies the contained checksum. The server must verify that the 451 principal identified in the Kerberos ticket is authorized to connect 452 as that authorization identity. After this verification, the 453 authentication process is complete. 454 455 456 457 Myers Standards Track [Page 8] 458 460 RFC 2222 SASL October 1997 461 462 463 The security layers and their corresponding bit-masks are as follows: 464 465 1 No security layer 466 2 Integrity (krb_mk_safe) protection 467 4 Privacy (krb_mk_priv) protection 468 469 Other bit-masks may be defined in the future; bits which are not 470 understood must be negotiated off. 471 472 EXAMPLE: The following are two Kerberos version 4 login scenarios to 473 the IMAP4 protocol (note that the line breaks in the sample 474 authenticators are for editorial clarity and are not in real 475 authenticators) 476 477 S: * OK IMAP4 Server 478 C: A001 AUTHENTICATE KERBEROS_V4 479 S: + AmFYig== 480 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 481 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 482 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 483 S: + or//EoAADZI= 484 C: DiAF5A4gA+oOIALuBkAAmw== 485 S: A001 OK Kerberos V4 authentication successful 486 487 488 S: * OK IMAP4 Server 489 C: A001 AUTHENTICATE KERBEROS_V4 490 S: + gcfgCA== 491 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 492 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 493 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 494 S: A001 NO Kerberos V4 authentication failed 495 496 7.2. GSSAPI mechanism 497 498 The mechanism name associated with all mechanisms employing the 499 GSSAPI [RFC 2078] is "GSSAPI". 500 501 7.2.1 Client side of authentication protocol exchange 502 503 The client calls GSS_Init_sec_context, passing in 0 for 504 input_context_handle (initially) and a targ_name equal to output_name 505 from GSS_Import_Name called with input_name_type of 506 GSS_C_NT_HOSTBASED_SERVICE and input_name_string of 507 "service@hostname" where "service" is the service name specified in 508 the protocol's profile, and "hostname" is the fully qualified host 509 name of the server. The client then responds with the resulting 510 output_token. If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, 511 512 513 514 Myers Standards Track [Page 9] 515 517 RFC 2222 SASL October 1997 518 519 520 then the client should expect the server to issue a token in a 521 subsequent challenge. The client must pass the token to another call 522 to GSS_Init_sec_context, repeating the actions in this paragraph. 523 524 When GSS_Init_sec_context returns GSS_S_COMPLETE, the client takes 525 the following actions: If the last call to GSS_Init_sec_context 526 returned an output_token, then the client responds with the 527 output_token, otherwise the client responds with no data. The client 528 should then expect the server to issue a token in a subsequent 529 challenge. The client passes this token to GSS_Unwrap and interprets 530 the first octet of resulting cleartext as a bit-mask specifying the 531 security layers supported by the server and the second through fourth 532 octets as the maximum size output_message to send to the server. The 533 client then constructs data, with the first octet containing the 534 bit-mask specifying the selected security layer, the second through 535 fourth octets containing in network byte order the maximum size 536 output_message the client is able to receive, and the remaining 537 octets containing the authorization identity. The client passes the 538 data to GSS_Wrap with conf_flag set to FALSE, and responds with the 539 generated output_message. The client can then consider the server 540 authenticated. 541 542 7.2.2 Server side of authentication protocol exchange 543 544 The server passes the initial client response to 545 GSS_Accept_sec_context as input_token, setting input_context_handle 546 to 0 (initially). If GSS_Accept_sec_context returns 547 GSS_S_CONTINUE_NEEDED, the server returns the generated output_token 548 to the client in challenge and passes the resulting response to 549 another call to GSS_Accept_sec_context, repeating the actions in this 550 paragraph. 551 552 When GSS_Accept_sec_context returns GSS_S_COMPLETE, the client takes 553 the following actions: If the last call to GSS_Accept_sec_context 554 returned an output_token, the server returns it to the client in a 555 challenge and expects a reply from the client with no data. Whether 556 or not an output_token was returned (and after receipt of any 557 response from the client to such an output_token), the server then 558 constructs 4 octets of data, with the first octet containing a bit- 559 mask specifying the security layers supported by the server and the 560 second through fourth octets containing in network byte order the 561 maximum size output_token the server is able to receive. The server 562 must then pass the plaintext to GSS_Wrap with conf_flag set to FALSE 563 and issue the generated output_message to the client in a challenge. 564 The server must then pass the resulting response to GSS_Unwrap and 565 interpret the first octet of resulting cleartext as the bit-mask for 566 the selected security layer, the second through fourth octets as the 567 maximum size output_message to send to the client, and the remaining 568 569 570 571 Myers Standards Track [Page 10] 572 574 RFC 2222 SASL October 1997 575 576 577 octets as the authorization identity. The server must verify that 578 the src_name is authorized to authenticate as the authorization 579 identity. After these verifications, the authentication process is 580 complete. 581 582 7.2.3 Security layer 583 584 The security layers and their corresponding bit-masks are as follows: 585 586 1 No security layer 587 2 Integrity protection. 588 Sender calls GSS_Wrap with conf_flag set to FALSE 589 4 Privacy protection. 590 Sender calls GSS_Wrap with conf_flag set to TRUE 591 592 Other bit-masks may be defined in the future; bits which are not 593 understood must be negotiated off. 594 595 7.3. S/Key mechanism 596 597 The mechanism name associated with S/Key [RFC 1760] using the MD4 598 digest algorithm is "SKEY". 599 600 The client sends an initial response with the authorization identity. 601 602 The server then issues a challenge which contains the decimal 603 sequence number followed by a single space and the seed string for 604 the indicated authorization identity. The client responds with the 605 one-time-password, as either a 64-bit value in network byte order or 606 encoded in the "six English words" format. 607 608 The server must verify the one-time-password. After this 609 verification, the authentication process is complete. 610 611 S/Key authentication does not provide for any security layers. 612 613 EXAMPLE: The following are two S/Key login scenarios in the IMAP4 614 protocol. 615 616 S: * OK IMAP4 Server 617 C: A001 AUTHENTICATE SKEY 618 S: + 619 C: bW9yZ2Fu 620 S: + OTUgUWE1ODMwOA== 621 C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== 622 S: A001 OK S/Key authentication successful 623 624 625 626 627 628 Myers Standards Track [Page 11] 629 631 RFC 2222 SASL October 1997 632 633 634 S: * OK IMAP4 Server 635 C: A001 AUTHENTICATE SKEY 636 S: + 637 C: c21pdGg= 638 S: + OTUgUWE1ODMwOA== 639 C: BsAY3g4gBNo= 640 S: A001 NO S/Key authentication failed 641 642 The following is an S/Key login scenario in an IMAP4-like protocol 643 which has an optional "initial response" argument to the AUTHENTICATE 644 command. 645 646 S: * OK IMAP4-Like Server 647 C: A001 AUTHENTICATE SKEY bW9yZ2Fu 648 S: + OTUgUWE1ODMwOA== 649 C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== 650 S: A001 OK S/Key authentication successful 651 652 7.4. External mechanism 653 654 The mechanism name associated with external authentication is 655 "EXTERNAL". 656 657 The client sends an initial response with the authorization identity. 658 659 The server uses information, external to SASL, to determine whether 660 the client is authorized to authenticate as the authorization 661 identity. If the client is so authorized, the server indicates 662 successful completion of the authentication exchange; otherwise the 663 server indicates failure. 664 665 The system providing this external information may be, for example, 666 IPsec or TLS. 667 668 If the client sends the empty string as the authorization identity 669 (thus requesting the authorization identity be derived from the 670 client's authentication credentials), the authorization identity is 671 to be derived from authentication credentials which exist in the 672 system which is providing the external authentication. 673 674 675 676 677 678 679 680 681 682 683 684 685 Myers Standards Track [Page 12] 686 688 RFC 2222 SASL October 1997 689 690 691 8. References 692 693 [RFC 2060] Crispin, M., "Internet Message Access Protocol - Version 694 4rev1", RFC 2060, December 1996. 695 696 [RFC 2078] Linn, J., "Generic Security Service Application Program 697 Interface, Version 2", RFC 2078, January 1997. 698 699 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 700 Requirement Levels", RFC 2119, March 1997. 701 702 [RFC 2223] Postel, J., and J. Reynolds, "Instructions to RFC 703 Authors", RFC 2223, October 1997. 704 705 [RFC 1760] Haller, N., "The S/Key One-Time Password System", RFC 706 1760, February 1995. 707 708 [RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, 709 RFC 1700, October 1994. 710 711 9. Security Considerations 712 713 Security issues are discussed throughout this memo. 714 715 The mechanisms that support integrity protection are designed such 716 that the negotiation of the security layer and authorization identity 717 is integrity protected. When the client selects a security layer 718 with at least integrity protection, this protects against an active 719 attacker hijacking the connection and modifying the authentication 720 exchange to negotiate a plaintext connection. 721 722 When a server or client supports multiple authentication mechanisms, 723 each of which has a different security strength, it is possible for 724 an active attacker to cause a party to use the least secure mechanism 725 supported. To protect against this sort of attack, a client or 726 server which supports mechanisms of different strengths should have a 727 configurable minimum strength that it will use. It is not sufficient 728 for this minimum strength check to only be on the server, since an 729 active attacker can change which mechanisms the client sees as being 730 supported, causing the client to send authentication credentials for 731 its weakest supported mechanism. 732 733 734 735 736 737 738 739 740 741 742 Myers Standards Track [Page 13] 743 745 RFC 2222 SASL October 1997 746 747 748 The client's selection of a SASL mechanism is done in the clear and 749 may be modified by an active attacker. It is important for any new 750 SASL mechanisms to be designed such that an active attacker cannot 751 obtain an authentication with weaker security properties by modifying 752 the SASL mechanism name and/or the challenges and responses. 753 754 Any protocol interactions prior to authentication are performed in 755 the clear and may be modified by an active attacker. In the case 756 where a client selects integrity protection, it is important that any 757 security-sensitive protocol negotiations be performed after 758 authentication is complete. Protocols should be designed such that 759 negotiations performed prior to authentication should be either 760 ignored or revalidated once authentication is complete. 761 762 10. Author's Address 763 764 John G. Myers 765 Netscape Communications 766 501 E. Middlefield Road 767 Mail Stop MV-029 768 Mountain View, CA 94043-4042 769 770 EMail: jgmyers (a] netscape.com 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 Myers Standards Track [Page 14] 800 802 RFC 2222 SASL October 1997 803 804 805 Appendix A. Relation of SASL to Transport Security 806 807 Questions have been raised about the relationship between SASL and 808 various services (such as IPsec and TLS) which provide a secured 809 connection. 810 811 Two of the key features of SASL are: 812 813 1. The separation of the authorization identity from the identity in 814 the client's credentials. This permits agents such as proxy 815 servers to authenticate using their own credentials, yet request 816 the access privileges of the identity for which they are proxying. 817 818 2. Upon successful completion of an authentication exchange, the 819 server knows the authorization identity the client wishes to use. 820 This allows servers to move to a "user is authenticated" state in 821 the protocol. 822 823 These features are extremely important to some application protocols, 824 yet Transport Security services do not always provide them. To 825 define SASL mechanisms based on these services would be a very messy 826 task, as the framing of these services would be redundant with the 827 framing of SASL and some method of providing these important SASL 828 features would have to be devised. 829 830 Sometimes it is desired to enable within an existing connection the 831 use of a security service which does not fit the SASL model. (TLS is 832 an example of such a service.) This can be done by adding a command, 833 for example "STARTTLS", to the protocol. Such a command is outside 834 the scope of SASL, and should be different from the command which 835 starts a SASL authentication protocol exchange. 836 837 In certain situations, it is reasonable to use SASL underneath one of 838 these Transport Security services. The transport service would 839 secure the connection, either service would authenticate the client, 840 and SASL would negotiate the authorization identity. The SASL 841 negotiation would be what moves the protocol from "unauthenticated" 842 to "authenticated" state. The "EXTERNAL" SASL mechanism is 843 explicitly intended to handle the case where the transport service 844 secures the connection and authenticates the client and SASL 845 negotiates the authorization identity. 846 847 When using SASL underneath a sufficiently strong Transport Security 848 service, a SASL security layer would most likely be redundant. The 849 client and server would thus probably want to negotiate off the use 850 of a SASL security layer. 851 852 853 854 855 856 Myers Standards Track [Page 15] 857 859 RFC 2222 SASL October 1997 860 861 862 Full Copyright Statement 863 864 Copyright (C) The Internet Society (1997). All Rights Reserved. 865 866 This document and translations of it may be copied and furnished to 867 others, and derivative works that comment on or otherwise explain it 868 or assist in its implmentation may be prepared, copied, published 869 andand distributed, in whole or in part, without restriction of any 870 kind, provided that the above copyright notice and this paragraph are 871 included on all such copies and derivative works. However, this 872 document itself may not be modified in any way, such as by removing 873 the copyright notice or references to the Internet Society or other 874 Internet organizations, except as needed for the purpose of 875 developing Internet standards in which case the procedures for 876 copyrights defined in the Internet Standards process must be 877 followed, or as required to translate it into languages other than 878 English. 879 880 The limited permissions granted above are perpetual and will not be 881 revoked by the Internet Society or its successors or assigns. 882 883 This document and the information contained herein is provided on an 884 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 885 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 886 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 887 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 888 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 Myers Standards Track [Page 16] 914 916
Indexes created Sat Feb 28 05:31:39 UTC 2026