Path: utzoo!attcan!uunet!lll-winken!ames!pasteur!ucbvax!agate!shelby!ATHENA.MIT.EDU!jtkohl
From: jtkohl@ATHENA.MIT.EDU (John T Kohl)
Newsgroups: comp.protocols.kerberos
Subject: Re: some comments on Kerberos
Message-ID: <8905101320.AA09961@LYCUS.MIT.EDU>
Date: 10 May 89 13:20:47 GMT
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 33


	...
	ticket/authenticator pairs captured by an intruder by observing the 
	traffic passing over an Ethernet or through an intermediate node can 
	be replayed.
	...

This is a bug in the current implementations.  The authenticator
contains a sealed request_id which the server is supposed to check
against the request_id's produced in the last <n> minutes (where <n> is
the max allowed clock skew).  Any duplication should be treated as
a replay attack.

	o  Kerberos is designed to work in an environment in which all 
	administrative domains use the same communications protocol (e.g., 
	TCP/IP).

We recognize this undesirability, and we plan to allow/support multiple
protocols (e.g. ISO, IP, ...) in the next version of Kerberos.

		In addition, all servers of all realms must support the 
	Kerberos protocol in order to interoperate.
	...

Not strictly true.  As long as a service provider has access to a secret
shared with its KDC, it can `play the game' as a passive recipient of
authentication information.  If the service provider wants to initiate
authentication to some other entity, it needs to speak the Kerberos
protocol to the appropriate KDC's, and it needs to know what
communications protocol to speak with those KDC's.

John Kohl <jtkohl@ATHENA.MIT.EDU>
Digital Equipment Corporation/Project Athena