Subject: key usage values

From: Ken Raeburn <[email-masked]>
Date: Fri, 08 Aug 2003 21:02:57 -0400

What quality of protection is intended to be afforded by key usage
values, if the current DES enctypes are specifically not permitted?

For example, could direction-specific key usage values be used to
prevent reflection attacks?  I.e., use different key usage values
depending whether you're the authentication initiator or acceptor, and
then you can drop the direction flag from your messages, and rely on
integrity protection to reject reflected messages because you can't
decrypt them with the wrong key usage value.  If it works, this would
give stronger protection, because it's not possible to accidentally
omit a test of the direction flag.  (Well, you could implement it
wrong, but any interoperability testing with someone who got it right
would fail, not just testing of detection of reflection attacks.)

I'm thinking about this in the context of extending RFC 1964 (my
approach, not Nico's, obviously, and based on some discussions with
Larry Zhu), where we could in fact rule out the use of DES keys, but
ideally that should be a list of enctypes that should never need
updating in the future.

If that's not possible, perhaps the use of key usage values should be
a testable attribute, such that we can say, "only use enctypes that
use key usage values to perturb their encryption".

In hindsight, I'm concerned that the language describing key usage
values in the Kerberos crypto draft might not be strong enough to make
them actually useful for a protocol designer to rely on.  I think we
kept it too weak so as not to make the DES enctypes be explicitly
non-compliant.  (And making it too strong probably would've required
some sort of analysis of when we might get collisions out of the use
of n-fold in the simplified profile when using different key usage
values.)

Larry and I have been exchanging a bunch of mail about extending the
GSSAPI mechanism to support AES, what's needed for general Kerberos
crypto support, limitations of SSPI, etc.  I'm not sure if we'll reach
agreement on a mechanism, but either way, I think we'll be bringing a
proposal or two -- one if we agree, two if we don't :-) -- back to the
WG list soon.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Aug 2003 23:41:08 -0700

> proposal or two -- one if we agree, two if we don't :-) -- back to the

So have Larry and I.  I suspect we're on the same page.

With respect to reflection attacks, I think we can definitely dedicate
one bit of the sequence number field (instead of 32 bits in rfc1964!) to
be a direction flag *and* derive different encryption keys for each
direction (for enctypes that support key usages).  The one bit flag
costs us nothing and saves us the bother of thinking about key
derivation collisions and whether key derivation should be mandatory for
all new enctypes.

Cheers,

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Sat, 09 Aug 2003 12:29:16 -0400

> derivation collisions and whether key derivation should be mandatory for

I think if the key derivation and the use of key usage values is
omitted from a new enctype, that's going to open up a whole new can of
worms that we may not want to have to think through all the details
of.

One example that immediately comes to mind is the case of doing
PA-ENC-TIMESTAMP preauth in conjunction with using the ticket's
timestamp to figure out what the offset is between the client clock
and the KDC's clock.  To do that, you presumably need to encrypt a
timestamp you get from an insecure source.  Since we have key usage
values, it appears to be the case that while the insecure time source
might be able to get you to encrypt a bogus timestamp, at least
nothing is going to be willing to decrypt that other than the
PA-ENC-TIMESTAMP code.  If you could get a client to encrypt an
arbitrary timestamp that could be decrypted by anything in Kerberos
that wants to decrypt something encrypted in the user's key, there may
be new attacks that become possible.

At the very least, a lot of protocol analysis would need to be done,
and it is probably easier and safer to require each enctype to support
key usage values.

(It also appears to me that skipping the key derivation doesn't really
have any substantial benefit.)