eap Mailing List: Re: hopefully final changes for draft-ietf-eap-keying

[Bernard_Aboba (Bernard_Aboba]

Yoshi Ohba said:

> 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.

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.