[EAPEXT] RE: EAP Extensions Work

["Walker, Jesse" <[e-mail]>]

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