Subject: Key usage values

From: "Josh Howlett" <[email-masked]>
Date: Thu, 9 Apr 2009 09:29:47 +0100

Section 2 of RFC 4121 defines four key usage values for naming specific
keys for signing and sealing.

Section 2 of RFC 3961 states that '[n]ew protocols defined in terms of
the Kerberos encryption and checksum types should use their own key
usage values.'

I infer from this that the key usage values defined in RFC 4121 can only
be used with that mechanism, and that newly defined mechanisms that also
use the Kerberos encryption and checksum crypto should define new usage
values.

Is that the correct interpretation?

If so, could someone kindly explain why this is necessary, and why it
isn't permitted to simply re-use the values defined for the K5 mechanism
if a new mechanism is re-using RFC3961 crypto?

Many thanks, josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 9 Apr 2009 11:14:35 -0500

> Is that the correct interpretation?

RFC4121 is a new protocol relative to RFC3961, but new GSS-API
mechanisms that re-use parts of RFC4121 wouldn't necessarily be new
protocols relative to RFC3961.

Also, that "should" is lower-cased, and even if it were up-cased it
would still only be a SHOULD.  Provided that you make sure that cut-n-
paste attacks aren't possible, then I think it would be reasonable to
say that it's so much easier to promote re-use of parts of RFC4121 if no
new key usages are required that protocols based on RFC4121 shouldn't
have to use different key usages.

Suppose you create a new GSS-API mechanism based on RFC4121, so much so
that if an attacker were to change the mechanism OID in the RFC2743
header the result could be accepted anyways, but with a loss of security
because the difference in security semantics somehow resides in the OID
of the mechanism used.  Then you have a problem.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 09 Apr 2009 12:36:34 -0400

> have to use different key usages.

What's important is that the same key doesn't get reused with the same key 
usage for different things, in such a way that data encrypted in one place 
could usefully be copied and pasted to another.  A new GSS-API mechanism 
which reuses the per-message tokens from RFC4121 but uses a key other than 
a Kerberos ticket session key should not have a problem.  In fact, IMHO 
such a mechanism _should_ use the same key usage values, rather than 
creating confusion by reusing the RFC4121 messages with minor differences.

-- Jeff

---

From: "Josh Howlett" <[email-masked]>
Date: Thu, 9 Apr 2009 17:37:24 +0100

> Suppose you create a new GSS-API mechanism based on RFC4121, 
> so much so that if an attacker were to change the mechanism 
> OID in the RFC2743 header the result could be accepted 
> anyways, but with a loss of security because the difference 
> in security semantics somehow resides in the OID of the 
> mechanism used.  Then you have a problem.

Interesting; I'll be mindful of that - thank you.

josh.

---

From: "Josh Howlett" <[email-masked]>
Date: Thu, 9 Apr 2009 17:47:09 +0100

> What's important is that the same key doesn't get reused with 
> the same key usage for different things, in such a way that 
> data encrypted in one place could usefully be copied and 
> pasted to another.  A new GSS-API mechanism which reuses the 
> per-message tokens from RFC4121 but uses a key other than a 
> Kerberos ticket session key should not have a problem.  In 
> fact, IMHO such a mechanism _should_ use the same key usage 
> values, rather than creating confusion by reusing the RFC4121 
> messages with minor differences.

That's what I intuited initially, but the text in RFC 3961 ('[n]ew
protocols defined in terms of the Kerberos encryption and checksum types
should use their own key usage values.') gave me cause for doubt.

I'll proceed as you suggest.

Many thanks, josh.