[869] in Kerberos_V5_Development
Re: Proposed Kerberos V5 Password Changing Algorithm
daemon@ATHENA.MIT.EDU (eichin@MIT.EDU)
Fri Feb 24 16:53:56 1995
Date: Fri, 24 Feb 95 16:51:47 -0500
To: tytso@MIT.EDU
Cc: rsalz@osf.org, krbdev@MIT.EDU
In-Reply-To: <9502241928.AA16140@sulphur.osf.org> (message from Rich Salz on Fri, 24 Feb 95 14:28:20 -0500)
From: eichin@MIT.EDU
Overview of my points: text-based isn't useful, nor is it widespread,
but the proposed binary protocol has too much in it and should be
pruned.
>> Because 95% of all IETF app-level protocols are text-based
Let's see, a random look at /etc/services here...
ftp -- command structure is text, but actually data exchange
is "raw" (binary, or 36 bit :-)
telnet -- 8-bit binary protocol
pop -- text, but then email is 7-bit anyway.
smtp -- text, and historically 7-bit. The text encoding (the
lack of quoting for "." for example) can be considered a *flaw*...
ntp -- binary (for efficiency/speed of parsing!)
bootp -- binary
sunrpc -- binary
dce -- binary
nntp -- text, with 8-bit data
r* -- binary (they've got problems, but this isn't it)
snmp -- binary. ASN.1 in fact.
x11 -- binary.
Sure, that's not all protocols, or even specifically IETF protocols,
it's just a quick survey of enough examples to show that whatever it
is, it isn't *clear*.
>> So that you can test it with TELNET
It wouldn't help... since you're going to need to armor the KRB_PRIV
messages anyway, there's really nothing "human readable" in the
protocol to begin with.
ASCII armor is only useful for non-clean streams, and if you're in
that situation, see Derek Atkins' "Charon" work.
Other comments:
I think the protocol can be made even simpler.
Besides, from the description given, we've got a text protocol inside
anyhow... If I can summarize, it is
-> KRB_AP_REQ
<- KRB_AP_REP
<- {"welcome message", \0}_{KRB_PRIV}
-> {"changepw", \0, 2, len:"oldpw", len:"newpw"}_{KRB_PRIV}
<- {NO_ERROR, 0}_{KRB_PRIV}
or... <- {PW_UNACCEPT, 1, len:"choose a better pw"}_{KRB_PRIV}
-> {"QUIT", \0, }_{KRB_PRIV}
<- {NO_ERROR, 0}_{KRB_PRIV}
There's some baggage there... how about something like
-> KRB_AP_REQ
<- KRB_AP_REP
-> { CPW_CODE, len:"oldpw", len:"newpw" }_{KRB_PRIV}
<- { SUCCESS_CODE, len:"message" }_{KRB_PRIV}
or... <- { FAIL_NEWPW, len:"message" }_{KRB_PRIV}
or... <- { FAIL_OLDPW, len:"message" }_{KRB_PRIV}
and then... just close it.
where CPW_CODE is a numeric value (might as well be 1 byte, though
making it a word is ok too -- but *why* make it a null terminated
string?)
Some other suggestions:
1) throw out the MOTD service. There are a whole host of
issues with doing that "right" and you've ignored all of them. Also,
this way the protocol is a simple bang-bang interchange
2) permit or recommend UDP implementation as well (after all,
nothing in the protocol actually needs TCP, right?)
3) don't mix length-strings and null-terminated-strings. I'd
recommend using *only* length-strings, to simplify allocating storage
and packet-size sanity checks.
4) throw out the QUIT command and reply. All it seems to
provide is another opportunity for protocol failure (any time the
response "must" be a certain value brings up the question of "then why
transmit the value in the first place, and why check it if you do?")
5) throw out the argument counts -- the command code is enough
to make it clear how much is needed. If more arguments are needed in
the future, add new command codes.
_Mark_ <eichin@cygnus.com>
Cygnus Support, East Coast
