eap Mailing List: RE: Authenticator versus AAA client

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Hi Jari,

Finally, I got around to look at this response more closely ;) 
I look at figure 4 in the draft and I like to use the figure for
separation of authenticator and AAA client.
The way I see it. The keys (those that can be transported) come down
from EAP server to AAA server, from AAA server over to AAA client (over
AAA protocol) and then up to Authenticator (EAP Auth layer). 


        peer                    EAP pass-thru Auth              EAP
server
                                PMK<----        ^
|
                                |               |
| MSK
                 SAP                            |       MSK
V 
                <------>        L2      AAA client<------------ AAA
server

I am guessing keys flow upward from AAA layer to authenticator layer
(AAA client to pass through authenticator), because, the pass-through
authenticator needs to create master keys for SAP between the itself and
the peer??
                
The current text requires "In order to prevent the compromise of
transported EAP keying material and parameters, the AAA client and EAP
authenticator MUST be co-resident."     

 I am trying to figure out why this text limits the usage to collocated
AAA client and EAP authenticator. Sure there may be some identifier
issues between AAA client ID and authenticator ID (I am wondering if
they have to be resolved by requiring co-residency), but what if I want
the keys to be sent to another AAA client (a key holder) that is not
acting as EAP authenticator. 

People have brought up 802.11r in previous discussion and mentioned that
the key holder there is an authenticator. I personally think that was a
result of the very same requirement.

Again, why is there a restriction that it has to be an EAP pass-through
authenticator that gets the master keys (MSK/AMSK). Also, is there a
restriction that EAP pass-through must hold master keys (such PMK) for
SAP and generates TSKs?

Thanks, and sorry for bringing this up again.

Madjid
-----Original Message-----
From: Jari Arkko [mailto:jari.arkko [at] piuha.net] 
Sent: Tuesday, December 13, 2005 7:43 AM
To: Nakhjiri Madjid-MNAKHJI1
Cc: eap [at] frascone.com; Mohan.Parthasarathy [at] nokia.com
Subject: Re: [eap] Authenticator versus AAA client

Nakhjiri Madjid-MNAKHJI1 wrote:

> 
>Hi folks,
>
>We are struggling to understand the true definition of EAP pass-through

>authenticator and how it differs from a AAA client. So here are some 
>functions that we have in mind, we are trying to understand what 
>function fits where:
>
>
>AAA client functionality:
>Run AAA protocol with AAA server.
>Receive authorization info  from AAA server
>
>EAP pass-through Authenticator
>Understand EAP success/ failure, but not EAP request/ responses.
>
>
>Things we need but not sure where to fit? Authenticator or AAA client?
>Converting EAP/link layer to EAP/AAA? 
>Receiving master keys from AAA server? Yes, EAP keying defines this as 
>authenticator, but it would seem that this is AAA client, since keys 
>are sent over AAA protocol.
>  
>
This is what the EAP keying framework says:

... On EAP
server, keying material requested by and passed down to the AAA layer
may be replicated to the AAA layer on the authenticator. On the
authenticator, the AAA layer may provide the replicated keying material
to the lower layer over which the EAP authentication conversation took
place. This enables "mode independence" to be maintained.

As illustrated in Figure 4, a AAA client receiving transported EAP
keying material and parameters passes them to the EAP authenticator and
EAP layers, which then provide them to the authenticator lower layer
using the same mechanisms that would be used if the EAP peer and
authenticator were conducting a stand-alone conversation. The resulting
key state in the lower layer is indistinguishable between the standalone
and pass-through cases, as required by the principle of mode
independence. In order to prevent the compromise of transported EAP
keying material and parameters, the AAA client and EAP authenticator
MUST be co-resident.

Hope this helps -- let us know if you want some specific clarification
to the text.

--Jari