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

[Dan Harkins (dharkins]

  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.

On Fri, November 16, 2007 10:47 pm, Bernard_Aboba [at] hotmail.com wrote:
> 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.
>
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
>
> Arhives: http://lists.frascone.com/pipermail/eap
>