Subject: [abfab] Does GSS-EAP need an acceptor subkey

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Sep 2010 14:04:52 -0400

Are there any reasons to have an RFC 4121-style acceptor subkey in
GSS-EAP?

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Sep 2010 13:17:54 -0500

> Are there any reasons to have an RFC 4121-style acceptor subkey in

The initiator and acceptor will both share a high-quality (one hopes)
MSK/EMSK from which to derive 'specific keys'[*].  I see no reason to
have the acceptor (nor initiator) provide additional 'protocol keys'[*].

[*] 'Protocol key' and 'specific key' are terms from RFC3961 (the crypto
    framework that RFC4121 uses).  Specific keys are the keys actually
    used for AES/whatever encryption/decryption, and are derived from
    protocol keys.  Protocol keys are the keys that are the result of
    key exchanges, sent around in protocol messages, etcetera.

    Here MSK/EMSK are protocol keys, from which we'd derive specific
    keys for use in RFC4121 per-message tokens (and for keying the PRF
    too).  We might want to derive RFC4121 protocol keys from MSK/EMSK,
    rather than directly derive RFC4121 specific keys from MSK/EMSK,
    that way more of RFC4121 implementations can be re-used and the
    interface to them can be simpler.

---

From: Josh Howlett <[email-masked]>
Date: Tue, 7 Sep 2010 19:41:07 +0000

Sam,

> Are there any reasons to have an RFC 4121-style acceptor subkey in

I think this is quite orthogonal to your question, but it's somewhat related and so may be helpful nonetheless. When I started sketching the GSS-EAP mechanism I was unsure about the appropriate use of key usage values in the case of non-Kerberos protocol keys being applied with RFC3961. Nico set me straight:

http://www.ietf.org/mail-archive/web/kitten/current/msg01579.html

I don't think I captured this in the initial sketch of the mechanism.

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: Sam Hartman <[email-masked]>
Date: Tue, 07 Sep 2010 15:52:59 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas>     Here MSK/EMSK are protocol keys, from which we'd derive
    Nicolas> specific keys for use in RFC4121 per-message tokens (and
    Nicolas> for keying the PRF too).  

No, they are random bit strings converted into protocol keys using
random-to-key (also from RFC 3961).

    Nicolas> We might want to derive RFC4121
    Nicolas> protocol keys from MSK/EMSK, rather than directly derive
    Nicolas> RFC4121 specific keys from MSK/EMSK, that way more of
    Nicolas> RFC4121 implementations can be re-used and the interface to

Yes, we might want to do this.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Sep 2010 15:01:29 -0500

> random-to-key (also from RFC 3961).

Well, yes, I skipped a step (that one could glean from reading RFC3961),
but only as a way to indicate that I'd much rather derive RFC4121

> Yes, we might want to do this.

My main point was that if you have an API to construct Kerberos-less
(i.e., just for the per-message tokens and PRF, thanks) RFC4121 security
contexts, then you'd want to have to pass in only protocol keys, not
specific keys.

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Wed, 8 Sep 2010 11:54:23 +0200

Noted, I'll use different usage numbers.

#define KEY_USAGE_ACCEPTOR_SEAL             512
#define KEY_USAGE_ACCEPTOR_SIGN             513
#define KEY_USAGE_INITIATOR_SEAL            514
#define KEY_USAGE_INITIATOR_SIGN            515

On 07/09/2010, at 9:41 PM, Josh Howlett wrote:

> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab
> 

--
www.padl.com | www.thisismagnolia.net

---

From: Sam Hartman <[email-masked]>
Date: Wed, 08 Sep 2010 08:50:23 -0400

>>>>> "Luke" == Luke Howard <[email-masked]> writes:

    Luke> Noted, I'll use different usage numbers.  #define

wait won't using different usage numbers make sharing code with  4121
harder?
Wouldn't it be easier to just make sure that the context root key has
gone through some sort of PRF that is specific to gss-eap?

--Sam

---

From: Luke Howard <[email-masked]>
Date: Wed, 8 Sep 2010 15:03:58 +0200

> gone through some sort of PRF that is specific to gss-eap?

Ack

-- luke

---

From: Luke Howard <[email-masked]>
Date: Wed, 8 Sep 2010 15:29:32 +0200

What about

random-to-key(rfc3961-prf(random-to-key([e]msk), "rfc4121-gss-eap"))

?

L

---

From: Sam Hartman <[email-masked]>
Date: Wed, 08 Sep 2010 10:51:25 -0400

>>>>> "Luke" == Luke Howard <[email-masked]> writes:

    Luke> What about random-to-key(rfc3961-prf(random-to-key([e]msk),
    Luke> "rfc4121-gss-eap"))

    Luke> ?
That works for me.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 8 Sep 2010 09:56:23 -0500

>     Luke> "rfc4121-gss-eap"))

And me.

---

From: Luke Howard <[email-masked]>
Date: Tue, 14 Sep 2010 01:18:51 +0200

Notwithstanding my confusion reading RFC 3961 s.5.3 and exactly how the message size m (which for RFC 3962 is one byte) relates to the the PRF length...

For key derivation where PRF length != key length, we need to do something similar to RFC 4402. So I'm proposing we do that (counter-based PRF).

---

From: Sam Hartman <[email-masked]>
Date: Tue, 14 Sep 2010 08:45:07 -0400

>>>>> "Luke" == Luke Howard <[email-masked]> writes:

    Luke> Notwithstanding my confusion reading RFC 3961 s.5.3 and
    Luke> exactly how the message size m (which for RFC 3962 is one
    Luke> byte) relates to the the PRF length...  For key derivation
    Luke> where PRF length != key length, we need to do something
    Luke> similar to RFC 4402. So I'm proposing we do that
    Luke> (counter-based PRF).

Uh, yes.
Sorry about not noticing that.