Fwd: Replay cache protection
josephharfouch at iinet.net.au
Mon Feb 11 02:14:08 EST 2008
Just an update on my earlier email.
I've actually found something in RFC4120 about this :
All services sharing a key need to use the same replay cache.
If separate replay caches are used, then an authenticator used with
one such service could later be replayed to a different service with
the same service principal.
but the question I still have is : Should the APIs such as krb5_rd_req
be providing this service to the application, or should this be added
to the documentation of these APIs that customers should set up their
replay caches this way? i.e should it be a kerberos implementation
code change, or a documentation change?
----- Original Message -----
From: 'josephharfouch at iinet.net.au'
To: krbdev at mit.edu
Sent: Sat Feb 9 2:27
Subject: Fwd: Replay cache protection
I have been lately looking at the code concerned with preventing
replay att some undocumented s because of the way some a particular setup. This is be shared, but replay caches, accor MIT Kerberos code, may not be system wide, shared between servers. I'm not really very familia Kerberos code, so I wanted to get a second opinion whether t concerns are correct, or if I simply misunderstood the code. If some
o deal wit Scenario 1
Two applicaton servers A and B both have their their keys stored in
t written accept any valid versa. It seems s are written using gss where name in the ticket matches the n krb5 calls, such as krb5_rd_req with a se understanding is that any ticket that can be decrypte the matching entry in the keytab is acceptable, so theoreti Server A can decode server B' tickets and vice versa.
Now, if server A has just finished processing a server ticket that has
been authenticato skew time, I would&n attack because it just finished already stored it in its replay cache, bu that is a replay attack, i.e would B know that processed this ticket?
This is a variation of scenario 1, where the administrator has used
the sam machines. i.e A and theoretically decrypt each others ticke Scenario 3
Here, multiple application servers that share the same name!!! are
ru presumably becaus I had a look in RFCs 1510 and 4120 but I didn't find any comments
reg would be i you think an expa would be justified, or wheth documentation, setups and coding practic applications more vulnerable to replay attacks.
More information about the krbdev