Replay cache protection

[Ken Raeburn]

On Feb 11, 2008, at 2:14, josephharfouch at iinet.net.au wrote:
>    Hi,
>    Just an update on my earlier email.

First off, please don't send HTML-only email here.  Our mail server  
converts it to plain text before redistribution, but when it has long  
lines (as your first message did but your second did not), it gets  
pretty badly mangled before going out to the mailing list.  I don't  
know if or when we'll be able to fix this.  So for now, please send  
plain text, or short (~70 character) lines.

>    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?

It's not very practical for krb5_rd_req to provide a unified replay  
cache across machines, but krb5_get_server_rcache should be doing a  
reasonable first approximation of selecting a single cache for all  
servers using the same service name and running under the same uid,  
though it does require that you specify a service name.  Arguably, it  
should be unified across all uids (but that gets in the way in some  
test cases), and it should be dependent on the key, not the service  
name (but that needs to not leak information about the key to people  
who can list the rcache files)... and should probably support the  
model (which we don't really implement) wherein multiple services on  
a host can use the same key.  Like I said, a first approximation...

Addressing your scenarios from your earlier email (which came through  
garbled, but the un-garbled versions were contained in email  
notifying me that your message was in the moderation queue), yes, if  
two application servers, on the same or different hosts, both have  
access to the same service principals' keys but different replay  
caches, and the code is written to accept whatever service principal  
is supplied, yes, replay detection can be defeated.

But in the one-host case (two services intended to be used with  
different principals, but keys all stored in the same keytab file)  
that'd mean specifying the service name in determining the replay  
cache *and* not checking it during authentication, nor after.  Or, as  
is also possible, writing one of them to not use a replay cache at  
all.  The short answer is, "don't do that."  Of course, it would help  
if we had better library documentation, and perhaps some guides on  
how to use the Kerberos library within an application, with attention  
to security details like this for the uninitiated; we are, in fact,  
trying to address our documentation problems.

In the multiple-host case (part of your scenario 3: two server  
systems with the same principals and keys in their keytab files, and  
application server code not specifying a principal), there's been  
some discussion about how to redesign the replay cache to perform  
efficiently over NFS, or otherwise coordinate its data between  
systems, but no firm design nor implementation plan has come out of  
it yet.

Your scenario 2 (keytabs on two machines containing keys for a  
service on machine one and a service on machine two) has similar  
problems to scenario 1, and falls even more strongly under the "don't  
do that" category, as compromising machine one means being able to  
attack a different service on machine two as a result.

Note that more desirable than fixing these issues is fixing  
application protocols, when possible, so that replay protection is  
not needed.  For example, if the protocol exchange includes an AP-REP  
message, a subsession key generated by the server can be included  
there.  If it's required to be used to encrypt or checksum all  
following traffic, then an attacker who can only replay previous  
traffic sniffed off the wire can re-send the authenticator, but can't  
generate properly protected data using the new key generated by the  
server during the attack, which would be different from the key used  
for the previously recorded session.  But such an authenticator might  
be useable in a replay attack on another service using the same  
principal and not using such built-in protection in its protocol, so  
having such a protocol isn't itself sufficient to do away with the  
replay cache; you need to not have any vulnerable services using the  
same service principal.  In such cases, it is perfectly reasonable to  
not use a replay cache.

Another approach is to have protocol operations that are idempotent,  
or reveal too little cryptographic information to make replay attacks  
significant, and then just not worry about them.  For example, we  
don't generally consider replays in the TGS exchange to be much of a  
problem.


>    Thanks
>    Joseph
>    ----- Original Message -----
>    From: 'josephharfouch at iinet.net.au'
>    To: krbdev at 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

[... rest of mangled original message deleted.]

Kind of hard to read, sorry.... :(


-- 
Ken Raeburn, Senior Programmer
MIT Kerberos Consortium