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

[Jeff Mandin (jmandin]

Sanjay and Bernard hi,

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.

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. 

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

- Jeff

---------------------------------------------------

> Issues that come to my mind are
>    a) MTU discovery
>       For the minimum MTU of 1020 specified in RFC3748 can be used

EAP can't do MTU discovery, per se.  Are you saying that a minimum MTU of
1020 is always available?

>    b) Channel Binding
>       Are there any EAP methods that implement this?

Yes, there are methods that are capable of this.  The EAP peer and server
verify that the "authenticator" they see is offering the same information
to each of them.  For example:

Authenticator MAC address as seen by peer = Called-Station-ID in
                                           Access-Request
SSID as seen by peer                      = SSID in Access-Request
NAS-Identifer as seen by peer             = NAS-Identifier in Request

> It is not clear to me how Channel Binding is implemented when pass-
> thru authenticator is in use. This because the Channel (lower
> layer) between peer and pass-thru authenticator is different from the
> lower layer between pass-thru authenticator and AAA backend that execute
> the EAP method.

I'm not sure why this would affect Channel bindings.

> Does the uplink BS perform any cryptographic operations on data or EAP
> packets?  Or does it just encapsulate/decapsulate packets?
>
> It just encapsulates/decapsulates EAP packets. However,
> data from application sessions is encrypted.

Presumably this occurs after the EAP conversation completes, no?  So the
EAP conversation itself is never encrypted, even in a re-authentication?

>Where are cryptographic keys stored in this architecture?  On the MSS?
> on the BS?  On both? How are the keys transported?  How many parties
> possess them?
>
> Main keys on MSS (peer) and BS (Authenticator)
>     MSK, AAA-Key as per eap-keying-draft

The liaison letter from Roger Marks indicated that the AAA-Key was derived
from the AMSK/EMSK via the "pre-emptive handoff" formula, rather than from
the MSK.  Is this coreect?

> MSK, AAA-Key are transported as per eap-keying-draft

Again, Roger's seemed to imply that the RADIUS pre-emptive keying
extension was used within 802.16e.  Is that right?

> PMK, AK, MACs are derived by peer and authenticator independently

> How are transient session keys derived?  How are they bound to the
> correct context?  How are authorization attributes handled?  Does this
> ensure proper cryptographic binding?
>
> [<<sbakshi>>] These are defined in 802.16 specs. If people are
> interested in getting an update on that, I will be glad to provide
> material for that.

Yes, we'd like to understand whether the requirements relating to TSK
freshness are being fulfilled.

> How do the parties identify themselves within the IEEE 802.16e
> exchanges? If the BS is not an authenticator, then the EAP peer cannot
> be aware of its identity;  that is, the BS must appear to be a port of
> the MSS, and the EAP peer can only be aware of the MSS identity in the
> layer below EAP. Is this how 802.16e works?
> >>
> [<<sbakshi>>] Assuming I understood your question correctly. Upon
> successful network entry (at PHY and MAC layer), MSS gets a connection
> identifier that represent the connection to the BS and eap packet are
> exchanged over this connection. So in my opinion for forwarding EAP
> packets, BS does appear as a port to EAP-peer.

If the BS appears as a port to the MSS, is the EAP peer aware of what MSS
it is connecting to?  This relates to whether the EAP peer and server are
in sync with respect to the Key Scope (the context of the key that is
being derived).

> How does IEEE 802.16e negotiate the key lifetime of the MSK and TSKs?
> Is this done explicitly?  What meaning is ascribed to the RADIUS
> Session-Time attribute?
>
> [<<sbakshi>>] Lifetime of MSK (derived from the eap session) is expected
> to be exchange by RADIUS Session-Time attribute.

The Session-Time attribute represents the maximum time to
re-authentication of a session-in-progress.  It isn't clear that this is
the right attribute to use to determine the lifetime of the AAA-Key in
pre-authentication, for example.

> There is no Security Association protocol defined for lifetime
> management etc. of the AAA-key.

Does 802.16e support pre-authentication?  If so, how does the peer and
authenticator know how long the AAA-Key lives after being derived?

> IMO equivalent to TSKs, 802.16e has TEKs (Traffic Encryption
> Key) but 802.16e's current key derivation of TEKs does not follow the
> guidelines mentioned in 1.3.3 of eap-keying-06. TEKs are derived as
> randoms by BS and send to MSS encrypted and signed by keys derived from
> PMK(AAA-Key)

The keying draft doesn't require a certain derivation for the TSKs, it
merely requires that they be fresh.  Derivation of TSKs via two
nonce/counters (one for each side) means that freshness can be provided
even if one party has a broken random number generator.  Deriving a TSK
from a Nonce provided by only one party (particularly if that party is an
embedded device that may lack the required boot entropy) seems risky, no?

In particular, one can no longer say that TSKs freshness is guaranteed if
the EAP method generates a fresh AAA-Key and if the peer can generate
Nonces/counters that are fresh (as one can do in 802.11i, for example).
In existing usage, freshness can be provided even if the EAP server
generates unfresh Nonces/counters since the EAP method includes
nonces/counters from both sides.  Similarly, if the method exported keys
are fresh and the EAP peer generates a fresh nonce/counter then the
authenticator nonce/counter need not be fresh for the freshness
requirement to be met.

> How are keys named in IEEE 802.16e?  How do the parties synchronize
> the key cache?  Are the messages within the Secure Association protocol
> >>authenticated?
> [<<sbakshi>>] 802.16e does not define anything analogous to Secure
> Association protocol. Validity of AAA-Key in Authenticator and MSS is
> assumed. There is a 3-way handshake to verify the liveliness of the
> session key namely (AK) that is derived from AAA-key

The 3-way handshake sounds like a Secure Association Protocol, as defined
in the keying framework.  For example, it appears that it provides for
mutual authentication between the peer and authenticator (one of the
Housley criteria), as well as potentially providing for key freshness.

What other functions does the 3-way handshake provide?  For example:

* Secure confirmation of ciphersuites (another required property)
* TSK lifetime determination (e.g. can the 3-way handshake be used for
 a TSK rekey by either side?)
* Proper identification (e.g. are the parties identified, not merely
 their ports?)
* Is the key properly bound to its context?  This includes not only
 use of the appropriate identifiers in the 3-way handshake, but
 but also ability to verify channel bindings.

- Show quoted text -