[EAPEXT] RE: EAP Extensions Work

["Narayanan, Vidya" <[e-mail]>]

Hi Jesse,

Thank you very much for providing comments. Some comments/questions
inline. 

> 
> Vidya,
> 
> As per your request, here are some comments on the EAPEXT charter:
> 
> 1. The second paragraph begins:
> 
> 	...for fast EAP re-authentication...
> 
> Is there a better word than "fast?" When the server is 
> remote, there may be nothing fast about the operation. 

It was meant to be a relative term, really - it is true that server
being remote introduces some delay - however, the full EAP exchange is
too time consuming - so, in comparison with that, this is a faster
process. So, I guess it goes to the definition of "fast" being
subjective :) We will clarify what we really mean here. Also, the goal
really is to allow this process to even be triggered ahead of time (like
pre-authentication). 

> And is 
> it really re-authentication?
> In all of the designs I am aware of, the MSK and EMSK are 
> ephemeral state used for authorization, not authentication; 
> this ephemeral state used for authorization is a by-product 
> of authentication. I would be happy with
> 
> 	...for reauthorization...
> 
> instead. I would make the same kind of change throughout the charter.
> 

Yes and no, actually. When the peer first performs the full EAP
exchange, it is authenticated by the server (using the long term
credential, for e.g.) and the MSK/EMSK are derived. The MSK provides
proof to the authenticator that the peer is *authorized* for network
access. In this sceanario itself, what you said is true that the MSK is
used for authorization. Now, consider a key derived from the EMSK that
the peer later uses to provide proof of possession to the server - that
is still authentication. It is just that it doesn't go back to using the
long term credential to provide this proof - hence, it avoids having to
execute the EAP method again, leading to faster operation. As a result
of this subsequent authentication, a key will be handed out to the new
authenticator, the key potentially being derived also from the EMSK. 

Does that make sense? 


> 2. The second paragraph concludes with:
> 
> 	Channel binding ensures that the peer and the server have the
> same 	understanding about the network access server (NAS), including
> its
> 	identity, advertised capabilities and services.
> 
> This has zero utility from a security perspective. The peer 
> has no knowledge that the NAS is valid, but EAP provides it 
> with a security relationship with the server. Similarly, the 
> NAS has no knowledge that the peer is valid, but EAP presumes 
> a security relationship between the NAS and the server. The 
> one and only party in any position to attest to the NAS that 
> the peer is valid is the server. Similarly, the one and only 
> party that is in any position to vouch for the identity of 
> the NAS to the peer is the server. So, this should read:
> 
> 	Channel binding will be (re)defined to allow the server 
> to attest to
> 	the peer identity to the NAS and to the NAS identity to 
> the peer, plus
> 	(pick your favorite attributes here).
> 

I agree with the above. Actually, what you said was exactly what was
intended to be said - as a result of that attestation by the server, the
peer and the server now have a common understanding of the NAS identity.
But, re-wording as you say is fine with me. 

> People are likely to push back and say something like "No, 
> Jesse, you don't understand. The NAS can be in a foreign 
> domain and unknown to the NAS." In response I will say that 
> no security relationship between the NAS and the peer is 
> possible in such a case, because, since the server is 
> explicitly assumed to not know anything about security 
> posture of the NAS, it has absolutely no business 
> distributing a key based on the peer's EMSK to the NAS. 
> Distributing one of the peer's keys to the NAS presupposes a 
> relationship between the NAS and the server that assures the 
> server that the NAS is controlled by a known good guy instead 
> of by Hackers-R-Us, i.e., that exposure of the peer's key to 
> the NAS does not compromise the key. It also presupposes a 
> channel between the NAS and the server that will not expose 
> the key to any other party. People will complain about the 
> word "any," but their complaint does not change the 
> assumption made by EAP.
> 

I more or less agree with the above - in the view of EAP, the NAS and
the server must have a security relationship. Now, AAA extends that to a
hop-by-hop security model, by introducing proxies along the way. That is
an accepted model today and is essential for practical deployment. This
hop-by-hop model of AAA may have an impact on how channel binding is
actually achieved and that requires a lot more discussion.  

