idnits 2.17.1 draft-myers-auth-sasl-06.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 62 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 151: '... The command SHOULD have an option...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1996) is 10023 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1730 (ref. 'IMAP4') (Obsoleted by RFC 2060, RFC 2061) -- No information found for draft-ietf-cat-gssv2-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'GSSAPI' ** Obsolete normative reference: RFC 1543 (Obsoleted by RFC 2223) ** Downref: Normative reference to an Informational RFC: RFC 1760 (ref. 'SKEY') Summary: 15 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Myers 3 Internet Draft Carnegie Mellon 4 Document: draft-myers-auth-sasl-06.txt November 1996 6 Simple Authentication and Security Layer 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a 19 ``working draft'' or ``work in progress``. 21 To learn the current status of any Internet-Draft, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 24 munnari.oz.au. 26 A revised version of this draft document will be submitted to the RFC 27 editor as a Proposed Standard for the Internet Community. Discussion 28 and suggestions for improvement are requested. This document will 29 expire before December 1996. Distribution of this draft is 30 unlimited. 32 Internet DRAFT SASL November 15, 1996 34 1. Abstract 36 This document describes a method for adding authentication support to 37 connection-based protocols. To use this specification, a protocol 38 includes a command for identifying and authenticating a user to a 39 server and for optionally negotiating protection of subsequent 40 protocol interactions. If its use is negotiated, a security layer is 41 inserted between the protocol and the connection. This document 42 describes how a protocol specifies such a command, defines several 43 mechanisms for use by the command, and defines the protocol used for 44 carrying a negotiated security layer over the connection. 46 2. Organization of this Document 48 2.1. How to Read This Document 50 This document is written to serve two different audiences, protocol 51 designers using this specification to support authentication in their 52 protocol, and implementors of clients or servers for those protocols 53 using this specification. 55 The sections "Introduction and Overview", "Profiling requirements", 56 and "Security Considerations" cover issues that protocol designers 57 need to understand and address in profiling this specification for 58 use in a specific protocol. 60 Implementors of a protocol using this specification need the 61 protocol-specific profiling information in addition to the 62 information in this document. 64 2.2. Conventions Used in this Document 66 In examples, "C:" and "S:" indicate lines sent by the client and 67 server respectively. 69 2.3. Examples 71 Examples in this document are for the IMAP profile [IMAP4] of this 72 specification. The base64 encoding of challenges and responses, as 73 well as the "+ " preceeding the responses are part of the IMAP4 74 profile, not part of the SASL specification itself. 76 3. Introduction and Overview 78 The Simple Authentication and Security Layer (SASL) is a method for 79 adding authentication support to connection-based protocols. To use 80 this specification, a protocol includes a command for identifying and 81 authenticating a user to a server and for optionally negotiating a 83 Internet DRAFT SASL November 15, 1996 85 security layer for subsequent protocol interactions. 87 The command has a single argument, identifying a SASL mechanism. 88 SASL mechanisms are named by strings, from 1 to 20 characters in 89 length, consisting of upper-case letters, digits, hyphens, and/or 90 underscores. SASL mechanism names must be registered with the IANA. 91 Procedures for registering new SASL mechanisms are given in the 92 section "Registration procedures" 94 If a server supports the requested mechanism, it initiates an 95 authentication protocol exchange. This consists of a series of 96 server challenges and client responses that are specific to the 97 requested mechanism. The challenges and responses are defined by the 98 mechanisms as binary tokens of arbitrary length. The protocol's 99 profile then specifies how these binary tokens are then encoded for 100 transfer over the connection. 102 After receiving the authentication command or any client response, a 103 server may issue a challenge, indicate failure, or indicate 104 completion. The protocol's profile specifies how the server 105 indicates which of the above it is doing. 107 After receiving a challenge, a client may issue a response or abort 108 the exchange. The protocol's profile specifies how the client 109 indicates which of the above it is doing. 111 During the authentication protocol exchange, the mechanism performs 112 authentication, transmits an authorization identity (frequently known 113 as a userid) from the client to server, and negotiates the use of a 114 mechanism-specific security layer. If the use of a security layer is 115 agreed upon, then the mechanism must also define or negotiate the 116 maximum cipher-text buffer size that each side is able to receive. 118 The transmitted authorization identity may be different than the 119 identity in the client's authetication credentials. This permits 120 agents such as proxy servers to authenticate using their own 121 credentials, yet request the access privileges of the identity for 122 which they are proxying. 124 If use of a security layer is negotiated, it is applied to all 125 subsequent data sent over the connection. The security layer takes 126 effect immediately following the last response of the authentication 127 exchange for data sent by the client and the completion indication 128 for data sent by the server. Once the security layer is in effect, 129 the protocol stream is processed by the security layer into buffers 130 of cipher-text. Each buffer is transferred over the connection as a 131 stream of octets prepended with a four octet field in network byte 132 order that represents the length of the following buffer. The length 134 Internet DRAFT SASL November 15, 1996 136 of the cipher-text buffer must be no larger than the maximum size 137 that was defined or negotiated by the other side. 139 4. Profiling requirements 141 In order to use this specification, a protocol definition must supply 142 the following information: 144 1. A service name, to be selected from the IANA registry of "service" 145 elements for the GSSAPI host-based service name form. [GSSAPI] 147 2. A definition of the command to initiate the authentication 148 protocol exchange. This command must have as a parameter the 149 mechanism name being selected by the client. 151 The command SHOULD have an optional parameter giving an initial 152 response. When this initial response is sent by the client and 153 the mechanism is defined to send no data in the initial challenge, 154 the empty challenge is not sent to the client and the server uses 155 the data in the initial response parameter as if it were sent in 156 response to the empty challenge. (The server then proceeds to 157 send the second challenge, indicates completion, or indicates 158 failure.) When this intial response is sent by the client and the 159 mechanism is defined to send one or more octets of data in the 160 initial challenge, the command fails. 162 3. A definition of the method by which the authentication protocol 163 exchange is carried out, including how the challenges and 164 responses are encoded, how the server indicates completion or 165 failure of the exchange, how the client aborts an exchange, and 166 how the exchange method interacts with any line length limits in 167 the protocol. 169 4. Identification of the octet where any negotiated security layer 170 starts to take effect, in both directions. 172 5. A specification of how the authorization identity passed from the 173 client to the server is to be interpreted. 175 5. Registration procedures 177 The following documents the procedure for registering new SASL 178 mechanism types. 180 While the registration procedures do not require it, authors of SASL 181 mechanisms are encouraged to seek community review and comment 182 whenever that is feasible. Authors may seek community review by 184 Internet DRAFT SASL November 15, 1996 186 posting a specification of their proposed mechanism as an internet- 187 draft. SASL mechanisms intended for widespread use should be 188 standardized through the normal IETF process, when appropriate. 190 5.1. Comments on SASL mechanism registrations 192 Comments on registered SASL mechanisms should first be sent to the 193 "owner" of the mechanism. Submitters of comments may, after a 194 reasonable attempt to contact the owner, request IANA to attach their 195 comment to the SASL mechanism registration itself. If IANA approves 196 of this the comment will be made accessible in conjunction with the 197 SASL mechanism registration itself. 199 5.2. Location of Registered SASL Mechanism List 201 SASL mechanism registrations will be posted in the anonymous FTP 202 directory "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl- 203 mechanisms/" and all registered SASL mechanisms will be listed in the 204 periodically issued "Assigned Numbers" RFC [currently RFC- 1700]. 205 The SASL mechanism description and other supporting material may also 206 be published as an Informational RFC by sending it to "rfc- 207 editor@isi.edu" (please follow the instructions to RFC authors [RFC- 208 1543]). 210 5.2. Change Control 212 Once a SASL mechanism registration has been published by IANA, the 213 author may request a change to its definition. The change request 214 follows the same procedure as the registration request. 216 The owner of a SASL mechanism may pass responsibility for the SASL 217 mechanism to another person or agency by informing IANA; this can be 218 done without discussion or review. 220 The IESG may reassign responsibility for a SASL mechanism. The most 221 common case of this will be to enable changes to be made to 222 mechanisms where the author of the registration has died, moved out 223 of contact or is otherwise unable to make changes that are important 224 to the community. 226 SASL mechanism registrations may not be deleted; mechanisms which are 227 no longer believed appropriate for use can be declared OBSOLETE by a 228 change to their "intended use" field; such SASL mechanisms will be 229 clearly marked in the lists published by IANA. 231 The IESG is considered to be the owner of all SASL mechanisms which 232 are on the IETF standards track. 234 Internet DRAFT SASL November 15, 1996 236 5.3. Registration Template 238 To: iana@isi.edu 239 Subject: Registration of SASL mechanism XXX 241 SASL mechanism name: 243 Security considerations: 245 Published specification (optional, recommended): 247 Person & email address to contact for further information: 249 Intended usage: 251 (One of COMMON, LIMITED USE or OBSOLETE) 253 Author/Change controller: 255 (Any other information that the author deems interesting may be 256 added below this line.) 258 6. Mechanism definitions 260 The following mechanisms are hereby defined. 262 6.1. Kerberos version 4 mechanism 264 The mechanism name associated with Kerberos version 4 is 265 "KERBEROS_V4". 267 The first challenge consists of a random 32-bit number in network 268 byte order. The client responds with a Kerberos ticket and an 269 authenticator for the principal "service.hostname@realm", where 270 "service" is the service name specified in the protocol's profile, 271 "hostname" is the first component of the host name of the server with 272 all letters in lower case, and where "realm" is the Kerberos realm of 273 the server. The encrypted checksum field included within the 274 Kerberos authenticator contains the server provided challenge in 275 network byte order. 277 Upon decrypting and verifying the ticket and authenticator, the 278 server verifies that the contained checksum field equals the original 279 server provided random 32-bit number. Should the verification be 280 successful, the server must add one to the checksum and construct 8 281 octets of data, with the first four octets containing the incremented 282 checksum in network byte order, the fifth octet containing a bit-mask 284 Internet DRAFT SASL November 15, 1996 286 specifying the security layers supported by the server, and the sixth 287 through eighth octets containing, in network byte order, the maximum 288 cipher-text buffer size the server is able to receive. The server 289 must encrypt using DES ECB mode the 8 octets of data in the session 290 key and issue that encrypted data in a second challenge. The client 291 considers the server authenticated if the first four octets of the 292 un-encrypted data is equal to one plus the checksum it previously 293 sent. 295 The client must construct data with the first four octets containing 296 the original server-issued checksum in network byte order, the fifth 297 octet containing the bit-mask specifying the selected security layer, 298 the sixth through eighth octets containing in network byte order the 299 maximum cipher-text buffer size the client is able to receive, and 300 the following octets containing the authorization identity. The 301 client must then append from one to eight zero-valued octets so that 302 the length of the data is a multiple of eight octets. The client must 303 then encrypt using DES PCBC mode the data with the session key and 304 respond with the encrypted data. The server decrypts the data and 305 verifies the contained checksum. The server must verify that the 306 principal identified in the Kerberos ticket is authorized to connect 307 as that authorization identity. After this verification, the 308 authentication process is complete. 310 The security layers and their corresponding bit-masks are as follows: 312 1 No security layer 313 2 Integrity (krb_mk_safe) protection 314 4 Privacy (krb_mk_priv) protection 315 Other bit-masks may be defined in the future; bits which are not 316 understood must be negotiated off. 318 EXAMPLE: The following are two Kerberos version 4 login scenarios to 319 the IMAP4 protocol (note that the line breaks in the sample 320 authenticators are for editorial clarity and are not in real 321 authenticators) 323 S: * OK IMAP4 Server 324 C: A001 AUTHENTICATE KERBEROS_V4 325 S: + AmFYig== 326 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 327 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 328 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 329 S: + or//EoAADZI= 330 C: DiAF5A4gA+oOIALuBkAAmw== 331 S: A001 OK Kerberos V4 authentication successful 333 Internet DRAFT SASL November 15, 1996 335 S: * OK IMAP4 Server 336 C: A001 AUTHENTICATE KERBEROS_V4 337 S: + gcfgCA== 338 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 339 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 340 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 341 S: A001 NO Kerberos V4 authentication failed 343 Internet DRAFT SASL November 15, 1996 345 6.2. GSSAPI mechanism 347 The mechanism name associated with all mechanisms employing the 348 GSSAPI [GSSAPI] is "GSSAPI". 350 6.2.1 Client side of authentication protocol exchange 352 The first challenge issued by the server contains no data. 354 The client calls GSS_Init_sec_context, passing in 0 for 355 input_context_handle (initially) and a targ_name equal to output_name 356 from GSS_Import_Name called with input_name_type of 357 GSS_C_NT_HOSTBASED_SERVICE and input_name_string of 358 "service@hostname" where "service" is the service name specified in 359 the protocol's profile, and "hostname" is the fully qualified host 360 name of the server. The client then responds with the resulting 361 output_token. If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, 362 then the client should expect the server to issue a token in a 363 subsequent challenge. The client must pass the token to another call 364 to GSS_Init_sec_context, repeating the actions in this paragraph. 366 When GSS_Init_sec_context returns GSS_COMPLETE, the client takes the 367 following actions: If the last call to GSS_Init_sec_context returned 368 an output_token, then the client responds with the output_token, 369 otherwise the client responds with no data. The client should then 370 expect the server to issue a token in a subsequent challenge. The 371 client passes this token to GSS_Unseal and interprets the first octet 372 of resulting cleartext as a bit-mask specifying the security layers 373 supported by the server and the second through fourth octets as the 374 maximum size output_message to send to the server. The client then 375 constructs data, with the first octet containing the bit-mask 376 specifying the selected security layer, the second through fourth 377 octets containing in network byte order the maximum size 378 output_message the client is able to receive, and the remaining 379 octets containing the authorization identity. The client passes the 380 data to GSS_Seal with conf_flag set to FALSE, and responds with the 381 generated output_message. The client can then consider the server 382 authenticated. 384 6.2.2 Server side of authentication protocol exchange 386 The server starts by issuing a challenge with no data. It passes the 387 resulting client response to GSS_Accept_sec_context as input_token, 388 setting acceptor_cred_handle to NULL (for "use default credentials"), 389 and 0 for input_context_handle (initially). If 390 GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server 391 returns the generated output_token to the client in challenge and 392 passes the resulting response to another call to 394 Internet DRAFT SASL November 15, 1996 396 GSS_Accept_sec_context, repeating the actions in this paragraph. 398 When GSS_Accept_sec_context returns GSS_COMPLETE, the client takes 399 the following actions: If the last call to GSS_Accept_sec_context 400 returned an output_token, the server returns it to the client in a 401 challenge and expects a reply from the client with no data. Whether 402 or not an output_token was returned (and after receipt of any respons 403 from the client to such an output_token), the server then constructs 404 4 octets of data, with the first octet containing a bit-mask 405 specifying the security layers supported by the server and the second 406 through fourth octets containing in network byte order the maximum 407 size output_token the server is able to receive. The server must 408 then pass the plaintext to GSS_Seal with conf_flag set to FALSE and 409 issue the generated output_message to the client in a challenge. The 410 server must then pass the resulting response to GSS_Unseal and 411 interpret the first octet of resulting cleartext as the bit-mask for 412 the selected security layer, the second through fourth octets as the 413 maximum size output_message to send to the client, and the remaining 414 octets as the authorization identity. The server must verify that 415 the src_name is authorized to authenticate as the authorization 416 identity. After these verifications, the authentication process is 417 complete. 419 6.2.3 Security layer 421 The security layers and their corresponding bit-masks are as follows: 423 1 No security layer 424 2 Integrity protection. 425 Sender calls GSS_Seal with conf_flag set to FALSE 426 4 Privacy protection. 427 Sender calls GSS_Seal with conf_flag set to TRUE 428 Other bit-masks may be defined in the future; bits which are not 429 understood must be negotiated off. 431 Internet DRAFT SASL November 15, 1996 433 6.3. S/Key mechanism 435 The mechanism name associated with S/Key [SKEY] is "SKEY". 437 The challenge issued by the server contains no data. The client 438 responds with the authorization identity. 440 The data encoded in the second ready response contains the decimal 441 sequence number followed by a single space and the seed string for 442 the indicated authorization identity. The client responds with the 443 one-time-password, as either a 64-bit value in network byte order or 444 encoded in the "six English words" format. 446 The server musth verify the one-time-password. After this 447 verification, the authentication process is complete. 449 S/Key authentication does not provide for any security layers. 451 EXAMPLE: The following are two S/Key login scenarios in the IMAP4 452 protocol. 454 S: * OK IMAP4 Server 455 C: A001 AUTHENTICATE SKEY 456 S: + 457 C: bW9yZ2Fu 458 S: + OTUgUWE1ODMwOA== 459 C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== 460 S: A001 OK S/Key authentication successful 462 S: * OK IMAP4 Server 463 C: A001 AUTHENTICATE SKEY 464 S: + 465 C: c21pdGg= 466 S: + OTUgUWE1ODMwOA== 467 C: BsAY3g4gBNo= 468 S: A001 NO S/Key authentication failed 470 The following is an S/Key login scenario in an IMAP4-like protocol 471 which has an optional "initial response" argument to the AUTHENTICATE 472 command. 474 S: * OK IMAP4-Like Server 475 C: A001 AUTHENTICATE SKEY bW9yZ2Fu 476 S: + OTUgUWE1ODMwOA== 477 C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== 478 S: A001 OK S/Key authentication successful 480 Internet DRAFT SASL November 15, 1996 482 7. References 484 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", 485 RFC 1730, University of Washington, December 1994. 487 [GSSAPI] Linn, J., "Generic Security Service Application Program 488 Interface, Version 2", draft-ietf-cat-gssv2-XX, OpenVision 489 Technologies, May 1996 491 [RFC-1543] Postel, J., "Instructions to RFC Authors", RFC 1543, 492 October 1993 494 [SKEY] Haller, Neil M. "The S/Key One-Time Password System", RFC 495 1760, Bellcore, February 1995 497 8. Security Considerations 499 Security issues are discussed throughout this memo. 501 The mechanisms that support integrity protection are designed such 502 that the negotiation of the security layer and authorization identity 503 is integrity protected. When the client selects a security layer 504 with at least integrity protection, this protects against an active 505 attacker hijacking the connection and modifying the authentication 506 exchange to negotiate a plaintext connection. 508 When a server or client supports multiple authentication mechanisms, 509 each of which has a different security strength, it is possible for 510 an active attacker to cause a party to use the least secure mechanism 511 supported. To protect against this sort of attack, a client or 512 server which supports mechanisms of different strengths should have a 513 configurable minimum strength that it will use. It is not sufficent 514 for this minimum strength check to only be on the server, since an 515 active attacker can change which mechanisms the client sees as being 516 supported, causing the client to send authentication credentials for 517 its weakest supported mechanism. 519 The client's selection of an SASL mechanism is done in the clear and 520 may be modified by an active attacker. It is important for any new 521 SASL mechanisms to be designed such that an active attacker cannot 522 obtain an authentication with weaker security properties by modifying 523 the SASL mechanism name and/or the challenges and responses. 525 Any protocol interactions prior to authentication are performed in 526 the clear and may be modified by an active attacker. In the case 527 where a client selects integrity protection, it is important that any 528 security-sensitive protocol negotiations be performed after 529 authentication is complete. Protocols should be designed such that 531 Internet DRAFT SASL November 15, 1996 533 negotiations performed prior to authentication should be either 534 ignored or revalidated once authentication is complete. 536 9. Author's Address 538 John G. Myers 539 Carnegie-Mellon University 540 5000 Forbes Ave. 541 Pittsburgh PA, 15213-3890 543 EMail: jgm+@cmu.edu 545 Internet DRAFT SASL November 15, 1996 547 TTTTaaaabbbblllleeee ooooffff CCCCoooonnnntttteeeennnnttttssss 549 Status of this Memo ............................................... i 550 1. Abstract ..................................................... 2 551 2. Organization of this Document ................................ 2 552 2.1. How to Read This Document .................................... 2 553 2.2. Conventions Used in this Document ............................ 2 554 2.3. Examples ..................................................... 2 555 3. Introduction and Overview .................................... 2 556 4. Profiling requirements ....................................... 4 557 5. Registration procedures ...................................... 4 558 5.1. Comments on SASL mechanism registrations ..................... 5 559 5.2. Location of Registered SASL Mechanism List .................. 5 560 5.2. Change Control .............................................. 5 561 5.3. Registration Template ....................................... 6 562 6. Mechanism definitions ........................................ 6 563 6.1. Kerberos version 4 mechanism ................................. 6 564 6.2. GSSAPI mechanism ............................................. 9 565 6.2.1 Client side of authentication protocol exchange ............. 9 566 6.2.2 Server side of authentication protocol exchange ............. 9 567 6.2.3 Security layer .............................................. 10 568 6.3. S/Key mechanism .............................................. 11 569 7. References ................................................... 12 570 8. Security Considerations ...................................... 12 571 9. Author's Address ............................................. 13