Subject: [EAPEXT] RE: EAP Extensions Work

From: "Walker, Jesse" <[email-masked]>
Date: Fri, 2 Jun 2006 14:56:26 -0700

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. 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.

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).

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.

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.

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.

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

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.

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

-- Jesse

> -----Original Message-----
> From: Narayanan, Vidya [mailto:[email-masked]]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/eapext

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 2 Jun 2006 17:36:56 -0700

Hi Jesse,

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

> 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
> 

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? 

> 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

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.  

> 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