Replay cache protection

[josephharfouch@iinet.net.au]

   Hi,
   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