eap Mailing List: RE: WGLC for eap-keying: EAP server-AAA server

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Hi Bernard,

Thank you for your email. Please see my comments below.

-----Original Message-----
From: Bernard Aboba [mailto:aboba [at] internaut.com] 
Sent: Friday, October 28, 2005 4:04 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: Jari Arkko; eap [at] frascone.com
Subject: RE: [eap] WGLC for eap-keying: EAP server-AAA server

> ***I think the terminology section needs some more clarification on 
> the distinction of a backend authentication server/AAA server and EAP 
> server, given that the draft says: "the terms "AAA server" and 
> "backend authentication server" are used interchangeably." Honestly, I

> think the draft might as well say "the terms AAA server, EAP sever and

> backend authentication server are used interchangeably"

The term "EAP server" is not necessarily synonymous with "AAA server".  
Remember, in the "stand alone" case the EAP server is the EAP
authenticator.  

Madjid>>I was merely trying sarcasm:) That is exactly my point: I think
we need to be very clear on the logical functions of EAP server and AAA
server and their distinctions. 
I think this draft is a specification on EAP. Hence it needs to be very
specific on functionality of an EAP server and clear whenever a part of
specification is really a requirement for a AAA server imposed by the
keying EAP framework for a AAA server, not a requirement for the EAP
server. Saying that "the terms "AAA server" and "backend authentication
server" are used interchangeably and then putting an EAP server function
into the definition of the backend authentication server (such as "When
used, this server typically executes EAP methods for the
authenticator.") really does not follow that spirit.   If "backend
authentication server" and AAA server are synonymous, then that sentence
needs to be removed and placed under definition of EAP server.


However, I do think it would be useful to use a single term for the
"backend authentication server". 

Madjid>> I am mostly interested in a consistent and tight spec, given
that there are several EAP-related drafts and RFCs that are trying so
delicately to balance each other.

> Backend authentication server
>       A backend authentication server is an entity that provides an
>      authentication service to an authenticator.  When used, this
server
>      typically executes EAP methods for the authenticator.  This
>      terminology is also used in [IEEE-802.1X].
> 
> I think the definition of "this server typically executes EAP methods 
> for the authenticator" should be added to the definition of EAP
server.

This is the definition from RFC 3748 and [IEEE 802.1X] so changing could
introduce confusion. 

Madjid>> So? We are not violating 3748, are we? I am simply striving
more clearance on a spec that has and will have a large audience. We are
struggling with these issues with WiMAX on daily basis. I am not just
trying to be pedantic.
If RFC 3748 is confusing on AAA server-EAP server distinction, then we
should not repeat it. BTW, there are plenty of RFCs that has been
deprecated many times. Mobile IPv4 is one example. Can't see why
clarifying a definition will hurt. 

> ***MSK and EMSK definitions talk about export. RFC 3748 terminology 
> does not include "export", so it is not clear what export means.

The definitions are copied from [RFC3748] without modification.  Note
that [RFC3748] does include the term "export".  See Section 1.2: 

   Master Session Key (MSK)
      Keying material that is derived between the EAP peer and server
      and exported by the EAP method.  The MSK is at least 64 octets in
      length.  In existing implementations, a AAA server acting as an
      EAP server transports the MSK to the authenticator.

Madjid>>Given that the definition "assumes" AAA server is the same as
EAP server, I cannot see what the importing entity is. This is another
place where separating EAP server and AAA server function would help.
Given that the current specs give so many 802.11 examples, I don't see
how an example of what "export" mean would hurt, I am guessing the
general definition of export is that the EAP method/ server and peer
will allow another layer (such as AAA layer) to see the keys, so why not
provide an example.

   Extended Master Session Key (EMSK)
      Additional keying material derived between the EAP client and
      server that is exported by the EAP method.  The EMSK is at least
      64 octets in length.  The EMSK is not shared with the
      authenticator or any other third party.  The EMSK is reserved for
      future uses that are not defined yet.



> ***PMK definition should be generic.

The term "PMK" was originally defined in IEEE 802.11 and is not used in
[RFC3748].  Given this, I'm not clear that it would be appropriate to
redefine it in this document.  As far as I can tell, everywhere the term
"PMK" is used in both IEEE 802.11 and 802.16, it is equivalent to
MSK(0,31). 

Madjid>> 802.16 D10 has already graduated to at least two PMKs:

1) EIK | PMK =truncate (MSK, 320)
2) PMK2= truncate (MSK, 160)

So I think a more generic definition of PMK is apt, that is IF a
definition of PMK would really add value to this draft (rather than
creating confusion). I personally think, if AMSK went to the extension
draft, so should PMK.

> ***TEK and TSK both use the word "session keys" as the start of the 
> definition, whereas the mean completely different "session" (if you 
> will).

It would probably help to make it clear that TEKs relate to the EAP
conversation and TSKs relate to data.  I think that this may have been
described in some of the material that was removed. 

Madjid>>The draft does have a "session ID" for EAP, so why not use it
when providing clarification?

> Given that EAP methods produce MSK and EMSK and export (presumably to 
> the AAA server), it is probably the AAA server that creates the 
> AAA-key out of the MSK and send it over? Specially given that we say 
> EAP server dumps the MSK after export? Does it dump the MSK and keep 
> the AAA key then? Do we want to leave this to interpretation?

In -08 the term "AAA-Key" is used only once, within the definition.  
Several commenters had felt that the term was confusing, so that it has
been removed.  Perhaps it might be clearer if the following definition
were used instead:

AAA-Key
     The term "AAA-Key" is synonymous with MSK.  

Given the above definition, the lower layer does not "create" the
AAA-Key; it is passed down to it from the EAP Method.  There has been
some discussion as to whether the lower layer "creates" AMSKs after
receiving the EMSK from the EAP layer, or whether the EAP layer keeps
the EMSK secret from the lower layer and calculates AMSKs from the EMSK
based on a request from the lower layer. 

Madjid>>Given that the concept of AMSK seems so powerful and easy to
grasp, but I am not clear why it has to be created from EMSK, not MSK
(can the lower layer cache the AMSK?)
My personal confusion aside, it feels that AAA-key is here only for
historical reason. Once you are completed the daunting task (may be a
timely thing given that this is Oct 30 :) ) of understanding the key
hierarchy of an EAP method and then SAP and all that, you then have to
try to justify why another key that is btw synonymous with MSK is
needed? And BTW what does "synonymous" mean with respective to RFC
2119?? Is every MUST for MSK, a MUST for AAA-key, and so forth??

> "The EAP server also decides whether access to some service should be 
> granted"??? Isn't this the job of AAA server?

The actual quotation is:

   The EAP server also
   stores the peer's identity and/or other information necessary to
   decide whether access to some service should be granted.

So yes, the AAA server makes the decision, but the EAP server stores the
information. 

Madjid>>Well, the quotation sounds like it IS the EAP server that makes
the decision. Even if we disagree on the rhetoric bases, I don't quite
understand the reasoning and the implication here. What sort of
information are we talking about? and why would EAP server store it?
Given that the EAP server does not even save MSK?