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