eap Mailing List: RE: The end of the keying hierarchy...

[Salowey, Joe (jsalowey]

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:jari.arkko [at] piuha.net] 
> Sent: Sunday, October 23, 2005 9:36 AM
> To: Bernard Aboba
> Cc: eap [at] frascone.com
> 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
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>