Subject: Re: [eap] hopefully final changes for draft-ietf-eap-keying

From: <[email-masked]>
Date: Fri, 16 Nov 2007 16:48:46 -0800

Forwarding for Dan.   

--------------------------------------------------------------------------------
From: Dan Simon
Sent: Friday, November 16, 2007 9:10 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [eap] hopefully final changes for draft-ietf-eap-keying

Having looked over the proposed changes, I share the concern about the modified language relating to key-sharing.  The new language is disturbingly vague-would any key-sharing among authenticators or EAP servers be acceptable, as long as the shared keys have passed through a key derivation step?  Since virtually all the keys in the hierarchy were derived at some point, the restriction on key-sharing would effectively disappear completely under the new language.

I would propose more restrictive changes to the language, but after looking at the documents of the HOKEY group (whence, as I understand it, the initiative to loosen the key-sharing language emerged), I can't for the life of me see any incompatibilities between their work and the current language.  Perhaps someone could articulate a clear, plausible example of a case where adherence to the current language significantly impedes HOKEY progress-or for that matter, progress on the design of any other useful protocol standard?

So my vote would be to leave the key-sharing portion of the text from -18 intact.

                                Dan Simon
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 17 Nov 2007 00:05:38 -0500

It seems that the change came from the following IESG DISCUSS comment:

https://datatracker.ietf.org/idtracker/draft-ietf-eap-keying/comment/73693/?

"
>An EAP authenticator MUST NOT share any keying material with
>another EAP authenticator, since if one EAP authenticator were
>compromised, this would enable the compromise of keying material on
>another authenticator. 

This text needs to be fixed to allow 802.11r style key hierarchies.
Previous text gets this correct.
"

As far as I understand 802.11r has a distributed authenticator model
in which an authenticator may span multiple APs.  Hence I don't think
this implies key sharing among multiple authenticators.

Regards,
Yoshihiro Ohba

---

From: <[email-masked]>
Date: Fri, 16 Nov 2007 22:47:06 -0800

> this implies key sharing among multiple authenticators.

That is correct.  I would encourage EAP WG members who have
not read IEEE 802.11r Draft 8.0 to look at it, since the authors appear to 
have
paid a lot of attention to the requirements of the EKMF and RFC 4962.

Some features:

1. Alignment of the authenticator identity provided to the peer (R0KH-ID) 
with the
NAS-Identifier attribute.

2.  Cryptographic separation of MSK-derived keys between the R1 key holders, 
as well
as separation from the key space from that utilized by other specifications,
including IEEE 802.11 and IEEE 802.1af, via use of unique key labels.

3.  Protection of SAP messages over the DS (when implemented along with 
11w).

4. Explicit communication of key lifetimes (TIE IE).

5. Prohibitions on sharing of PMK-R0s and PMK-R1s and requirements for 
deletion
of stale keys (see 11A2.2 and 11A2.3).

6. Discussion of parent/child relationships (see 11A4.2).

7. Support for PMK-R1 "push" (11A-13) and subsequent deletion of PMK-R0s 
(and PMKs?) which
prevents compromise of an R0KH from compromising R1KHs.

8. Support for authorization determination of the R1KH when implemented 
along with
11k and 11w (e.g. secured Neighbor Report).  Though the document is a bit 
confused about
the authorization properties of 11r when implemented alone (stating 
incorrectly in 11A2.2
that authorization to hold the R1KH is determined solely by possession), 
it's likely
that 11k, 11r and 11w will be implemented together (WFA Voice Enterprise 
certification requires both
11r and 11k), in which case authorization to hold an R1KH can be securely 
verified.

9. Protection of the reassociation exchange.

Overall, a lot of care has gone into the document.  .About the only thing 
that I found questionable was the use of
key names based on keying material.  Though it is handled better than with 
11i (a separate branch is used)
I believe this will still allow dictionary attacks on PSKs without 
sufficient entropy
(e.g. passwords). However use of 11r with PSKs strikes me as a somewhat 
unlikely scenario.

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 16 Nov 2007 23:19:50 -0800 (PST)

11r refused to put a 3-party protocol in their draft (well one got
voted in but then in a sneaky low-down manner they removed it). Their
position was that the IETF would define a 3 party protocol for them to
use. Their position wasn't that simple key sharing would be permitted.

  We don't change laws (like the one on drunk driving) because certain
people violate them (like Lindsey Lohan). The prohibition on key
sharing is there for a good reason; let's keep it.

  Dan.

On Fri, November 16, 2007 9:05 pm, Yoshihiro Ohba wrote:
>> Having looked over the proposed changes, I share the concern about the
>> modified language relating to key-sharing.  The new language is
>> disturbingly vague-would any key-sharing among authenticators or EAP
>> servers be acceptable, as long as the shared keys have passed through a
>> key derivation step?  Since virtually all the keys in the hierarchy were
>> derived at some point, the restriction on key-sharing would effectively
>> disappear completely under the new language.
>>
>> I would propose more restrictive changes to the language, but after
>> looking at the documents of the HOKEY group (whence, as I understand it,
>> the initiative to loosen the key-sharing language emerged), I can't for
>> the life of me see any incompatibilities between their work and the
>> current language.  Perhaps someone could articulate a clear, plausible
>> example of a case where adherence to the current language significantly
>> impedes HOKEY progress-or for that matter, progress on the design of any
>> other useful protocol standard?
>>

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 16 Nov 2007 23:39:55 -0800 (PST)

11r is restricted to modifications of the MAC and PHY. Their "key
holders" are therefore part of the MAC. Authenticators are not part
of the MAC.

  Dan.