Network Working Group RL "Bob" Morgan Internet Draft Stanford University draft-morgan-ident-ext-04.txt March 1998 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 in September 1998. Distribution of this draft is unlimited. Table of Contents Status of This Memo 1. Abstract 2. Motivation and Background 3. Terminology 3.1. Roles 3.2. Requirements 4. S/Ident design 4.1. Ident extension format 4.1.1. Keyword and value syntax 4.1.2. Request format 4.1.3. Response format 4.2. Authentication extension 4.2.1. Authentication request 4.2.2. Authentication response 4.3. S/Ident authenticator RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 1] Internet Draft S/Ident March 1998 4.4. ERROR responses 4.4.1 ERROR response types 4.4.2 Extended ERROR response keywords and values 4.5. Connection management 4.6. Mapping to SASL 5. Mechanism definitions 5.1. Kerberos version 4 mechanism 5.1.1. USER-INTERACTION modifier 5.2. GSSAPI mechanism 5.2.1. USER-INTERACTION modifier 6. Compatibility 7. Security considerations 8. Formal syntax 9. Acknowledgements 10. References 11. Author's Address 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 specifies extensions to Ident to support strong (i.e., cryptographic) authentication methods. The extensions are based on the Simple Authentication and Security Layer [RFC-2222]. 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 a site's security infrastructure. In these cases, rather than simply living with inadequate authentication, a site can work around the problem by using a modified application server that calls back, out of band of the original application connection, to a separate component on the client system which can provide the required 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 originated, which responds with an identifier for the owner of the indicated 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 [RFC-1731] specifies an authentication framework and RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 2] Internet Draft S/Ident March 1998 mechanisms for the IMAP protocol [IMAP]. This framework has been generalized into the "Simple Authentication and Security Layer", SASL [RFC-2222]. This proposal adapts that framework to extend the Ident protocol. 3. Terminology 3.1. Roles 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". In their roles in the application, these systems are called the "application server" and the "application client." 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". The set of S/Ident protocol messages resulting from an initial request is called a "session." 3.2. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 4. S/Ident design 4.1. Ident extension format The Ident protocol uses messages in US-ASCII text, terminated by the sequence. A request is of the form , for example 6191, 23 A response is of the form , : : for example RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 3] Internet Draft S/Ident March 1998 6193, 23 : USERID : UNIX : stjohns 6195, 23 : ERROR : NO-USER This memo specifies extended formats for requests and responses. 4.1.1. Keyword and value syntax Several protocol constructionss defined in this memo use "keyword" and "value" syntax elements. These are defined as: keyword-value ::= keyword | nonstd-keyword "=" value [ "," value ] keyword ::= initial kvchar+ nonstd-keyword ::= "X" kvchar+ initial ::= < A-Z a-z 0-9 > value ::= kvchar+ kvchar ::= < A-Z a-z 0-9 - !@#$%^&*()_+.<>/?~{}[] > That is, a keyword value sequence is a keyword followed by "=" followed by one or more comma-separated values. A standard keyword defined in this or other standards-track memos must begin with an alphanumeric character; non-standard keywords must begin with "X". A value may include any characters from the set above; specifically ",", ":", "=", and ";" are excluded. If a value might need to represent other (e.g., binary) data, it must be specified to be encoded in base64 format, as specified in RFC 2045 [RFC-2045]. 4.1.2. Request format This memo extends the RFC 1413 request format to be of the form "," [":" [":" ]* ] that is, a ":", a keyword identifying the extension, and optional req-ext-data fields, each preceded by a ":". The req-ext-data field is in the "value" syntax as defined above. At most one extension is included with a request. 4.1.3. Response format RFC 1413 specifies resp-type values of USERID and ERROR, each with its own format: RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 4] Internet Draft S/Ident March 1998 6193, 23 : USERID : : 6195, 23 : ERROR : This memo extends the response format to be: ":" ":" [":" ]* [":" ]* where resp-type-info is zero or more fields, as determined by the response type, and each resp-ext-data field is a keyword-value sequence as defined above. 4.2. Authentication extension An authentication request extension is defined as AUTHENTICATE [: ]* that is, the token "AUTHENTICATE" followed by zero or more fields specifying authentication request information, separated by ":". Each field identifies an authentication mechanism; 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 MUST accept any one of the methods it offers. The auth-req field is of the form , [, ]* where auth-mech is a registered identifier for an authentication mechanism, and auth-req-info is information specific to that authentication mechanism. The auth-req-modifier field is a keyword- value sequence as defined above. The auth-req-modifier fields modify the behavior of the responder in handling a response using this mechanism; the auth-req-info field contains information, if any, intrinsic to the operation of the mechanism. The response format is extended to have a new resp-type of AUTHENTICATE. In this case a response is of the form , : AUTHENTICATE : The auth-resp field is of the form: , where auth-resp-info is specific to the authentication mechanism. RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 5] Internet Draft S/Ident March 1998 If the responder is not able to use any of the authentication mechanisms proposed by the requester in its initial request message, it MAY specify a different mechanism in its response. In this case the 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 2045 [RFC-2045]) before transmission. Note that there MUST NOT be any line breaks () in the field itself, since a line break terminates the entire record. 4.3. S/Ident authenticator A structure, called the "S/Ident authenticator", is sent by the responder as a part of one of its responses. It is protected from modification and disclosure in mechanisms that support such protection. It is defined as: {resp-flags, resp-port, req-port, authid-len, authid, pad} where resp-flags is a two-octet field (in network byte order) where: Bit zero (the LSB), the NMA (no-mutual-auth) bit, if set, indicates that the responder is not interested in the mutual authentication message from the requester, so the requester need not send it. This might be set by a responder with limited resources that wishes to limit the session to a single request- response pair. All other bits of resp-flags MUST be zero when sent and MUST be ignored when received. resp-port and req-port are the TCP port numbers (in binary form, in network byte order) from the request; authid-len is the two-octet length in octets, in network byte order, of the following authid field; authid is the "authorization identity" (as described in [RFC-2222]) asserted by the user; and pad is zero to seven zero-valued octets to bring the total pre- encryption length of this structure to a multiple of eight octets. 4.4. ERROR responses RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 6] Internet Draft S/Ident March 1998 New values for the field of ERROR responses are defined as appropriate for each mechanism. Note that messages from the requester to the responder indicate errors also, if appropriate; in this case the error value is put into the auth-req-info field. New generic ERROR response values are defined below. In addition, an extended ERROR response format is defined to allow the responder to return information to the requester that may be useful in a subsequent request. Some standard extension values are defined below. 4.4.1 ERROR response values New generic error values include: 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 MAY 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.4.2. Extended ERROR response keywords and values This section defines keywords and values for use in the resp-ext-data field of extended ERROR response messages. RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 7] Internet Draft S/Ident March 1998 Keyword: CAPABILITY. Values following the CAPABILITY keyword indicate optional capabilities that are supported by the responder. A responder SHOULD include the CAPABILITY block listing all of its capabilities in each error response. CAPABILITY values defined in this memo include: Value: USER-INTERACTION. This capability indicates that the responder supports the ability to prompt the user on the responding system to supply information to support the S/Ident interaction. Keyword: AUTH-MECH. Values following the AUTH-MECH keyword indicate authentication mechanisms supported by the responder. Each value is the same as the authentication mechanism token defined for that mechanism. For the GSSAPI mechanism, supported sub-mechanisms are separately listed as GSSAPI/. Values defined in this memo are: GSSAPI/KERBEROS_V5, GSSAPI/SPKM, GSSAPI/DCE. A responder SHOULD include the AUTH-MECH block listing all of its supported mechanisms in each error response. 4.5. Connection management A RFC-1413 Ident session consists of a single request message and a single response message. An S/Ident session MAY include several requests and responses. A particular S/Ident TCP connection has at most one session in progress; that is, interleaving requests from different sessions is prohibited. An ERROR message from either requester or responder terminates the session. A connection MAY remain open after a session is completed so that other sessions can be conducted on it; or it MAY be closed by either side. 4.6. 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. This message should contain an argument identifying a SASL mechanism. In Ident, the initial message is normally the connection request from the client using the application protocol. Rather than impose an additional round-trip, the server acting as the S/Ident requester offers a set of authentication mechanisms to the client in its initial message. The responder selects one mechanism to use for its response, or responds with an ERROR message, optionally announcing the authentication mechanisms that it supports. 5. Mechanism definitions RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 8] Internet Draft S/Ident March 1998 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 [KERB-4] is as specified in RFC 2222 ("KERBEROS_V4"). The auth-req-info for the first request message in this mechanism is the challenge as specified in RFC 2222, 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 consists of the following parts, concatenated together: (1) a two-octet integer in network byte order indicating the length of part (2) in octets; (2) 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 RFC 2222, the encrypted checksum field included within the Kerberos authenticator contains the server provided 32-bit challenge in network byte order. (3) a two-octet integer in network byte order indicating the length of part (4) in octets; (4) the S/Ident authenticator, encrypted using DES PCBC mode with the session key from the Kerberos ticket. The requester receives and decrypts the response message. It verifies the Kerberos ticket and authenticator, and the 32-bit challenge value. It uses the session key to decrypt the S/Ident authenticator, and verifies the port values. If all these conditions hold, the requester considers the responder authenticated, and the requester (or the application server that called it) MAY then evaluate the principal and the authorization identity for access control purposes. Independent of this evaluation, the requester proceeds as described below. If the requester determines that there is an error in the response, it sends the appropriate S/Ident error message to the responder and concludes its processing for the session. RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 9] Internet Draft S/Ident March 1998 In the no-error case, if the NMA bit in the resp-flags field of the S/Ident authenticator is set, the requester concludes its processing without sending another message. Otherwise, the requester forms a new message as follows. It adds one to the checksum value and makes this the first four octets of its SASL-specified eight octet response field. 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 ECB mode with the session key, as in SASL, and sends the result as the auth-req-info field in a second request message that is 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, if any, to verify the checksum and authenticate the requester. It does not generate a second response message. 5.1.1. USER-INTERACTION modifier The "USER-INTERACTION" modifier keyword has two possible values: "YES" and "NO". The "NO" value indicates that the responder SHOULD generate a response using whatever credentials are available for the user, but SHOULD NOT (if possible) prompt the user to provide authentication information (this allows the response to be sent more or less immediately). The "YES" value indicates that the responder SHOULD, if credentials are unavailable, prompt the user, if possible, to provide authentication information, blocking its response until the user interaction is complete. The "NO" value is the default. 5.2. GSSAPI mechanism The auth-mech token for the all mechanisms using the GSSAPI [GSSAPI] is as specified in RFC 2222 ("GSSAPI"). Protocol interactions occur as specified in RFC 2222. The service name for the requester is "ident". There is no security layer. The "authorization identity" field in the final response message contains the complete S/Ident authenticator. The requester verifies the port values in the authenticator. If they are correct, it makes the authid value and any responder credentials available to the calling application for use in access control evaluation. 5.2.1. USER-INTERACTION modifier This is defined identically to the KERBEROS_V4 USER-INTERACTION RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 10] Internet Draft S/Ident March 1998 modifier. 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 data 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. Since the software (i.e., the responder) 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. Setting of the "no-mutual-auth" flag by the responder prevents the responder from being able to check that a request came from an authentic requester. This can increase the responding system's vulnerability to requests from malicious sources, though there is no obvious attack that can be mounted by such a malicious source. If multiple services on a single host employ S/Ident to authenticate their clients, they must necessarily share access to the ident service credentials on that host. This implies that such services are in a single trust domain on that host, and therefore that trusted services (i.e., those operating at a high privilege level) and untrusted services should not both run on the same host if they are using the S/Ident scheme for authentication. RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 11] Internet Draft S/Ident March 1998 Similarly, any login users on a service host that uses S/Ident can relatively easily generate valid request messages to clients of that host. This suggests restricting login access to hosts that use S/Ident to authenticate their clients. Several measures can be used by a responder to limit its vulnerability to potentially abusive requests. Requests can be filtered based on the IP address or the DNS domain of the requester. After a certain delay following the establishment of a TCP connection, the responder can stop responding to requests about that connection. A responder can answer the first request about a connection, and drop any subsequent requests. A responder can display information about the request to the user, and ask for confirmation before responding (though this decision may be difficult for the user to make). On a multi-user system, a responder may be configured with a list of identities (e.g., UNIX "root") for which it always responds with a NO-USER or USER-CANT-AUTH error. Furthermore, note that if the system on which the responder is running is running any TCP-based services, a requester can initiate a request to one of these services and then request authentication on that connection (this includes the S/Ident responder itself!). This potentially allows any host to cause the responder to produce a valid response. If the responder on a single-user system were to treat all connections as belonging to that single user and respond with authentication data for that user, this may be an undesirable exposure. On a multi-user system the response would depend on what identity the servers use; a valid response may also be an exposure in this case. To prevent this abuse, responders can treat requests with a responder-port equal to some configurable list of service ports in a special way, perhaps always responding with a NO-USER error. If the responder can distinguish connections initiated remotely from those initiated locally, it can return an error on requests for authentication of remotely-initiated connections. 8. Formal syntax (to be supplied) 9. Acknowledgements Stuart Cheshire's Macintosh Authenticator [MAC-AUTH], developed at Stanford, implements a similar approach to a security callback scheme. Andy Hanushevsky of Cornell's Project Mandarin developed a callback authentication scheme called "SideCar" (SideCar is the responder side, FrontCar is the requester side) [SIDECAR]. This proposal RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 12] Internet Draft S/Ident March 1998 borrows the basic callback idea from there. The MacLeland team at Stanford [MACLELAND], including Andy Maas and Jeff Mapes, did an implementation of an earlier version of this protocol. Lynn McRae persisted in promoting the callback concept despite the author's initial resistance. Craig Jurney and Roland Schemers made suggestions leading to the adaptation of Ident and SASL. Booker Bense made substantial contributions in the process of doing the initial implementation. 10. References [KERB-4] Steiner, J., Neuman, B., Schiller, J., "Kerberos: An Authentication Service for Open Network Systems", Usenix Conference Proceedings, 1988. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, University of Washington, December 1996. [GSSAPI] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997. [MAC-AUTH] Cheshire, S., Crellin, N., "The Cheshire/Crellin Macintosh Print Accounting Package", http://rescomp.stanford.edu/macauth.html. [MACLELAND] Maas, M., "MacLeland Project", http://www- leland.stanford.edu/~maas/macleland/. [RFC-1413] M. St. Johns, "Identification Protocol", RFC 1413, 1993. [RFC-2045] Freed, N., Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", November 1996. [RFC-1731] J. Myers, "IMAP4 Authentication mechanisms", RFC 1731, 1994. [RFC-2222] J. Myers, "Simple Authentication and Security Layer", RFC 2222, October 1997. [Sidecar] http://www.mandarin.org/. 11. Author's Address RL "Bob" Morgan Computing and Communication Systems RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 13] Internet Draft S/Ident March 1998 Pine Hall Stanford University Stanford, CA 94305 Email: Bob.Morgan@Stanford.EDU RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 14]