Telnet Authentication: Simple-Strong Authentication

[Steven Schoch <[e-mail]>]

We have a working implementation of Telnet Authentication using the
Simple-Strong Authentication method.  I would like to see this proposed
as an internet-draft.  Can I get some feedback from the IETF group on this?
Thanks.

	Steve

							    Steven Schoch
							    NASA Ames
							    August 1994


               Telnet Authentication: Simple-Strong Authentication


1. Command Names and Codes

   Authentication Types

      SSA  23	(this number may change!)

2.  Command Meanings

   IAC SB AUTHENTICATION IS <authentication-type-pair> <SSA token> IAC SE

      This is used to pass the Simple-Strong Authentication token to
      the remote side of the connection.  The first octet of the
      <authentication-type-pair> value is SSA, to indicate the use of
      the Simple-Strong Authentication method.

      The format of the Simple-Strong Authentication token is defined
      as the "Authentication Value" in the NIST document "Output from
      the March 1994 OSE Implementors Workshop", part 12, section
      9.1.1.1, and the X.511 standard (ISO9594-3).  For the purposes of
      the telnet protocol, the "certification-path" element of
      "StrongCredentials" is not OPTIONAL.

      The token will be encoded using the ASN.1 Basic Encoding Rules (BER).

      Currently, the Simple-Strong-Authentication method only supports
      one-way authentication.  Therefore the second octet of the
      <authentication-type-pair> must be AUTH_HOW_ONE_WAY.

3.  Implementation Rules

   Because the purpose of this authentication type is to avoid sending
   clear-text passwords over the network, it is recommended that the
   client only send "Authentication-Value" tokens of type "Strong", not
   "Simple".  This implies that the more-restrictive Distinguished
   Encoding Rules (DER) as defined in X.509 (ISO9594-8) be used.

   The "Strong" authentication token has the "Intended-Recipient" as
   one of its elements.  Possible values for this element are the
   pseudo-DN "@o=Internet@presentationAddress=Internet=<IP address>"
   where <IP address> is the IP address of the server to which the
   client is connected, the pesudo-DN "@cn=<host.domain-name>" where
   <host.domain-name> is the fully-qualified domain name of the server,
   or a real DN that has been assigned to the server.  Another possibility
   is to use a DN as specified in RFC-1608 or RFC-1609.

   The server will determine the identity of the sender of the token
   from the subject of the certificate sent as the first element of the
   "Certification-Path".  If no IAC SB AUTHENTICATION NAME has been
   sent by the client, the server determines the user name by referring
   to a table that maps DNs to user names.  If an IAC SB AUTHENTICATION
   NAME has been sent, the server determines whether the sender of the
   token is authorized to login as the user name by referring to a
   (possibly different) table which contains a list of possible user names
   for each DN.

Author's Address

   Steven Schoch NASA
   Ames Research Center
   m/s 233-18
   Moffett Field, CA 94035

   Phone: [phone]
   EMail: [e-mail]