Replay cache protection
josephharfouch at iinet.net.au
Fri Feb 8 12:27:40 EST 2008
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