[2920] in Kerberos
Re: Krb 5 replay cache
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Thu Dec 9 14:17:20 1993
Date: Thu, 9 Dec 93 13:55:14 EST
From: tytso@MIT.EDU (Theodore Ts'o)
To: Jim_Miller@suite.com
Cc: kerberos@MIT.EDU
In-Reply-To: Jim Miller's message of Mon, 29 Nov 93 22:12:55 -0600,
From: jim@bilbo.suite.com (Jim Miller)
Date: Mon, 29 Nov 93 22:12:55 -0600
Reply-To: Jim_Miller@suite.com
The routine 'krb5_rd_req_decoded' places both the unparsed sender name and
the unparsed client name in the 'rep' structure (see rc_conv.c). However,
'krb5_rd_priv', and 'krb5_rd_safe" initialize the 'rep' structure using a
different strategy.
Q1: Why doesn't it set "replay.server" to anything?
Because rd_priv and rd_safe don't have access to the sender and client
names anymore. So, they use krb5_gen_replay_name() to store the sender
address and the flag "_priv", and stash that information in the replay
cache. That information, plus the time in microseconds resolution, is
used to guard against the replay attack.
It might be useful to include the recipient address (if presnet) and
encode that for the server field, but it's not really necessary. Also,
since this not a protocl issue, it can be easily added at some later
point.
The routines 'krb5_mk_priv' and 'krb5_mk_safe' use this same strategy for
storing info into the client's replay cache.
Q2: Why does the client need create a replay cache to *send* a
timestampped private or safe message?
If the message is sequence numbers aren't used (and so therefore the
message is timestammped) then there is a danger that an attacker might
be able to take the private or safe message and send it back at the
client at some other point where it is expecting a private or safe
message, as long as its within the time skew window. (The possibility
is actually pretty small, since the client and the sender would have to
have the same address; but it is possible.) The replay cache prevents
this.
- Ted
