Projects/replay_cache_collision_avoidance and replay cache uses

[Nicolas Williams]

On Mon, Jan 05, 2009 at 04:00:04PM -0500, ghudson at mit.edu wrote:
> In the process of preparing to implement
> Projects/replay_cache_collision_avoidance I noticed that we don't just
> use the replay cache for received authenticators.  The full range of
> uses are:
> 
>   * krb5_rd_req (the basic authenticator case)
>   * krb5_mk_priv/krb5_rd_priv
>   * krb5_mk_safe/krb5_rd_safe
>   * verify_sam_response (KDC preauth)

Ah, right.  And don't forget KRB-CRED.

> (mk_priv and mk_safe store replay records presumably so that an
> attacker cannot reflect messages back at the sender.)

KRB-SAFE and KRB-PRIV have an s-address field that can prevent
reflection (yes, yes, NAT, multi-homing, ...).  And then there's
sub-session keys.

> [...]
> 
> Second, we have to decide what string to hash in each use case.  If
> people would like to sanity check, my plan is:
> 
>   rd_req: Ciphertext of authenticator (as passed to krb5_c_decrypt)

As discussed.

>   mk_priv/rd_priv: Ciphertext of message (as passed to krb5_c_decrypt)
>   mk_safe/rd_safe: String against which checksum is computed (see below)
>   verify_sam_response: sam_track_id field of response (as passed to
>    krb5_c_decrypt)

If it's easy enough, sure.  But just so we're clear: KRB-PRIV/SAFE are
not (or should not be) remotely the motivator for this project.

In the case of KRB-PRIV/SAFE the best thing to do is to always use
sequence numbers, not time, and to always assert sub-session keys.  I'm
not sure what protocols exist that use KRB-PRIV/SAFE much, but these
come to mind:

 - kprop (but not iprop, which is RPC based) (uses sequence numbers)
 - kpasswd and RFC3244 (uses sequence numbers (at least in the MIT
   code-base)
 - set/change password v2 (I forget what the I-D says; I'll make sure it
   says to use sequence numbers)

Are there others?  (UName*It uses KRB-PRIV/SAFE, someone might want to
check what it does.  What about Zephyr and other Athena friends?)

> For mk_safe/rd_safe, what our code does is encode the KRB_SAFE message
> with a zeroed checksum, compute the checksum, and then re-encode the
> message with the checksum set.  On the receiving end, the message is
> decoded, re-encoded with a zeroed checksum, and the received checksum
> is verified against the re-encoded message.  It's this
> message-encoded-without-checksum string which should be hashed in the
> replay record (even though that string never appears on the wire),
> since that is what the attacker would have difficulty modifying
> without invalidating the checksum.

Sounds reasonable to me, though likely unnecessary.  I assume there will
be testing (remember, it's likely that no commonly used apps will use
this feature).

Nico
--