Subject: RE: [eap] WGLC for eap-keying: EAP server-AAA server

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Fri, 28 Oct 2005 12:37:02 -0400

Hi,

I started reading the V08 draft and having the hindsight of some very
recent issues we are dealing with in other SDOs, I have some comments on
what I have read so far (the first 6 pages :) )

***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"

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.
Here instead we may say that "the backend authentication server
typically includes EAP server functionality". The way it is, the text is
adding EAP server function to the backend authentication server
definition.

***MSK and EMSK definitions talk about export. RFC 3748 terminology does
not include "export", so it is not clear what export means. I typically
take it as EAP server passing something to the AAA server (or backend
authentication server) or lower layer as it has been called recently. I
think this is an important concept that needs to be clarified before
this document is considered complete.

***PMK definition should be generic, Example: Pair wise master key is a
key that is shared by the peer and the authenticator as a base line key
to derive session keys that protect data between the peer and the
authenticator. The current text is an example on how 802.11 does it and
should go in an appendix somewhere, it is not a definition.

***TEK and TSK both use the word "session keys" as the start of the
definition, whereas the mean completely different "session" (if you
will). One is really about the "EAP session" or exchange between peer
and server, and the other about the peer-authenticator. May be call one
authentication session and the other link session keys??? (I know not a
good suggestion, but honestly it is not worse than what is there
already)

***AAA key
It says that the key "is derived by the peer and EAP server, ...
The AAA key is transported from the backend authentication server to the
authenticator.."
How did the key end up in the AAA server (remember "backend
authentication server" being synonymous with AAA server?)?
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? 

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

Thanks, and regards,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jari Arkko
Sent: Thursday, October 27, 2005 3:01 AM
To: [email-masked]
Cc: Bernard Aboba
Subject: [eap] WGLC for eap-keying

This is a Working Group Last Call announcement for
draft-ietf-eap-keying-08.txt which is now available at:

  http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-08.txt

This last call ends on Nov 30th, 2005 (longer than usual to accommodate
for IETF and IEEE meetings and leave time for detailed security review).

Please review this document and post your comments to the EAP WG mailing
list.

Jari Arkko
Bernard Aboba
EAP WG co-chairs

_______________________________________________
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: "Glen Zorn (gwz)" <[email-masked]>
Date: Fri, 28 Oct 2005 11:33:44 -0700

Nakhjiri Madjid-MNAKHJI1 <> supposedly scribbled:

> recent issues we are dealing with in other SDOs, I have some comments
> on what I have read so far (the first 6 pages :) )  
> 
> 
> ***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"   

Except that that would be technically incorrect.  
  
>      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].
> 
> typically includes EAP server functionality". The way it is, the text
> is adding EAP server function to the backend authentication server
> definition.   
> 
> ***MSK and EMSK definitions talk about export. RFC 3748 terminology
> does not include "export", so it is not clear what export means. I
> typically take it as EAP server passing something to the AAA server
> (or backend authentication server) or lower layer as it has been
> called recently. I think this is an important concept that needs to
> be clarified before this document is considered complete.     
> 
> ***PMK definition should be generic, Example: Pair wise master key is
> a key that is shared by the peer and the authenticator as a base line
> key to derive session keys that protect data between the peer and the
> authenticator. The current text is an example on how 802.11 does it
> and should go in an appendix somewhere, it is not a definition.    
> 
> and server, and the other about the peer-authenticator. May be call
> one authentication session and the other link session keys??? (I know
> not a good suggestion, but honestly it is not worse than what is
> there already)     
> 
> ***AAA key
> The AAA key is transported from the backend authentication server to
> the authenticator.." 

Good question.

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

Sure is, IMHO.  Some people seem to believe that EAP is an authorization protocol, however.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jari Arkko 
> This last call ends on Nov 30th, 2005 (longer than usual to
> accommodate for IETF and IEEE meetings and leave time for detailed
> security review).  
> 
> Please review this document and post your comments to the EAP WG
> mailing list. 
> 
> Jari Arkko
> Bernard Aboba
> EAP WG co-chairs
> 

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Fri, 28 Oct 2005 14:53:02 -0400

Hi Glen,

Exactly, I get a sarcasm overflow sometimes :)
 
Madjid

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

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Mon, 31 Oct 2005 12:01:22 -0500

Hi Bernard,

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

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

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

>      authentication service to an authenticator.  When used, this
server
> 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. 

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

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

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

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