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

From: Jeffrey Altman <[email-masked]>
Date: Tue, 1 Aug 2000 14:25:50 EDT

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

You do not want to negotiate SASL under AUTH for the exact same 
reasons that you do not want to negotiate SPNEGO under SASL.
Each negotiation provides an ordered list of authentication methods
in order of reduced strength.  The client is to choose the strongest
authentication method that it supports.  When you create multiple
levels of negotiation you can't ensure that the strongest method
will be selected.

If you want to do SASL then you need to implement a TELNET SASL
option.  But then you have incompatibities between existing AUTH 
implementations and SASL. You can't do both. 

Besides there is no reason to develop SASL for TELNET.  TELNET already
has a method for negotiating among 15 different authentication
methods.  Plus, adding SASL does not solve the problem of providing an
authentication method for Windows 2000.  SASL is not an SSPI on 
Windows 2000.  You would still need to implement GSSAPI-KRB5.  So
there is no benefit.

Chris Newman published a Telnet SASL option I-D in 1998.  His primary
argument in favor of SASL was to provide the integrity protection that
Telnet ENCRYPT did not provide; and to allow GSSAPI to be used under
Telnet.  At this point in time, Telnet START_TLS was already
published as an I-D and deployed.  It was known that TLS was the 
long term direction to use for providing integrity protection and
privacy for Telnet.  The lack of GSSAPI was not a priority because
there were no GSSAPI implementations that did not also have an
equivalent Telnet AUTH method; and there are several Telnet AUTH
methods which do not have equivalents in either SASL or GSSAPI.

At the Telnet/Kermit BOF in November 1998 several approaches were
discussed and SASL was rejected by the unofficial working group.

The IESG/IAB have been provided a proposal for a Telnet Security WG to
finish the work that Ted, Russ, and I have done over the last two
years on Telnet Authentication and Encryption.  Last month, the IESG
approved as Proposed Standards the Telnet AUTH and ENCRYPT options
along with the I-Ds describing the IANA registered methods.  The WG
will finish the work of integrating START_TLS and AUTH, deprecate
ENCRYPT to HISTORIC, and finish the work on the X Windows System data
forwarding. (TELNET FORWARD_X)  Someone would have to make an
extremely strong case at this point for us to reconsider SASL in
Telnet.  

- Jeff

                  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]