Re: Last Call: Telnet Authentication Option to Proposed Standard

[Harald Tveit Alvestrand <[e-mail]>]

At 17:35 23.11.99 -0500, Jeffrey Altman wrote:
> > Protocols that offer increased complexity but no gain in security or
> > efficiency over other standards-track efforts, but are in use today, are
> > IMHO excellent candidates for Informational publication.
> >
> > Not for the standards track.
>
>I think the point of this debate is whether or not there is added
>strength to the encryption.  And so far the opinions have been
>divergent.  If 3DES is a better PRNG than DES then it is stronger.

Indeed. Or rather: If draft-altman-telnet-enc-des3-[cfb,ofb] describes a 
mechanism where the best known attack is (significantly)more difficult than 
the best known attack on draft-tso-telnet-enc-des-[cfb,ofb], it should go 
to Proposed Standard (and the shoe is on the other foot; the -des- ones 
shouldn't go forward to Proposed, since DES-protected data is known to be 
vulnerable to brute force attacks).


>As we point out in the Drafts, the telnet encryption stream mechanism
>is susceptible to attacks.  We know that.  We have addressed it in
>various ways.  Unfortunately, the Telnet AUTH option implementations
>for Kerberos 4, Kerberos 5, and Secure Remote Password all rely on the
>Telnet Encryption option for privacy.  I don't think it is appropriate
>to send Telnet Auth to Proposed Standard with its reliance on an
>option that is Informational.  Hence, the desire for all of these
>drafts to go to Proposed Standard.

I'm not at the moment questioning whether draft-tso-telnet-encryption-04.txt
should go to Proposed; the question hasn't been raised.
I'm questioning the arguments for letting 
draft-altman-telnet-enc-des3-cfb-01.txt and 
draft-altman-telnet-enc-des3-ofb-01.txt should go to Proposed.


>The TN3270 WG is working on a Telnet over TLS draft which has seen
>several independent interoperable implementations for TN3270 and well
>as more traditional telnet.  My hope is to integrate Telnet over TLS
>with Telnet AUTH so that Telnet AUTH may be used to provide mutual
>authentication via a TLS using an ADH cipher.  The one problem I have
>run into is that the TLS Library vendors (other than OpenSSL) have
>been very resistent to exporting the contents of the Finished messages
>to the application so that they may be used in the Telnet Auth
>negotiation to provide mutual authentication of the TLS.  Once this
>draft goes to Proposed Standard I would recommend that the Telnet
>Encryption option be moved to Historical.  But until that happens we
>need it on the standards track.
>
>These drafts have been floating around the net for almost eight years
>with many implementations.  Its time for them to move on.

If it is possible to satisfy RFC 2026 para 4.1.1:

    A Proposed Standard should have no known technical omissions with
    respect to the requirements placed upon it.  However, the IESG may
    waive this requirement in order to allow a specification to advance
    to the Proposed Standard state when it is considered to be useful and
    necessary (and timely) even with known technical omissions.

Yes.

                      Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[e-mail]