Network Working Group RL "Bob" Morgan Internet Draft Stanford University draft-morgan-ident-ext-00.txt August 1996 S/Ident: Security Extensions for the Ident Protocol Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress``. To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire before January 1997. Distribution of this draft is unlimited. 1. Abstract The Ident protocol, RFC 1413, specifies a method for a host to request from a remote host an assertion of an identifier associated with a TCP connection between the two hosts. This memo proposes extensions to Ident to support strong (i.e., cryptographic) authentication methods. The extensions are based on the Simple Authentication and Security Layer (SASL), draft-myers-auth- sasl-03.txt. 2. Motivation and Background Many application protocols in use today do not offer strong, cryptography-based authentication mechanisms. Even for those that do, particular implementations may not support them. Or, the mechanisms supported by a protocol or its implementations may not match an organization's security infrastructure. In these cases a RL "Bob" Morgan draft-morgan-ident-ext-00.txt [Page 1]
Internet Draft S/Ident August 1996 work-around that can be employed is to modify an application server to call back, out of band of the original application connection, to a separate component on the client which can provide the authentication service. The Ident protocol, RFC 1413, provides a method for the target of a TCP connection to send a request to the system from which the connection initiated, asking it for the identity of the "user" that initiated the connection. RFC 1413 only defines clear-text exchanges. This proposal specifies the use of strong authentication schemes for Ident exchanges. The resulting protocol is called "S/Ident". RFC 1731 specifies an authentication framework and mechanisms for the IMAP protocol. This framework has been generalized into the "Simple Authentication and Security Layer" (SASL) in draft-myers-auth- sasl-03.txt. This proposal adapts that framework to extend the Ident protocol. 3. Terminology In most protocols the initiator of a connection is the "client", and the target of the connection is the "server". In the proposed scheme it is normally a server that would "call back" to the client system to request authentication information. To avoid confusion, this memo calls the system that asks for the authentication information the "requester", and the system that returns this information the "responder". Also, the security principal who is authenticated by the response is referred to as the "user", and the receiver and processor of the authentication response as the "application". 4. S/Ident design 4.1. Protocol and data format The Ident protocol uses messages in US-ASCII text, terminated by the <CR-LF> sequence. A request is of the form <responder-port> , <requester-port> for example 6191, 23 A response is of the form <responder-port> , <requester-port> : <resp-type> : <add-info> RL "Bob" Morgan draft-morgan-ident-ext-00.txt [Page 2]
Internet Draft S/Ident August 1996 for example 6193, 23 : USERID : UNIX : stjohns 6195, 23 : ERROR : NO-USER RFC 1413 specifies resp-type values of USERID and ERROR. A USERID response may include a user name in the usual sense, or some other information (such as encrypted information), identified by the token OTHER. S/Ident extends the request to be of the form <resp-port> , <req-port> : AUTHENTICATE : <auth-req> [ : <auth-req> ] that is, the token "AUTHENTICATE" followed by one or more fields specifying authentication request information. Several auth-req fields may be included to allow the responder a choice of methods. They are in the order of requester's preference; the responder should use the first one it can to construct a valid response. The requester should accept any one of the methods it offers. The auth-req field is of the form <auth-mech> , <auth-req-info> where auth-mech is a registered identifier for an authentication mechanism, and auth-req-info is information specific to that authentication mechanism. The response format is extended to have a new resp-type of AUTHENTICATE. In this case a response is of the form <port-num> , <port-num> : AUTHENTICATE : <auth-resp> The auth-resp field is of the form: <auth-mech> , <auth-resp-info> where auth-resp-info is specific to the authentication mechanism. If the responder does not wish to use any of the authentication mechanisms proposed by the requester in its initial request message, it can specify a different mechanism in its response. In this case the <auth-resp-info> field will be empty. The auth-req-info and auth-resp-info fields each might contain any binary data. Accordingly, the data in these fields is encoded in base64 (as specified in RFC 1521) before transmission. Note that RL "Bob" Morgan draft-morgan-ident-ext-00.txt [Page 3]
Internet Draft S/Ident August 1996 there should be no line breaks (<CR-LF>) in the field itself, since a line break terminates the entire record. 4.2. ERROR responses New values for the <add-info> field of ERROR responses are defined as appropriate for each mechanism. Note that messages from the requester to the responder may now indicate errors also; in this case the error value is put into the auth-req-info field. New generic error values: AUTH-NOT-SUPPORTED Indicates that none of the authentication mechanisms offered by the requester are supported for authentication of the owner of the indicated connection. It can also be sent by the requester to indicate that the authentication mechanism specified by the responder is not supported. INVALID-AUTH-REQ-INFO Indicates that one or more of the supplied values in the auth-req- info field are syntactically invalid. INVALID-AUTH-RESP-INFO Indicates that one or more of the supplied values in the auth-resp- info field are syntactically invalid. USER-CANT-AUTH Indicates that the authentication mechanism is supported for the owner of the connection, but that no authentication information is available for that user. AUTH-FAILURE Indicates that an authentication verification operation failed. 4.3. Connection management RFC-1413 Ident exchanges consist of a single request string and a single response string. S/Ident exchanges may include several requests and responses. A particular S/Ident connection has at most one exchange in progress; that is, interleaving requests from different exchanges is prohibited. An ERROR message from either requester or responder terminates the exchange. A connection may RL "Bob" Morgan draft-morgan-ident-ext-00.txt [Page 4]
Internet Draft S/Ident August 1996 remain open after an exchange is completed so that other exchanges can be conducted on it; or it can be closed by either side. 4.4. Mapping to SASL When a protocol is extended to use SASL, a protocol message is defined that permits a client to request the use of a particular security mechanism with the server. This is the initial message in the SASL exchange. In Ident, the initial event is normally the connection request from the client. Rather than impose an additional round-trip, the server acting as the S/Ident requester offers a set of security mechanisms to the client in its initial message. The S/Ident responder can propose a single different mechanism in its initial response; in this case this message functions as the initial SASL message. 5. Mechanism definitions The following sections describe how some SASL-defined security mechanisms are applied to S/Ident. 5.1. Kerberos version 4 mechanism The auth-mech token for the Kerberos 4 authentication mechanism is as specified in SASL ("KERBEROS_V4"). The auth-req-info for the first request message in this mechanism is the challenge as specified in SASL, a random 32-bit number in network byte order. In response to the first request message, the responder sends a message whose auth-resp-info field is a Kerberos ticket and an authenticator for the service principal "ident.hostname@realm", where "ident" is the service name, "hostname" is the first component of the host name of the server with all letters in lower case, and where "realm" is the Kerberos realm of the server. The client principal is the principal associated with the owner of the connection specified in the request. As specified in SASL, the encrypted checksum field included within the Kerberos authenticator contains the server provided challenge in network byte order. The requester, receiving the response message, proceeds as in SASL. It decrypts and verifies the message. If valid, it adds one to the checksum value and makes this the first four octets of its eight octet response. Since S/Ident does not use a security layer, a bit is set to indicate this, and the cipher-text buffer size is set to zero. It encrypts the 8 octets using DES, as in SASL, and sends the result as the auth-req-info field in a second request message that is RL "Bob" Morgan draft-morgan-ident-ext-00.txt [Page 5]
Internet Draft S/Ident August 1996 otherwise identical to the first (except that it need not contain auth-req fields for any other mechanisms that might have been included in the initial message). The responder processes the second request message to verify the checksum and authenticate the requester. It does not generate a second response message. 5.2. GSSAPI mechanism The auth-mech token for the all mechanisms using the GSSAPI is as specified in SASL ("GSSAPI"). Protocol interactions occur as specified in SASL. The service name for the requester is "ident". There is no security layer. 5.3. One-Time Password mechanism The auth-mech token for the one-time password system specified in RFC 1938 is "OTP". Protocol interactions occur as specified in SASL for the S/Key mechanism. 6. Compatibility If a RFC 1413 responder receives an extended-format request, it might (1) not respond at all, (2) respond with an an ERROR due to the presence of the extended fields, (3) ignore the extended fields and respond as usual, perhaps with a USERID response. In any case the requester can determine that no valid response was received. The no- response case could be a problem since it would result in a long timeout. An extended responder should be configurable to either respond to RFC 1413 traditional requests in the traditional way, or to give an ERROR response. 7. Security considerations This protocol can provide only authentication information. Protection of the integrity or confidentiality of the application stream can not be provided. Use of this protocol is inferior to the provision of proper security mechanisms within application protocols, and should not be considered as a reason not to develop them. It should only be used as a last resort when the application protocol can not be secured. RL "Bob" Morgan draft-morgan-ident-ext-00.txt [Page 6]
Internet Draft S/Ident August 1996 Since the software handling the authentication interaction is different from the client application that makes the initial connection, it may be difficult for a user to understand that a prompt requesting authentication information (e.g., a password) is related to the original application action. This may require careful user interface design and user education. 8. Acknowledgements Cornell's Project Mandarin implements a callback authentication scheme called "SideCar" (SideCar is the responder side, FrontCar is the requester side). This proposal borrows the basic callback idea from there. Craig Jurney and Roland Schemers of Stanford made suggestions leading to the re-use of Ident. John Myers of CMU is the creator of SASL. The MacLeland team at Stanford, including Andy Maas and Jeff Mapes, did an implementation of an earlier version of this protocol. 9. Author's Address RL "Bob" Morgan Distributed Computing and Communication Systems Pine Hall Stanford University Stanford, CA 94305 Email: Bob.Morgan@Stanford.EDU RL "Bob" Morgan draft-morgan-ident-ext-00.txt [Page 7]