Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!unmvax!ncar!ames!eos!shelby!JUNE.CS.WASHINGTON.EDU!bcn
From: bcn@JUNE.CS.WASHINGTON.EDU (Clifford Neuman)
Newsgroups: comp.protocols.kerberos
Subject: some comments on Kerberos
Message-ID: <8905180607.AA03766@june.cs.washington.edu>
Date: 18 May 89 06:07:19 GMT
References: <8905171437.aa29674@huey.udel.edu>
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 52

The comment by Dan Nessett is quite accurate.  You do need a mechanism
to prevent replays.  Looking through your paper, I see a way to
accomplish this, but it requires me to make a few assumptions which
were not specified.  From you paper, I get the impression that the
authentication provided is intended for internal authentication
between a group of timeservers.  Extending it to the end user results
in the key distribution problem you were asking about.

First, for the techique to prevent replays within your protocol.  It
requires that the party receiving each authenticated message keep
track of the last message received under that key.  Further, it must
make sure that the time in such messages is always increasing.  This
will prevent replays, but you must still provide some mechanisms to
prevent deliberately delayed packets from causing problems.  This
might not be a problem for your protocol, but I would have to look at
your entire protocol to determine that (and, unfortunately, I don't
have the time right now).

If you are not going to require that servers maintain the time from
the last message received under each key, you will have to use a
challenge response mechanism using a nonce of some kind.  When
requesting the time, the client sends a nonce which is included
encrypted with the response along with the encrypted timestamp (or
checksum of the timestamp).  You would have to make sure that the
encrypted timestamp can not be modified without causing the nonce to
change, but this can be accomplished with an appropriate ordering of
fields and the use of a suitable encryption chaining method.  This
approach would require a different format (and probably length) for
your message authentication field.

I actually think you would be much better off if you left the contents
and length of the authentication field open, and include a field
indicating type of authentication used.  This would allow you to push
both problems off to a separate authentication protocol.  You might
then want to suggest the use of two such protocols.  The first being
one of the low overhead ones just described for use between
timeservers.  The second would be one incorporating key distribution.
It would be used by the end user.

Kerberos could be used for the second protocol.  The timeservice would
be interesting in the sense that it is more important to authenticate
the service than the user.  In fact, the timeserver itself probably
doesn't care who the user is.  Anyway, to use Kerberos, the request to
the timeserver would include the client's ticket and authenticator.
By decoding these credentials, the timserver would obtain the session
key and the client's timestamp (which for mutual authentication
purposes is equivilant to a nonce).  The response would then be the
same as in the challenge response protocol described above except that
the key would be the session key, and the nonce would be the client's
old timestamp.

	~ Cliff