Subject: RE: [eap] Re: IEEE 802.16e EAP usage modes

From: Jeff Mandin <[email-masked]>
Date: Wed, 06 Apr 2005 18:42:45 +0200

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 -

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 6 Apr 2005 21:54:18 -0700 (PDT)

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

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

> 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?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap