[prev in list] [next in list] [prev in thread] [next in thread] 

List:       krbdev
Subject:    Fwd: Replay cache protection
From:       "josephharfouch () iinet ! net ! au" <josephharfouch () iinet ! net ! au>
Date:       2008-02-11 7:14:08
Message-ID: 62676.1202714048 () iinet ! net ! au
[Download RAW message or body]


   Hi,
   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?
   Thanks
   Joseph
   ----- Original Message -----
   From: 'josephharfouch@iinet.net.au'
   To: krbdev@mit.edu
   Sent: Sat Feb 9 2:27
   Subject: Fwd: Replay cache protection
   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
   
_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev


[prev in list] [next in list] [prev in thread] [next in thread]