idnits 2.17.1 draft-morgan-ident-ext-04.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-23) 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 Introduction section. ** 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. ** The abstract seems to contain references ([RFC-1413], [RFC-2222]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (March 1998) is 9536 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IMAP' is mentioned on line 96, but not defined == Missing Reference: 'SIDECAR' is mentioned on line 576, but not defined == Unused Reference: 'IMAP4' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'Sidecar' is defined on line 619, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'KERB-4' ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2078 (ref. 'GSSAPI') (Obsoleted by RFC 2743) -- Possible downref: Non-RFC (?) normative reference: ref. 'MAC-AUTH' -- Possible downref: Non-RFC (?) normative reference: ref. 'MACLELAND' ** Obsolete normative reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) -- Possible downref: Non-RFC (?) normative reference: ref. 'Sidecar' Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group RL "Bob" Morgan 3 Internet Draft Stanford University 4 draft-morgan-ident-ext-04.txt March 1998 6 S/Ident: Security Extensions for the Ident Protocol 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 in September 1998. Distribution of this draft is unlimited. 31 Table of Contents 33 Status of This Memo 34 1. Abstract 35 2. Motivation and Background 36 3. Terminology 37 3.1. Roles 38 3.2. Requirements 39 4. S/Ident design 40 4.1. Ident extension format 41 4.1.1. Keyword and value syntax 42 4.1.2. Request format 43 4.1.3. Response format 44 4.2. Authentication extension 45 4.2.1. Authentication request 46 4.2.2. Authentication response 47 4.3. S/Ident authenticator 48 4.4. ERROR responses 49 4.4.1 ERROR response types 50 4.4.2 Extended ERROR response keywords and values 51 4.5. Connection management 52 4.6. Mapping to SASL 53 5. Mechanism definitions 54 5.1. Kerberos version 4 mechanism 55 5.1.1. USER-INTERACTION modifier 56 5.2. GSSAPI mechanism 57 5.2.1. USER-INTERACTION modifier 58 6. Compatibility 59 7. Security considerations 60 8. Formal syntax 61 9. Acknowledgements 62 10. References 63 11. Author's Address 65 1. Abstract 67 The Ident protocol [RFC-1413], specifies a method for a host to 68 request from a remote host an assertion of an identifier associated 69 with a TCP connection between the two hosts. This memo specifies 70 extensions to Ident to support strong (i.e., cryptographic) 71 authentication methods. The extensions are based on the Simple 72 Authentication and Security Layer [RFC-2222]. 74 2. Motivation and Background 76 Many application protocols in use today do not offer strong, 77 cryptography-based authentication mechanisms. Even for those that 78 do, particular implementations may not support them. Or, the 79 mechanisms supported by a protocol or its implementations may not 80 match a site's security infrastructure. In these cases, rather than 81 simply living with inadequate authentication, a site can work around 82 the problem by using a modified application server that calls back, 83 out of band of the original application connection, to a separate 84 component on the client system which can provide the required 85 authentication service. 87 The Ident protocol, RFC 1413, provides a method for the target of a 88 TCP connection to send a request to the system from which the 89 connection originated, which responds with an identifier for the 90 owner of the indicated connection. RFC 1413 only defines clear-text 91 exchanges. This proposal specifies the use of strong authentication 92 schemes for Ident exchanges. The resulting protocol is called 93 "S/Ident". 95 RFC 1731 [RFC-1731] specifies an authentication framework and 96 mechanisms for the IMAP protocol [IMAP]. This framework has been 97 generalized into the "Simple Authentication and Security Layer", SASL 98 [RFC-2222]. This proposal adapts that framework to extend the Ident 99 protocol. 101 3. Terminology 103 3.1. Roles 105 In most protocols the initiator of a connection is the "client", and 106 the target of the connection is the "server". In the proposed scheme 107 it is normally a server that would "call back" to the client system 108 to request authentication information. To avoid confusion, this memo 109 calls the system that asks for the authentication information the 110 "requester", and the system that returns this information the 111 "responder". In their roles in the application, these systems are 112 called the "application server" and the "application client." 114 The security principal who is authenticated by the response is 115 referred to as the "user", and the receiver and processor of the 116 authentication response as the "application". The set of S/Ident 117 protocol messages resulting from an initial request is called a 118 "session." 120 3.2. Requirements 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119. 126 4. S/Ident design 128 4.1. Ident extension format 130 The Ident protocol uses messages in US-ASCII text, terminated by the 131 sequence. A request is of the form 133 , 135 for example 137 6191, 23 139 A response is of the form 141 , : : 143 for example 144 6193, 23 : USERID : UNIX : stjohns 145 6195, 23 : ERROR : NO-USER 147 This memo specifies extended formats for requests and responses. 149 4.1.1. Keyword and value syntax 151 Several protocol constructionss defined in this memo use "keyword" 152 and "value" syntax elements. These are defined as: 154 keyword-value ::= keyword | nonstd-keyword "=" value [ "," value ] 156 keyword ::= initial kvchar+ 158 nonstd-keyword ::= "X" kvchar+ 160 initial ::= < A-Z a-z 0-9 > 162 value ::= kvchar+ 164 kvchar ::= < A-Z a-z 0-9 - !@#$%^&*()_+.<>/?~{}[] > 166 That is, a keyword value sequence is a keyword followed by "=" 167 followed by one or more comma-separated values. A standard keyword 168 defined in this or other standards-track memos must begin with an 169 alphanumeric character; non-standard keywords must begin with "X". 170 A value may include any characters from the set above; specifically 171 ",", ":", "=", and ";" are excluded. If a value might need to 172 represent other (e.g., binary) data, it must be specified to be 173 encoded in base64 format, as specified in RFC 2045 [RFC-2045]. 175 4.1.2. Request format 177 This memo extends the RFC 1413 request format to be of the form 179 "," 180 [":" [":" ]* ] 182 that is, a ":", a keyword identifying the extension, and optional 183 req-ext-data fields, each preceded by a ":". The req-ext-data field 184 is in the "value" syntax as defined above. 186 At most one extension is included with a request. 188 4.1.3. Response format 190 RFC 1413 specifies resp-type values of USERID and ERROR, each with 191 its own format: 193 6193, 23 : USERID : : 194 6195, 23 : ERROR : 196 This memo extends the response format to be: 198 ":" ":" 199 [":" ]* [":" ]* 201 where resp-type-info is zero or more fields, as determined by the 202 response type, and each resp-ext-data field is a keyword-value 203 sequence as defined above. 205 4.2. Authentication extension 207 An authentication request extension is defined as 209 AUTHENTICATE [: ]* 211 that is, the token "AUTHENTICATE" followed by zero or more fields 212 specifying authentication request information, separated by ":". 213 Each field identifies an authentication mechanism; several auth-req 214 fields MAY be included to allow the responder a choice of methods. 215 They are in the order of requester's preference; the responder SHOULD 216 use the first one it can to construct a valid response. The 217 requester MUST accept any one of the methods it offers. 219 The auth-req field is of the form 221 , [, ]* 223 where auth-mech is a registered identifier for an authentication 224 mechanism, and auth-req-info is information specific to that 225 authentication mechanism. The auth-req-modifier field is a keyword- 226 value sequence as defined above. The auth-req-modifier fields modify 227 the behavior of the responder in handling a response using this 228 mechanism; the auth-req-info field contains information, if any, 229 intrinsic to the operation of the mechanism. 231 The response format is extended to have a new resp-type of 232 AUTHENTICATE. In this case a response is of the form 234 , : AUTHENTICATE : 236 The auth-resp field is of the form: 238 , 240 where auth-resp-info is specific to the authentication mechanism. 242 If the responder is not able to use any of the authentication 243 mechanisms proposed by the requester in its initial request message, 244 it MAY specify a different mechanism in its response. In this case 245 the field will be empty. 247 The auth-req-info and auth-resp-info fields each might contain any 248 binary data. Accordingly, the data in these fields is encoded in 249 base64 (as specified in RFC 2045 [RFC-2045]) before transmission. 250 Note that there MUST NOT be any line breaks () in the field 251 itself, since a line break terminates the entire record. 253 4.3. S/Ident authenticator 255 A structure, called the "S/Ident authenticator", is sent by the 256 responder as a part of one of its responses. It is protected from 257 modification and disclosure in mechanisms that support such 258 protection. It is defined as: 260 {resp-flags, resp-port, req-port, authid-len, authid, pad} 262 where 264 resp-flags is a two-octet field (in network byte order) where: 266 Bit zero (the LSB), the NMA (no-mutual-auth) bit, if set, 267 indicates that the responder is not interested in the mutual 268 authentication message from the requester, so the requester need 269 not send it. This might be set by a responder with limited 270 resources that wishes to limit the session to a single request- 271 response pair. 273 All other bits of resp-flags MUST be zero when sent and MUST be 274 ignored when received. 276 resp-port and req-port are the TCP port numbers (in binary form, in 277 network byte order) from the request; 279 authid-len is the two-octet length in octets, in network byte 280 order, of the following authid field; 282 authid is the "authorization identity" (as described in [RFC-2222]) 283 asserted by the user; and 285 pad is zero to seven zero-valued octets to bring the total pre- 286 encryption length of this structure to a multiple of eight octets. 288 4.4. ERROR responses 289 New values for the field of ERROR responses are defined as 290 appropriate for each mechanism. Note that messages from the 291 requester to the responder indicate errors also, if appropriate; in 292 this case the error value is put into the auth-req-info field. 294 New generic ERROR response values are defined below. In addition, an 295 extended ERROR response format is defined to allow the responder to 296 return information to the requester that may be useful in a 297 subsequent request. Some standard extension values are defined 298 below. 300 4.4.1 ERROR response values 302 New generic error values include: 304 AUTH-NOT-SUPPORTED 306 Indicates that none of the authentication mechanisms offered by the 307 requester are supported for authentication of the owner of the 308 indicated connection. It MAY also be sent by the requester to 309 indicate that the authentication mechanism specified by the 310 responder is not supported. 312 INVALID-AUTH-REQ-INFO 314 Indicates that one or more of the supplied values in the auth-req- 315 info field are syntactically invalid. 317 INVALID-AUTH-RESP-INFO 319 Indicates that one or more of the supplied values in the auth-resp- 320 info field are syntactically invalid. 322 USER-CANT-AUTH 324 Indicates that the authentication mechanism is supported for the 325 owner of the connection, but that no authentication information is 326 available for that user. 328 AUTH-FAILURE 330 Indicates that an authentication verification operation failed. 332 4.4.2. Extended ERROR response keywords and values 334 This section defines keywords and values for use in the resp-ext-data 335 field of extended ERROR response messages. 337 Keyword: CAPABILITY. Values following the CAPABILITY keyword 338 indicate optional capabilities that are supported by the responder. 339 A responder SHOULD include the CAPABILITY block listing all of its 340 capabilities in each error response. 342 CAPABILITY values defined in this memo include: 344 Value: USER-INTERACTION. This capability indicates that the 345 responder supports the ability to prompt the user on the responding 346 system to supply information to support the S/Ident interaction. 348 Keyword: AUTH-MECH. Values following the AUTH-MECH keyword indicate 349 authentication mechanisms supported by the responder. Each value is 350 the same as the authentication mechanism token defined for that 351 mechanism. For the GSSAPI mechanism, supported sub-mechanisms are 352 separately listed as GSSAPI/. Values defined in this memo 353 are: GSSAPI/KERBEROS_V5, GSSAPI/SPKM, GSSAPI/DCE. A responder 354 SHOULD include the AUTH-MECH block listing all of its supported 355 mechanisms in each error response. 357 4.5. Connection management 359 A RFC-1413 Ident session consists of a single request message and a 360 single response message. An S/Ident session MAY include several 361 requests and responses. A particular S/Ident TCP connection has at 362 most one session in progress; that is, interleaving requests from 363 different sessions is prohibited. An ERROR message from either 364 requester or responder terminates the session. A connection MAY 365 remain open after a session is completed so that other sessions can 366 be conducted on it; or it MAY be closed by either side. 368 4.6. Mapping to SASL 370 When a protocol is extended to use SASL, a protocol message is 371 defined that permits a client to request the use of a particular 372 security mechanism with the server. This is the initial message in 373 the SASL exchange. This message should contain an argument 374 identifying a SASL mechanism. In Ident, the initial message is 375 normally the connection request from the client using the application 376 protocol. Rather than impose an additional round-trip, the server 377 acting as the S/Ident requester offers a set of authentication 378 mechanisms to the client in its initial message. The responder 379 selects one mechanism to use for its response, or responds with an 380 ERROR message, optionally announcing the authentication mechanisms 381 that it supports. 383 5. Mechanism definitions 384 The following sections describe how some SASL-defined security 385 mechanisms are applied to S/Ident. 387 5.1. Kerberos version 4 mechanism 389 The auth-mech token for the Kerberos 4 authentication mechanism 390 [KERB-4] is as specified in RFC 2222 ("KERBEROS_V4"). 392 The auth-req-info for the first request message in this mechanism is 393 the challenge as specified in RFC 2222, a random 32-bit number in 394 network byte order. 396 In response to the first request message, the responder sends a 397 message whose auth-resp-info field consists of the following parts, 398 concatenated together: 400 (1) a two-octet integer in network byte order indicating the length 401 of part (2) in octets; 403 (2) a Kerberos ticket and an authenticator for the service principal 404 "ident.hostname@realm", where "ident" is the service name, "hostname" 405 is the first component of the host name of the server with all 406 letters in lower case, and where "realm" is the Kerberos realm of the 407 server. The client principal is the principal associated with the 408 owner of the connection specified in the request. As specified in 409 RFC 2222, the encrypted checksum field included within the Kerberos 410 authenticator contains the server provided 32-bit challenge in 411 network byte order. 413 (3) a two-octet integer in network byte order indicating the length 414 of part (4) in octets; 416 (4) the S/Ident authenticator, encrypted using DES PCBC mode with the 417 session key from the Kerberos ticket. 419 The requester receives and decrypts the response message. It 420 verifies the Kerberos ticket and authenticator, and the 32-bit 421 challenge value. It uses the session key to decrypt the S/Ident 422 authenticator, and verifies the port values. If all these conditions 423 hold, the requester considers the responder authenticated, and the 424 requester (or the application server that called it) MAY then 425 evaluate the principal and the authorization identity for access 426 control purposes. Independent of this evaluation, the requester 427 proceeds as described below. 429 If the requester determines that there is an error in the response, 430 it sends the appropriate S/Ident error message to the responder and 431 concludes its processing for the session. 433 In the no-error case, if the NMA bit in the resp-flags field of the 434 S/Ident authenticator is set, the requester concludes its processing 435 without sending another message. Otherwise, the requester forms a 436 new message as follows. It adds one to the checksum value and makes 437 this the first four octets of its SASL-specified eight octet response 438 field. Since S/Ident does not use a security layer, a bit is set to 439 indicate this, and the cipher-text buffer size is set to zero. It 440 encrypts the 8 octets using DES ECB mode with the session key, as in 441 SASL, and sends the result as the auth-req-info field in a second 442 request message that is otherwise identical to the first (except that 443 it need not contain auth-req fields for any other mechanisms that 444 might have been included in the initial message). 446 The responder processes the second request message, if any, to verify 447 the checksum and authenticate the requester. It does not generate a 448 second response message. 450 5.1.1. USER-INTERACTION modifier 452 The "USER-INTERACTION" modifier keyword has two possible values: 453 "YES" and "NO". The "NO" value indicates that the responder SHOULD 454 generate a response using whatever credentials are available for the 455 user, but SHOULD NOT (if possible) prompt the user to provide 456 authentication information (this allows the response to be sent more 457 or less immediately). The "YES" value indicates that the responder 458 SHOULD, if credentials are unavailable, prompt the user, if possible, 459 to provide authentication information, blocking its response until 460 the user interaction is complete. 462 The "NO" value is the default. 464 5.2. GSSAPI mechanism 466 The auth-mech token for the all mechanisms using the GSSAPI [GSSAPI] 467 is as specified in RFC 2222 ("GSSAPI"). 469 Protocol interactions occur as specified in RFC 2222. The service 470 name for the requester is "ident". There is no security layer. 472 The "authorization identity" field in the final response message 473 contains the complete S/Ident authenticator. The requester verifies 474 the port values in the authenticator. If they are correct, it makes 475 the authid value and any responder credentials available to the 476 calling application for use in access control evaluation. 478 5.2.1. USER-INTERACTION modifier 480 This is defined identically to the KERBEROS_V4 USER-INTERACTION 481 modifier. 483 6. Compatibility 485 If a RFC 1413 responder receives an extended-format request, it might 486 (1) not respond at all, (2) respond with an an ERROR due to the 487 presence of the extended fields, (3) ignore the extended fields and 488 respond as usual, perhaps with a USERID response. In any case the 489 requester can determine that no valid response was received. The no- 490 response case could be a problem since it would result in a long 491 timeout. 493 An extended responder SHOULD be configurable to either respond to RFC 494 1413 traditional requests in the traditional way, or to give an ERROR 495 response. 497 7. Security considerations 499 This protocol can provide only authentication information. 500 Protection of the integrity or confidentiality of the application 501 data stream can not be provided. 503 Use of this protocol is inferior to the provision of proper security 504 mechanisms within application protocols, and should not be considered 505 as a reason not to develop them. It should only be used as a last 506 resort when the application protocol can not be secured. 508 Since the software (i.e., the responder) handling the authentication 509 interaction is different from the client application that makes the 510 initial connection, it may be difficult for a user to understand that 511 a prompt requesting authentication information (e.g., a password) is 512 related to the original application action. This may require careful 513 user interface design and user education. 515 Setting of the "no-mutual-auth" flag by the responder prevents the 516 responder from being able to check that a request came from an 517 authentic requester. This can increase the responding system's 518 vulnerability to requests from malicious sources, though there is no 519 obvious attack that can be mounted by such a malicious source. 521 If multiple services on a single host employ S/Ident to authenticate 522 their clients, they must necessarily share access to the ident 523 service credentials on that host. This implies that such services 524 are in a single trust domain on that host, and therefore that trusted 525 services (i.e., those operating at a high privilege level) and 526 untrusted services should not both run on the same host if they are 527 using the S/Ident scheme for authentication. 529 Similarly, any login users on a service host that uses S/Ident can 530 relatively easily generate valid request messages to clients of that 531 host. This suggests restricting login access to hosts that use 532 S/Ident to authenticate their clients. 534 Several measures can be used by a responder to limit its 535 vulnerability to potentially abusive requests. Requests can be 536 filtered based on the IP address or the DNS domain of the requester. 537 After a certain delay following the establishment of a TCP 538 connection, the responder can stop responding to requests about that 539 connection. A responder can answer the first request about a 540 connection, and drop any subsequent requests. A responder can 541 display information about the request to the user, and ask for 542 confirmation before responding (though this decision may be difficult 543 for the user to make). On a multi-user system, a responder may be 544 configured with a list of identities (e.g., UNIX "root") for which it 545 always responds with a NO-USER or USER-CANT-AUTH error. 547 Furthermore, note that if the system on which the responder is 548 running is running any TCP-based services, a requester can initiate a 549 request to one of these services and then request authentication on 550 that connection (this includes the S/Ident responder itself!). This 551 potentially allows any host to cause the responder to produce a valid 552 response. If the responder on a single-user system were to treat all 553 connections as belonging to that single user and respond with 554 authentication data for that user, this may be an undesirable 555 exposure. On a multi-user system the response would depend on what 556 identity the servers use; a valid response may also be an exposure in 557 this case. To prevent this abuse, responders can treat requests with 558 a responder-port equal to some configurable list of service ports in 559 a special way, perhaps always responding with a NO-USER error. If 560 the responder can distinguish connections initiated remotely from 561 those initiated locally, it can return an error on requests for 562 authentication of remotely-initiated connections. 564 8. Formal syntax 566 (to be supplied) 568 9. Acknowledgements 570 Stuart Cheshire's Macintosh Authenticator [MAC-AUTH], developed at 571 Stanford, implements a similar approach to a security callback 572 scheme. 574 Andy Hanushevsky of Cornell's Project Mandarin developed a callback 575 authentication scheme called "SideCar" (SideCar is the responder 576 side, FrontCar is the requester side) [SIDECAR]. This proposal 577 borrows the basic callback idea from there. 579 The MacLeland team at Stanford [MACLELAND], including Andy Maas and 580 Jeff Mapes, did an implementation of an earlier version of this 581 protocol. Lynn McRae persisted in promoting the callback concept 582 despite the author's initial resistance. Craig Jurney and Roland 583 Schemers made suggestions leading to the adaptation of Ident and 584 SASL. Booker Bense made substantial contributions in the process of 585 doing the initial implementation. 587 10. References 589 [KERB-4] Steiner, J., Neuman, B., Schiller, J., "Kerberos: An 590 Authentication Service for Open Network Systems", Usenix 591 Conference Proceedings, 1988. 593 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 594 4rev1", RFC 2060, University of Washington, December 1996. 596 [GSSAPI] Linn, J., "Generic Security Service Application Program 597 Interface, Version 2", RFC 2078, January 1997. 599 [MAC-AUTH] Cheshire, S., Crellin, N., "The Cheshire/Crellin 600 Macintosh Print Accounting Package", 601 http://rescomp.stanford.edu/macauth.html. 603 [MACLELAND] Maas, M., "MacLeland Project", http://www- 604 leland.stanford.edu/~maas/macleland/. 606 [RFC-1413] M. St. Johns, "Identification Protocol", RFC 1413, 607 1993. 609 [RFC-2045] Freed, N., Borenstein, N., "Multipurpose Internet Mail 610 Extensions (MIME) Part One: Format of Internet Message Bodies", 611 November 1996. 613 [RFC-1731] J. Myers, "IMAP4 Authentication mechanisms", RFC 1731, 614 1994. 616 [RFC-2222] J. Myers, "Simple Authentication and Security Layer", 617 RFC 2222, October 1997. 619 [Sidecar] http://www.mandarin.org/. 621 11. Author's Address 623 RL "Bob" Morgan 624 Computing and Communication Systems 625 Pine Hall 626 Stanford University 627 Stanford, CA 94305 629 Email: Bob.Morgan@Stanford.EDU