[856] in Kerberos_V5_Development
Re: Proposed Kerberos V5 Password Changing Algorithm
daemon@ATHENA.MIT.EDU (John Gilmore)
Thu Feb 16 22:12:06 1995
To: "Theodore Ts'o" <tytso@MIT.EDU>
Cc: krbdev@MIT.EDU, gnu@cygnus.com
In-Reply-To: Your message of "Thu, 16 Feb 1995 17:31:28 +0500."
<9502162231.AA09108@dcl.MIT.EDU>
Date: Thu, 16 Feb 1995 19:11:57 -0800
From: John Gilmore <gnu@cygnus.com>
I'd like to propose that we use an ASCII rather than binary protocol
inside the KRB_PRIV messages. Kerberos is one of the few Internet
protocols that's infested with binary fields; the other protocols are
much easier to debug because humans can actually watch what's going
on with very little aid from their debugger, network monitor, etc.
In fact, I'd suggest that we simply open an encrypted stream to
the password server and then pass ASCII messages in the stream,
rather than sending KRB_PRIV messages.
As for how we open an encrypted stream, I recommend that the
negotiation be in ASCII, and involve proposing an encryption type and
accepting one of the proposed ones. Then the client creates a
sendauth-equivalent message containing a session key of that type
(krb_mk_auth, our recent K4 port called it), encodes it in ASCII, and
sends it as the argument of a command. The mutual authentication
response comes back similarly encoded. Upon mutual authentication,
the stream has been opened.
Example:
(connect to port)
->TEXT The message of the day
->TEXT is to use human readable protocols.
<-ESTREAM 3DES IDEA MCGUFFIN DES
->ESTREAM-ACK MCGUFFIN
<-EKEY K5 7583DE6AB762643E95834202948757639DBEF...
->EKEY-ACK 867573910958667392EFADBBBE
[Encrypted communication begins]
<-CHECK foo
->NOGO "foo" is too common a password.
<-PASS bar
->NOGO "bar" is even more common!
<-PASS 8i2salivate
->OKAY Password changed.
[Encrypted communication ends]
(break connection)
[We could put three-digit numbers ahead of the response messages
if we wanted to, to aid interoperation with future extensions to the
protocol.]
K4 set a horrible precedent with krb_sendauth() by dumping binary data
down an otherwise application-controlled socket. I'd like it if we in
K5 could set a better example for application writers, by already
standardizing e.g. ways of encoding the sendauth messages into ASCII
arguments of ASCII commands. This will help in the integration of K5
with many other popular ASCII-based protocols. We won't force this
on anyone, just set an example.
John
