Questions on kerb 4 vice kerb 5

[Ted Anderson]

On Mon, 19 Nov 2001 14:14:46 -0800 "Henry B. Hotz" <hotz at jpl.nasa.gov> wrote:
> > I am not quite sure what you mean by the weel-known reply
> > vulnerability,
> 
> if it matters:                                      replay, not reply

Right, that's what I meant.  Also s/weel/well/.

> >but the Rx and K4 authentication (TGT) protocols do have an important
> >difference.  The Rx protocol's request requires a timestamp to be
> >encrypted with the user's password.  This means that the kaserver can
> >reject bogus requests and those more than a few (15?) minutes old.
> >This solves the problem of the K4 protocol in giving out "free"
> >samples of ciphertext.
>
> Kind of sounds like it -- except I thought that the problem was that
> k4 had timestamps, but the server allowed around 5-15 minutes of slop
> (because people were generally sloppy about setting clocks back then
> and NPT wasn't developed yet).  There was plenty of time for an attack
> robot to capture and replay the requesting packets and get its own
> ticket/token.
>
> In other words your description of rx matches my memory of the k4
> problem.
>
> Since I guess I've exhausted the store of free technical advice on
> the subject can I ask people for a reference to the rx protocol so I
> can concievably figure this out for myself?

Well, I kind of hate the implication that I've been tapped out already,
though I applaud your willingness to track down the answer for yourself.
I am not at all current the state of documentation for the kaserver and
Rx.  However, since I wrote the former and have dabbled in the latter on
and off for more than a decade, I feel sure I could answer your question
if only I understood it.

So let's try again.  The vulnerability of K4 that I am talking about is
that an attacker can request a TGT from the server for any user whose
name it knows.  The resulting ticket is encrypted with the user's
password, so isn't a direct risk or of immediate use to the attacker.
Collectively, however, this allows a dictionary to be constructed with
ciphertext samples encrypted with every user's password.  The dictionary
enables an effective off-line attack in parallel on all the system's
passwords.

I avoided this in the Rx kaserver interface because the request contains
a timestamp encrypted with the user's password.  This allows the
kaserver to reject queries from requesters that clearly don't know the
user's password.  This makes it difficult to assemble a large dictionary
for an off-line attack.  Instead the attacker would have to monitor the
network leading to the kaserver and collect ciphertext samples as each
users authenticates.  This is a much more challenging and risky task.
In support of this improvement, it is possible to configure the kaserver
so that it doesn't respond on port 750 (the standard K4 port), but, of
course, it could be blocked with a firewall as well.

There was a rationale for this behavior in K4.  The designers didn't
want kinit to request the user's password before contacting the server,
because then the password would sit around in the program's memory while
it waited for the server's response.  They were worried about a core
dump attack that would allow capture of user's passwords from public
workstations.  In Kerberos version 5, the authentication request
protocol was changed to require proof of password possession.  Thus, it
now works much like the Rx interface to the kaserver.

The timestamp allows a window of 5-15 minutes because clocks really are
very badly synchronized in the real world, especially client clocks.
The currency of the timestamp allows the kaserver to validate a
successful decryption of the request.

The reason this isn't really a "replay" attack, to my thinking, is that
requesting a ticket is idempotent and doesn't expose any new
information.  If the attacker can re-inject the request into the
network, he can surely see the original response come back.  To make
sense of this he needs the user's password.  But if he has this he can
just request a TGT directly.  I think the "replay attack" generally
refers to the use of timestamps to authenticate uses of a ticket.  You
don't want an attacker to be able to delete a file he once saw deleted
by just replaying his side of an old conversation, without knowing the
session key even if the ticket it depends upon is still valid.

Of course, a 5-15 minute window is still a long one, so purely UDP based
servers are really supposed to maintain a replay cache (bounded to 5-15
minutes worth of entries).  This really isn't a problem for the
authentication server itself (K4, K5 or kaserver), but for application
servers it may be significant.  In AFS, Rx provides enough connection
orientation to prevent replay attacks.  The last serious problem along
those lines was exposed by Peter Honeyman and his CITI group and fixed
back in 1991.

In this sense of "replay attack", I don't think K4 or K5 or the kaserver
are vulnerable and the Rx protocol protects AFS servers from this risk.

So does this clear up the situation any?  Can you restate the security
concern you have in this context?

Ted Anderson

[1] http://web.mit.edu/afs/sipb/contrib/doc/AFS/hijacking-afs.ps.gz