Subject: Re: Telnet Encryption Specification

From: Jeffrey Altman <[email-masked]>
Date: Wed, 4 Feb 98 10:00:26 EST

I finished reading through the draft-tso-telnet-auth-enc-00.txt and I
am wondering about a few things:

First, is this draft supposed to represent how things are in the
current implementations or in a future (incompatible) implementation?

The reason I ask is because the use of the INI_CRED_FWD bit causes 
Kerberos 5 1.0.x Telnetd to stop processing the connection since
the combination of the bits does not match the numerical value of 
the requested Authentication types.

This comes back to a question I asked about a month ago but never
received a definitive answer:

  "as the negotiations proceed is it an error if the Authentication
   Modifier bits change?"

By the implementation of INI_CRED_FWD described in this document
the apparent answer to that questions is 'No' it is not an error if
the bit flags change since the INI_CRED_FWD could be turned on at
any point.

---

The definition of the ENCRYPT bit which requires successful
negotiation of encryption after authentication is appropriate.
However, existing K4 implementations (although they follow the
example) do not use an ENCRYPT bit.  Will this be backwards compatible
to existing implementations?  [I haven't tried this yet.]

---

Is it appropriate for the only example to be from Kerberos 4?  It
makes the draft appear to apply only to Kerberos 4 and not to other 
Authentication schemes.

---

The second example describes using encryption.  However, I think that
it needs to be restated that this is to be done with the Telnet
Encrypt Option.  

Also, in the second example the ENCRYPT_ON bit appears to disappear
from the CHALLENGE and the RESPONSE messages.  Would this be
considered a protocol error?

- Jeff

P.S. - How do I subscribe to [email-masked]?

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
       612 West 115th St #716 * New York, NY * 10025 * (212) 854-1344
    http://www.columbia.edu/kermit/k95.html * [email-masked]

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 4 Feb 1998 18:54:21 -0500

Date: Wed, 4 Feb 98 10:00:26 EST
   From: Jeffrey Altman <[email-masked]>

Well, it was *supposed* to represent how things are now..... but....

Err.. yes.  That's a problem in the 1.0 telnetd implementation,
actually.  I didn't catch this discrepancy earlier; thanks for finding it!

The problem is the Krb5 1.0 implementation didn't implement, and hence
doesn't recognize the INI_CRED_FWD bit.  The idea was to not send the
telnet authentication forwarding commands unless you were sure the other
side would know how to deal with them.  

So it's a good idea in the protocol, but we screwed up the
implementation by not recognizing the bit.  This can be easily fixed,
and we can release a patch that does it, although there is a
compatibility issue for deployed servers that don't know about the bit.
Oops.  Hmmm, how we deal with this will require more thought.

Yes, it's an error if the Authentication modifier bits change.  In fact,
a good implementation should either (a) check this, and abort if the
other side doesn't do things right, or (b) remember the original initial
authentication modifier bits, and ignore the ones in subsequent
messages.  

It's backwards compatible because the bit's meaning "MUST_ENCRYPT".  You
can do encryption without that bit, and in fact what happens is that
when you do the negotiation, you prefer MUST_ENCRYPT, but you can start
encryption even without the MUST_ENCRYPT bit.

Do people care about that?  We need one example protocol, and it can be
Kerberos V4, Kerberos V5, KEA with Skipjack, or any number of other
possibilities.   I suppose we could use a different protocol for the
second example.

OK, I can do that.

It should be considered a document error  :-)   Thanks for pointing it
out.

Send mail to [email-masked], I believe.

Thanks for the comments!!  They were very helpful.

						- Ted