Internet DRAFT - draft-ietf-morgan-ident-ext
draft-ietf-morgan-ident-ext
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 05:32:23 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 27 Nov 1996 00:18:00 GMT
ETag: "361b84-5ae8-329b88b8"
Accept-Ranges: bytes
Content-Length: 23272
Connection: close
Content-Type: text/plain
Network Working Group RL "Bob" Morgan
Internet Draft Stanford University
draft-morgan-ident-ext-02.txt November 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 in April 1997. Distribution of this draft is unlimited.
Table of Contents
Status of This Memo
1. Abstract
2. Motivation and Background
3. Terminology
4. S/Ident design
4.1. Ident extension format
4.2. Authentication extension
4.3. S/Ident authenticator
4.4. ERROR responses
4.5. Connection management
4.6. Mapping to SASL
5. Mechanism definitions
5.1. Kerberos version 4 mechanism
5.2. GSSAPI mechanism
6. Compatibility
RL "Bob" Morgan draft-morgan-ident-ext-02.txt [Page 1]
Internet Draft S/Ident November 1996
7. Security considerations
8. Acknowledgements
9. References
10. 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 [SASL].
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
mechanisms for the IMAP protocol [IMAP]. This framework has been
generalized into the "Simple Authentication and Security Layer"
[SASL]. 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
RL "Bob" Morgan draft-morgan-ident-ext-02.txt [Page 2]
Internet Draft S/Ident November 1996
"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."
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
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.
This memo extends the RFC 1413 request format to be of the form
<responder-port> , <requester-port>
[: <keyword> [: <extension data> ]* ]
that is, a ":", a keyword identifying the extension, and optional
extension data fields, each preceded by a ":". Neither the keyword
nor the extension data can contain the ":" character. Only a single
extension may be included with a request.
4.2. Authentication extension
RL "Bob" Morgan draft-morgan-ident-ext-02.txt [Page 3]
Internet Draft S/Ident November 1996
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>
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
there should be no 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:
RL "Bob" Morgan draft-morgan-ident-ext-02.txt [Page 4]
Internet Draft S/Ident November 1996
{resp-flags, resp-port, req-port, authid-len, authid, pad}
where
resp_flags is a two-octet field 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 SASL)
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
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
RL "Bob" Morgan draft-morgan-ident-ext-02.txt [Page 5]
Internet Draft S/Ident November 1996
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.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 can 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. 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
[KERB-4] is as specified in SASL ("KERBEROS_V4").
The auth-req-info for the first request message in this mechanism is
RL "Bob" Morgan draft-morgan-ident-ext-02.txt [Page 6]
Internet Draft S/Ident November 1996
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 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
SASL, 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) can 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.
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
RL "Bob" Morgan draft-morgan-ident-ext-02.txt [Page 7]
Internet Draft S/Ident November 1996
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.2. GSSAPI mechanism
The auth-mech token for the all mechanisms using the GSSAPI [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.
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.
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.
RL "Bob" Morgan draft-morgan-ident-ext-02.txt [Page 8]
Internet Draft S/Ident November 1996
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.
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
RL "Bob" Morgan draft-morgan-ident-ext-02.txt [Page 9]
Internet Draft S/Ident November 1996
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. 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
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.
9. 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
4", RFC 1730, University of Washington, December 1994.
[GSSAPI] Linn, J., "Generic Security Service Application Program
Interface, Version 2", draft-ietf-cat-gssv2-XX, Geer Zolot
Associates, May 1996
[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,
RL "Bob" Morgan draft-morgan-ident-ext-02.txt [Page 10]
Internet Draft S/Ident November 1996
1993.
[RFC-1731] J. Myers, "IMAP4 Authentication mechanisms", RFC 1731,
1994.
[SASL] J. Myers, "Simple Authentication and Security Layer",
draft-myers-auth-sasl-06.txt, 1996.
[Sidecar] http://www.mandarin.org/.
10. 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-02.txt [Page 11]
