Subject: Telnet AUTH option GSSAPI-KRB5 type (notes for discussion at Kerberos Mtg)

From: Jeffrey Altman <[email-masked]>
Date: Mon, 31 Jul 2000 23:24:07 EDT

Microsoft Windows 2000 provides Kerberos as a GSSAPI compatible SSPI
but does not provide access to the traditional krb5 api.  This makes
it impossible to implement kerberos 5 authentication mechanisms for
applications which rely on the krb5 api (using the Win32 api).  Telnet
is one application protocol which uses the krb5 api to implement
kerberos 5 authentication.

In the past, Microsoft has implemented the telnet AUTH option without
proper concern for the IETF protocol specifications.  In the case of
the NTLM AUTH type, Microsoft engineers originally distributed their
code with an authtype value already assigned by IANA to another
authentication method.  Even after IANA convinced them to register for
a value, the NTLM authtype has never been properly documented
regardless of the promises by the project manager to IANA to do so
once the product shipped.

There is a strong need to implement a method for securing telnet
sessions to/from Windows 2000.  It would be preferred for us in the
IETF to take the lead in developing this protocol rather than leave it
to a Microsoft development team that is ignorant of the IETF
process. Besides, we have a better understanding of the Telnet AUTH
option and the plans for its integration with the Telnet START_TLS
option.

As an overview, the Telnet AUTH option allows multiple authentication
methods to be negotiated.  The server sends an ordered list of
acceptable authentication type pairs to the client.  The client is to
choose the first authentication method it supports.

A type pair consists of two octets.  The first represents an
authentication method such as Kerberos V5 or Secure Remote Password.
The second octet is a bit mask specifying: the authentication
direction; whether mutual authentication is to be used; and how
encryption is to be provided.  There are four encryption modes: none;
via telnet ENCRYPT option; encrypt after AUTH mode; and via telnet
START_TLS option.

When GSSAPI-KRB5 will always be negotiated as CLIENT_TO_SERVER with
MUTUAL authentication.  There will be three modes depending on the
setting of the AUTH_ENCRYPT mode.

  AUTH_ENCRYPT_NONE:
    GSSAPI-KRB5 protects the auth-type pair but does not provide
    encryption

  AUTH_ENCRYPT_AFTER_EXCHANGE:
    GSSAPI-KRB5 protects the auth-type pair and does provide
    encryption

  AUTH_ENCRYPT_START_TLS:
    GSSAPI-KRB5 protects the auth-type pair plus the TLS connection
    but does not provide encryption

  AUTH_ENCRYPT_USING_TELOPT:
    MUST NOT be implemented with GSSAPI-KRB5 as GSSAPI-KRB5 encryption
    is stronger than TELOPT ENCRYPT.  (TELOPT ENCRYPT does not provide
    integrity protection.)

Outstanding questions:

 . which mech types are to be used?

 . how to control credential forwarding?

 . how much detail can be hidden from telnet?

 . what service name is to be used?  KRB5 uses the "host" service
   name.

                  Jeffrey Altman * Sr.Software Designer
                 The Kermit Project * Columbia University
               612 West 115th St * New York, NY * 10025 * USA
     http://www.kermit-project.org/ * [email-masked]

---

From: "Booker C. Bense" <[email-masked]>
Date: Tue, 1 Aug 2000 10:50:42 -0700 (PDT)

On Mon, 31 Jul 2000, Jeffrey Altman wrote:

[Lots of ugly history deleted]

> choose the first authentication method it supports.

- I don't want to start any protocol wars here, but is there any
reasonable way to incorporate SASL into the AUTH protocol? This 
would provide an easy way forward when new authentication schemes
come into existence. The problem as I see it is that SASL is much
more of an algorithm than a protocol. Each use of SASL requires 
that you define it's "application profile" or how it interacts
with the existing protocol. It gets awfully fuzzy when you start
talking about mutual authentication and encryption. 

- What I'n thinking of is something like 

AUTH SASL 

to indicate that you know how to do the SASL dance.

- Booker C. Bense 

P.S. if this is a really dumb idea, flame away...