Re: domain-based service names redux
Jeffrey Hutzelman <jhutz <at> cmu.edu>
2007-06-14 19:05:57 GMT
On Thursday, June 14, 2007 12:33:45 PM -0600 Peter Saint-Andre
<stpeter <at> jabber.org> wrote:
> It's not clear to me how the session replay attack you mention is
> specific to the architecture I described. Couldn't an attacker send an
> earlier ticket even if there is only one service involved (i.e., in my
> description, only one connection manager)?
The basic Kerberos protocol provides only a limited amount of reply
protection for applications, by requiring that clients include in their
request a timestamp which must be "close enough" to the server's clock.
The idea is that you get full replay protection by combining this with a
cache which stores all messages received within the "close enough" period
-- messages that are too old are rejected outright; more recent messages
are rejected if they appear in the replay cache. This only works if
servers which share the same service key also share the same replay cache.
(BTW, the details of Kerberos are getting just a bit far afield for the
Kitten list; at the GSS-API layer you're not supposed to care much what
mechanism is being used, and at the SASL layer you should care even less).
Depending on the application involved, this may not be an issue. For
example, some application protocols are designed such that the application
messages themselves are protected from replays, or require some sort of
initial exchange that makes a replay impossible.
Similarly, you have to see a message to replay it, so if you are always
using TLS _and checking the server's certificate_, then you need not worry
about your credentials being replayed to a server. Of course, servers do