eap Mailing List: RE: Re: IEEE 802.16e EAP usage modes

[Bernard Aboba (aboba]

> Just to clarify a few points -  and let Sanjay respond to the rest:
>
> 1.  MTU: 1020 bytes is always available (as EAP messages are sent on a
> connection with capability for fragmentation)
>
> 2.  Channel Binding:  802.16e includes the BSId in the derivation of the
> "Authorization Key" (AK) from the PMK.  I think that this constitutes an
> adequate channel binding.

Binding requires that all parties have the same understanding of who the
key is being derived with and for what purpose it is being used.  For EAP,
the "entities" that possess the PMK are the EAP peer, server and
authenticator.  Channel binding is a way for the peer to verify that the
authenticator has provided it with the same parameters as it provided to
the EAP server.

As I understand it, the BSId identifies a port on the authenticator, not
the authenticator itself, correct?

> 3.  Pre-emptive keying: 802.16e is only an air interface.  It relies on
> pre-emptive keying without saying how it's to be done.  But yes a RADIUS
> extension is an obvious possibility.   Similarly, 16e only uses the
> AAA-Key that it receives and doesn't tell the AAA Server how to create it.

The pre-emptive keying formula that was in -05 has been removed from the EAP Key
Management framework document to enable a more complete analysis. There
are a number of problems with pre-emptive keying that have been raised by
Jesse Walker and others.  For example, in pre-emptive keying the peer does
not know where the server has sent the keys and this can result in key cache
misses until the server's view of the world synchronizes with the peer.  Also,
pre-emptive keying does not provide for mutual authentication between the
EAP peer and server via the authenticator that will be used.  This raises the
question about whether the pre-emptive key is properly bound.

>From a AAA perspective, pre-emptive keying faces some
deployment obstacles.  RFC 3576 has not yet been widely adopted, and
requires changes to RADIUS proxies and possibly firewall configurations.
The RADIUS extension document describing pre-emptive keying was created
for the IRTF, not the IETF, so it doesn't even have the status of an IETF
individual submission, let alone a WG work item.  Given that 802.16e
is in Sponsor ballot, it would be very hard to see how a dependency
that immature could be resolved in time.

> 4. TSKs:  Traffic Encryption Keys (as we call them) are transported from
> BS to MSS wrapped in a KEK that is derived from the AK (using AES Key
> Wrap). The TEK lifetime is specified explicitly by the BS and there is
> overlap in the lifetime of successive generations of TEK.  This scheme
> was inherited from DOCSIS (why it has been retained is a different story).
>
> Additionally a TEK can expire prematurely by using up its 32bit Counter
> space.
>
> The context of a TEK is defined in a roundabout manner, but essentially
> there are potentially several sessions who are permitted to access a
> particular TEK.  These sessions are identified by an ID that is carried
> in the 802.16 MAC header.  The MAC header in turn is not protected by
> the Message Authentication Code, but is instead used in generated the
> CCM-mode initialization block.
>
> Bottom line is that the MSS must rely on the BS guaranteeing TEK
> freshness.  The TEK context is dictated by the BS to MSS and mutually
> enforced (and the AAA-Server is not in the picture at all for TEKs).

Right.  It sounds like 802.16e handles the key lifetime of transient
session keys.  Does it also negotiate the PMK key lifetime in situations
where PMK caching is supported?