Subject: RE: [eap] Strawman -10/EMSK deletion requirement?

From: "Avi Lior" <[email-masked]>
Date: Fri, 10 Mar 2006 00:16:31 -0500

Joe,

> -----Original Message-----
> From: Salowey, Joe [mailto:[email-masked]] 
> Sent: Friday, March 10, 2006 12:16 AM
> To: Avi Lior; Narayanan, Vidya; Jari Arkko
> Cc: [email-masked]
> Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
> 
>  
> 
> > -----Original Message-----
> > From: Avi Lior [mailto:[email-masked]]
> > Sent: Thursday, March 09, 2006 9:03 PM
> > To: Salowey, Joe; Narayanan, Vidya; Jari Arkko
> > Cc: [email-masked]
> > Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
> > 
> > Joe and All,
> > 
> > I totally agree with Joe.
> > 
> > AAA is a protocol that transports and cant realy cache 
> anything in the 
> > case of RADIUS which is stateless.
> > 
> > So any caching has to be outside AAA or with AAA (but 
> Diameter only). 
> 
> [Joe] I think a AAA server is typically composed of several 
> components.
> One of these can be a key holder.  I don't see why you 
> couldn't define new functionality in RADIUS to interact with 
> the key holder (other than the fact that it seems to be 
> difficult to define anything new in RADIUS). 

[Avi]  Aboslutely correct on all fronts ;-).  A AAA server can have
EAP-AS (authetncation server) and a key holder/key generator.  So I
guess ia m being very formal in the sense that AAA is a protocol and not
a server.

And BTW I don't think we need to have an RFC to define a Key Holder
function in RADIUS servers.
 
> > 
> > > -----Original Message-----
> > > From: Salowey, Joe [mailto:[email-masked]]
> > > Sent: Thursday, March 09, 2006 11:59 PM
> > > To: Narayanan, Vidya; Avi Lior; Jari Arkko
> > > Cc: [email-masked]
> > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
> > > 
> > >  
> > > 
> > > > 
> > > > I guess when you say EAP Authentication Server, it is a 
> bit vague 
> > > > about whether that is the EAP layer or AAA layer. I'm 
> not sure if 
> > > > there is value in clarifying this or if it makes more sense
> > > to leave
> > > > it to implementation.
> > > >
> > > [Joe] I'm pretty convinced it is in EAP.  In the pictures the AAA 
> > > layer appears to carry communication between AAA client and AAA 
> > > server, I do not think this is where the EMSK belongs.
> > > 
> > >  
> > > 
> > 
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Jari Arkko <[email-masked]>
Date: Fri, 10 Mar 2006 10:33:54 +0200

>function in RADIUS servers.
First of all, I think this part of the discussion is largely just
a matter of vague definitions making it hard to make exact
statements. E.g. where is the line between AAA as a
"transport" and as an "application" that has intelligence
to make decisions and grant resources such as keys?

Just to repeat what we have already established, I think
we have consensus that (a) EMSK is generated by EAP
methods and that (b) its not going to be shipped away
to the access devices. In addition, it seems obvious that
the document we are discussing will not define how AMSKs
are used or transported.

So the conclusion is that the EMSK is kept somewhere
between the EAP method and AAA transport layers.
I would note that this means that it is, in an IETF sense,
within a box and not transported via protocols. I don't
think it makes a lot of sense to debate too long about
what the internal structure of the box is. I'd be happy
saying that it resides in the EAP server. I would in
addition only say the following about the internal
module structures: The EMSK is not communicated
either to the lower layer or the AAA transport layer.
But AMSKs derived from it can be,
and that any such derivation would have to be defined
in future documents.

Finally, I dislike the idea that we would be adding
major functionality (such as key server) to IETF
protocols and mechanisms without properly
documenting how they will be used and what the
protocols will exactly carry. The role of the EAP
keying framework is to leave some key material
in the EAP server to enable such functionality,
but if we are going to use it, we will need, among
other things, protocol descriptions on how
RADIUS can retrieve pieces of this key information
and how particular applications employ these
keys.

--Jari

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 10 Mar 2006 11:15:08 -0500

Hi Jari

>to make decisions and grant resources such as keys?
I agree on you this. In my mind the AAA server (where EAP server might 
be co-located) is (or should be) intelligent enough to manage keys from 
users.