> There is an implication here that "defining and scoping 
> channel binding as defined in the EAP keying framework" may 
> not be the correct goal. If channel bindings is defined to 
> support attestation by the server of the peer and the NAS 
> identities to the NAS and the peer, then this is indeed 
> correct. If channel bindings is not defined to support 
> attestation of the NAS and peer identities to the peer and 
> NAS, then it might be better to write "defining or extending 
> channel binding as defined in the EAP keying framework." I 
> think more discussion will be necessary to understand whether 
> the channel bindings concept support the attestation needs, 
> so the charter should not preclude the working group from 
> doing work required to make security work.
> 

We'll re-word to clarify this. But, I do believe that a lot more
discussion needs to happen before we know how to best do channel binding
(and whether it even buys anything). The purpose of including channel
binding in the charter is strictly to define it; any solutions, if
needed, will come after re-chartering.  

> 3. Bullet 2 of the charter says
> 
> 	Specification of EMSK usage. This specification will define the
> 	derivation of root keys from the EMSK for specific purposes.
> 
> Since it is infeasible (and undesirable) to specify every 
> possible usage, what is meant is probably more along the lines of
> 
> 	Specification of rules governing EMSK usage. This 
> specification will
> 	define guidelines governing the derivation of keys from 
> the EMSK for
>       specific applications.
> 

The specification is actually intended to be a framework for
EMSK-derived keys. How about this - "Specification of rules govering
EMSK usage. This specification will provide a framework for the
derivation of root keys from the EMSK for specific purposes."

> And why is Bullet 3 different from Bullet 2? Maybe I don't 
> understand what Bullet 2 is really about.
>

Perhaps this will clarify - "An informational document with a template
on how to write specifications on the derivation and the distribution of
keys from the root keys of the EMSK hierachy." Please note that Bullet 2
refers to the derivation of the first level keys (called root keys) from
the EMSK, while Bullet 3 talks about providing guidelines for key
derivations thereof.  
 
> 4. Bullet 4 of the charter is a complete mystery to me. This 
> Bullet alludes to three applications of the EMSK derivation, 
> but does not provide even a summary motivation as to why 
> these are important applications to consume the other work or 
> why the EAPEXT Working Group is the appropriate home for this 
> work. Yes, you're right; I should read the motivation 
> document, but I think that experience amply shows there is a 
> problem if the motivation for doing work is not immediately 
> obvious from the charter. It is not at all evident why any of 
> these three applications should fall within this group.
> 

Yes, the motivation does discuss the need for this work. To summarize -
the EMSK is likely to be used for disparate purposes. Hence, the goal is
to derive a root key (called usage specific root key) for each specific
purpose from the EMSK. We have identified three usages that need to be
currently addressed - fast
re-authentication (pending terminology agreement :)), access to one or
more home network services and access to one or more visited network
services. 

> Hopefully some of this will be helpful to you. Thanks.
> 

Yes, and thanks again. 

Regards,
Vidya

> -- Jesse
> 
> > -----Original Message-----
> > From: Narayanan, Vidya [mailto:[e-mail]]
> > Sent: Thursday, June 01, 2006 9:48 PM
> > To: Blumenthal, Uri; Walker, Jesse; Iyer, Prakash
> > Cc: Dondeti, Lakshminath
> > Subject: EAP Extensions Work
> > 
> > Jesse, Prakash, Uri,
> > You may have seen the email that we had sent out on the 
> creation of a 
> > mailing list to discuss next steps on EAP keying (on the 
> IETF mailing 
> > list). We would very much like to get your input on the charter that
> we
> > have put together as next steps in this space. We would greatly 
> > appreciate if you could share your thoughts on the list so 
> that we can 
> > have some technical decisions with input from people 
> knowledgeable in 
> > this space.
> > 
> > You can subsrcibe to the list via
> > https://www1.ietf.org/mailman/listinfo/eapext.
> > 
> > The charter and motivation can be found at:
> > 
> > http://www.geocities.com/hellovidya/EAPExt_charter.txt
> > http://www.geocities.com/hellovidya/EAPExt_motivation.txt
> > 
> > Thanks in advance for taking the time to provide any comments.
> > 
> > Regards,
> > Vidya
> 

_______________________________________________
EAPEXT mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/eapext