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

[Jari Arkko (jari.arkko]

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