>between the EAP method and AAA transport layers.
So far, between EAP methods and AAA transpor layers (AAA server?? ) we 
have EAP authenticator layer and EAP layer. An as specified 
draft-ietf-eap-keying-10.txt both layers cannot cache anything. I think 
it does not preclude the use of EMSK but it establishes limits to the 
creation of AMSK. That is, the AMSK should be created just in the moment 
the EMSK is exported. If EMSK wants to be cached, that part of text 
should be relaxed, no?

>and that any such derivation would have to be defined
I have seen during discussions and also under my understanding of 
draft-aboba-eap-keying-extns-00.txt that either 1) AMSK would be 
tranported from AAA server to some entity or 2) AMSK could be used as a 
root and cached by the AAA server to derive new keys which would be 
eventually transported to different entities.

will that decision between both cases be specified for application? or 
would it be better to select one approach (it seems people like second one)?

Regards.

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: [email-masked]
------------------------------------------------------

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 10 Mar 2006 11:43:23 -0500

An additional comment, I have been wondering about EAP peer side and EAP 
authenticator side.

In the EAP peer side, I have some doubts:

It seems following the same that it has been discussed for EAP server, 
that EAP peer would create the same set of AMSKs than EAP server.
And then  AMSKs should be exported to lower layer correct?.  However I 
do not know if the bunch of AMSKs should be exported to the EAP lower 
layer or
to another "lower layers". Maybe I am wrong, but I was assuming each 
"application" could have different lower layers to interact with 
different "authenticators" . And (possibly) each AMSK is intended to be 
used with each different authenticator.

Additionally, I was wondering how it affects to "Mode Independence". EAP 
peer might think that EAP authenticator has MSK and AMSKs (or keys 
derived from them), is that correct?. Also , would it make sense to 
create AMSKs in case of standalone EAP authenticator?

Thanks.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 12 Mar 2006 21:28:58 +0200

Rafa Marin Lopez wrote:

> draft-ietf-eap-keying-10.txt both layers cannot cache anything. I
> think it does not preclude the use of EMSK but it establishes limits
> to the creation of AMSK. That is, the AMSK should be created just in
> the moment the EMSK is exported. If EMSK wants to be cached, that part
> of text should be relaxed, no?

I think so.

> tranported from AAA server to some entity or 2) AMSK could be used as
> a root and cached by the AAA server to derive new keys which would be

I think the practical approach would be to take one application and
specify how its done
for that. Other applications may later use the same approach or
something else, if
their requirements differ.

--Jari

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 13 Mar 2006 18:10:14 -0500

Hi Jari...

>their requirements differ.
Yes , that's good. As first example of 2), section 2.3 in 
draft-aboba-eap-keying-extns-00.txt. Maybe it would be interesting to 
start discussing from this application. But in any case,  did you have 
any other in mind?.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 14 Mar 2006 13:12:24 +0200

It seems that we have converged on this issue. Is there
anyone who would like to suggest specific text changes?

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 14 Mar 2006 22:55:32 -0500

Hi Jari

As I commented in a previous e-mail, I think this paragraph in section 
2.2 (page 14) should be relaxed if we consider EAP peer / EAP 
authenticator layer or EAP layer could be in charge of creating AMSK and 
also if we consider EMSK could be cached in those layers.

"The EAP peer and authenticator layers MUST NOT modify or cache keying
   material or parameters (including Channel Bindings) passing in either
   direction between the EAP method layer and the EAP layer.  The EAP
   layer also MUST NOT cache keying material or parameters (including
   Channel Bindings) passed to it, whether by the EAP peer/authenticator
layer, the lower layer or the AAA layer."

Additionally, that paragraph seems a bit contradictory with this in page 15.

"The EMSK is reserved for future use and MUST remain on the EAP
      peer and EAP server where it is derived; it MUST NOT be
      transported to, or shared with, additional parties, or used to
      derive any other keys.  (This restriction will be relaxed in a
      future document that specifies how the EMSK can be used.)"

Could we say ...

"The EMSK is reserved for future use and MUST remain on the EAP
      peer and EAP server where it is derived; it MUST NOT be
      transported to, or shared with, additional parties." ?