Subject: [Ietf-krb-wg] FAST and armor keys: yet another misuse of subkeys

From: Sam Hartman <[email-masked]>
Date: Wed, 21 Jan 2009 10:38:14 -0500

regularize the use of subkeys.  In particular, we generally want the
client subkey to be used unless the server provides a subkey, in which
case the server subkey is used.

Currently, the FAST spec does that.  However, we want FAST armor to
form a channel in the sense of RFC 5056.

As we discussed, any channel name is likely to be derived from the
armor key.  In the uses we're talking about the name will actually be
implicit: by using the armor key in encryption or combining the armor
key to form other keys, we'll force things to be part of that channel.
It may be the case that someone wants a more traditional name for a
FAST channel and hashes the armor key; doing so is fine but we have
not yet needed to do so.

However, as we discussed, there is a problem with using the
client-supplied subkey as it interacts with anonymous pkinit.  A
man-in-the-middle can create a channel to both the client and the KDC
using the same armor key (and thus channel name).  The
man-in-the-middle can read the armor key supplied by the client as he
can decrypt the authenticator.  The man-in-the-middle can choose the
armor key to the KDC and can choose it to be the same as the key to
the client.  Thus, the man-in-the-middle becomes part of the channel.

We provided part of a fix to this in the anonymous draft: both the KDC
and client contribute to the session key, and the client can prove
this happened.  That means that a man-in-the-middle cannot force the
session key to be the same on both sides.

However we need to pull the fix into FAST.  I think the easiest way to
do that is to say that the armor key in the AS case is KRB-FX-CF2 of
the session key and the subkey in the authenticator.  The dis
advantage of this is that this is yet another case where the subkey in
an authenticator is used specially.

There are a couple of other options.  We could include an
authorization data provided by the client to be used as a PRF string
with the session key and not use the subkey field at all.

>From a cryptographic standpoint, that's basically the same  thing.

I'm going to move forward under the assumption that we will use the
subkey, although I'd appreciate comments from the WG.

--Sam

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg