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

From: "Bakshi, Sanjay" <[email-masked]>
Date: Tue, 5 Apr 2005 19:30:28 -0700

Hi Bernard,
I have tried to answer your questions below as best as I can. I need to
provide more details in order to fully answer some your questions. But
one thing is apparent, 802.16e follow the eap-keying-06 upto the point
of delivery of AAA-Key to authenticator. But Security Association
Protocol is not followed fully as detailed in the eap-keying-06.

Following is more generalized version of my question that I had earlier
asked. I prefer not to get dragged into overall 802.16e security
analysis over the email at this point. The question is:

What are the issues with having multiple relaying/switching devices
between  a Peer and an Authenticator .. specifically a pass-thru
Authenticator?

Issues that come to my mind are 
   a) MTU discovery 
      For the minimum MTU of 1020 specified in RFC3748 can be used
   b) Channel Binding
      Are there any EAP methods that implement this?
      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.
      Is my understanding correct?

Appreciate answers/clarifications to these.
Thanks,
--sanjay

>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On Behalf
Of
>>Bernard Aboba
>>Sent: Monday, March 21, 2005 8:22 PM
>>To: [email-masked]
>>Subject: [eap] Re: IEEE 802.16e EAP usage modes
>>
>>The EAP Key Management Framework includes security requirements for
EAP
>>usage modes.  In particular, the "Housley Criteria" describes the
>>requirements for publication of AAA key management documents in the
IETF.
>>My advice would be to look carefully at those requirements in order to
>>understand whether 802.16e is compliant or not.

[<<sbakshi>>] The question I am asking is not related to AAA key
management but I will nevertheless check the document

>>
>>> Basically, in the context of EAP in this model BS acts as a relay
and
>>> implements two functions.
>>>
>>>  1. On uplink BS removes EAP pdus from the PKMv2 encapsulation,
>>> encapsulates them in a "to be defined" encapsulation and forwards
them
>>> to the Gateway which is a RADIUS client.
>>
>>Does the uplink BS perform any cryptographic operations on data or EAP
>>packets?  Or does it just encapsulate/decapsulate packets?

[<<sbakshi>>] It just encapsulates/decapsulates EAP packets. However,
data from application sessions is encrypted. 

>>
>>>  2. On downlink BS removes EAP pdus from a "to be defined"
>>> encapsulation, encapsulates them in PKMv2 and forwards them to the
MSS
>>
>>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?

[<<sbakshi>>] 
Main keys on MSS (peer) and BS (Authenticator)
    MSK, AAA-Key as per eap-keying-draft
    PMK derived by truncation from AAA-Key.
    AK (Authentication Key) derived from PMK using a KDF(PMK, SS ID, BS,
ID)
    Two MACs (uplink and downlink) for signing the control messages
    One or more TEK (Traffic Encryption Keys) for encrypting user
traffic.
       These are derived from randoms by the BS and sent to MSS

MSK, AAA-Key are transported as per eap-keying-draft
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.

>>> BS does not implement any Authenticator functions.
>>
>>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.

>>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. There is no Security
Association protocol defined for lifetime management etc. of the
AAA-key. 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)

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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 6 Apr 2005 03:24:58 -0700 (PDT)

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

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

> It just encapsulates/decapsulates EAP packets. However,

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

> on the BS?  On both? How are the keys transported?  How many parties
> possess them?
>

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?

> correct context?  How are authorization attributes handled?  Does this
> ensure proper cryptographic binding?
>

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

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

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

> Is this done explicitly?  What meaning is ascribed to the RADIUS
> Session-Time attribute?
>
> 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

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.

> the key cache?  Are the messages within the Secure Association protocol
> >>authenticated?

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