Replay cache protection josephharfouch at
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?
   Scenario 2
   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.
   Many Thanks
   Jospeh Harfouch

More information about the krbdev mailing list