Subject: RE: [eap] The end of the keying hierarchy...

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 24 Oct 2005 14:43:11 -0700

> Joe said:
> 
> "My concern with the above is that you may not want all of 
> the authenticator to have access to the EMSK.  You would 
> probably want it to remain with the part of the authenticator 
> that hosts the EAP server."
> 
> In the case where EAP runs standalone, the EAP authenticator 
> *is* the EAP server.  In the case of passthrough, the EAP 
> authenticator doesn't host the EAP server, although it is 
> co-resident with the AAA client.  So I guess I'm not 
> understanding your comment.
> 

[Joe] I look at the EAP-server as being a logical part of the EAP
Authenticator. I am concerned about the EMSK leaving the AAA in the case
where the EAP Server is in a different device that hosts the EAP
Authenticator interface with the lower layer. 

> Maybe this has to do with the flow of keying 
> material/attributes in the standalone case?  In order to 
> preserve mode independence, I think that the keying material 
> needs to be processed the same way it would be if EAP were 
> being run standalone.
> 
[Joe] The EMSK should stay within the EAP server. 

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 24 Oct 2005 14:47:39 -0700

If we want to shoe the termination of the EMSK hierarchy in the lower
layer then we need to deal with the AMSK as Jari states. I think we do
have enough detail about this that we can easily describe this.  We will
have to leave certain interfaces out of scope of this document. I could
be happy with this approach. 

Joe

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Sunday, October 23, 2005 9:36 AM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Re: [eap] The end of the keying hierarchy...
> 
> Hi Bernard,
> 
> > Jari Arkko said:
> >
> > "My e-mail was a response to the discussion you and Joe had about 
> > Joe's comments to 2.6. I agree that we want to keep eap-keying as 
> > small as possible. But I think the practical alternatives 
> are saying 
> > that the key hierarchy ends at EMSK (and leave rest of 
> keying-extns) 
> > or that the hieararchy ends at AMSK (and leave all applications of 
> > AMSKs to keying-extns). I'd prefer the latter, but I could be 
> > persuaded to go for the former, too."
> >
> > The EAP key hierarchy "ends" with the keying material passed to the 
> > lower layer.  One attraction of passing the
> 
> (I think there's still a distinction between ending as far as 
> EAP is concerned vs.
> EAP keying framework document is concered. We do need talk 
> about the use of keys beyond the EAP layer to have a system 
> level analysis. But I'm reading on...)
> 
> > EMSK to the lower layer is that this implies that the 
> calculation of 
> > AMSKs is purely a lower layer issue, and not something that the EAP
> > layer needs to be concerned about.   However, allowing the 
> EMSK to be 
> > passed to the lower layer in some circumstances 
> (stand-alone) but not 
> > in others (pass-through) violates the principle of Mode 
> independence, 
> > so I don't think we can allow this.
> 
> Yes.
> 
> > Of course, the transformation of the Method-ID => 
> Session-ID and EMSK 
> > => AMSK within the EAP layer does imply functionality 
> within the EAP 
> > layer that is not envisaged in RFC 3748, so we need to 
> think this over 
> > a bit.
> 
> Well, its really simple in theory. EMSK goes to entity X, 
> which is in charge of handing it to different apps as AMSKs. 
> Here "X" can not be "lower layer", because that would imply 
> either that we send EMSK too liberally or that we treat lower 
> layers differently (e.g., AAA server side and 802.11). But 
> "X" could still be "EAP layer" which would imply additional 
> functionality, or a new entity "EMSK manager", which is not 
> the existing EAP layer nor is it the existing lower layer.
> 
> > Essentially we are saying that the EAP layer is shielding 
> EAP methods 
> > from writing into each other's Session-ID space, guarding against 
> > compromise of the EMSK by lower layers, and in general becoming 
> > something of a "security policeman" for EAP.
> 
> Yes. But lets not make this too generic. The specific needs 
> that we have are:
> 
> (1) Do not reveal EMSK to anyone.
> (2) Reveal specific AMSKs to only those that have the right to
>      get it, with "reveal" and "right" being defined in 
> future documents.
> (3) Avoid collisions for the EMSK ID keyspace. (MSK keyid space
>      isn't used today, and is unlikely to be used in the future if
>      we can sort out how EMSK is used, so it seems unnecessary
>      to guard it.)
> 
> > Joe said:
> >
> > "My concern with the above is that you may not want all of the 
> > authenticator to have access to the EMSK.  You would 
> probably want it 
> > to remain with the part of the authenticator that hosts the 
> EAP server."
> >
> > In the case where EAP runs standalone, the EAP 
> authenticator *is* the 
> > EAP server.  In the case of passthrough, the EAP 
> authenticator doesn't 
> > host the EAP server, although it is co-resident with the AAA client.
> > So I guess I'm not understanding your comment.
> >
> > Maybe this has to do with the flow of keying material/attributes in 
> > the standalone case?  In order to preserve mode 
> independence, I think 
> > that the keying material needs to be processed the same way 
> it would 
> > be if EAP were being run standalone.
> 
> All existing key material is treated the same way. The 
> treatment of EMSK and AMSK is something that we can fully 
> understand only if we understand the whole system and its 
> requirements. For instance, one view of how EMSK could be 
> used is that its a value determined by the EAP server, which 
> can be later requested to be used as a basis for a specific 
> AMSK. For instance, if a standalone case there could be, say, 
> a lower layer qos operation that requests a qos AMSK. 
> Similarly, in the passthrough case the qos operation would 
> request AAA to give the NAS a qos AMSK. The AAA lower layer 
> would then request this from the EAP server at the server end.
> 
> This would be very similar to what we have now: EAP delivers 
> MSK, but in some cases that delivery is indirect through AAA.
> 
> Given that we do not want to send EMSK to everyone, I think 
> we have very small number of real choices here. We can debate 
> what the name of the entity is that holds EMSK, but its not 
> given to the lower layer as defined now. The lower layer as 
> defined now (either AAA or 802.11) on the other hand can be 
> used to make AMSK requests. And that second part is out of 
> the scope of our document, so I think we would be fine by 
> saying that the EMSK ends up in X (maybe EAP layer) and that 
> it will be responsible for AMSK derivation and request 
> processing in a tbd manner.
> 
> --Jari
>