[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 02 04                                                      
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
   <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>

   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

     <responder-port> "," <requester-port>
          [":" <keyword> [":" <req-ext-data> ]* ]

   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 : <opsys,charset> : <id-string>
     6195, 23 : ERROR : <error-type>

   This memo extends the response format to be:

     <ports> ":" <resp-type> ":"
        [":" <resp-type-info>]* [":" <resp-ext-data>]*

   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 [: <auth-req> ]*

   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

     <auth-mech> , <auth-req-info> [, <auth-req-modifier> ]*

   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

     <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.



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 <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 2045 [RFC-2045]) before transmission.
   Note that there MUST NOT be any line breaks (<CR-LF>) 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 <add-info> 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/<submech>.  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]