Subject: RE: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication Using Only A Password) to Informational RFC

From: "Glen Zorn" <[email-masked]>
Date: Mon, 1 Mar 2010 07:06:31 +0700

Dorothy Stanley [mailto:[email-masked]] writes:

I am submitting one comment on draft-harkins-emu-eap-pwd :

(1)   Channel bindings are becoming increasingly necessary for new and
evolving uses of EAP. 

This point is certainly debatable, if for no other reason that the concept
of "EAP channel bindings" seems not to be well-understood, but in any case.

This EAP-PWD protocol should provide for them.

.the idea that individual EAP methods (each and every one) should be forced
to provide support for this rather amorphous capability (of questionable
utility) is absurd.  

Dorothy Stanley

------------------------

Dorothy Stanley

Aruba Networks

[email-masked]

630-363-1389

---

From: Sam Hartman <[email-masked]>
Date: Sun, 28 Feb 2010 20:58:44 -0500

Glen, I have to agree with Dorothy's comment.  This method should
provide for channel binding support.  I find your unsubstantiated
assertion that doing so wouldbe be absurd uncompelling.

You claim that channel bindings are poorly defined.  I believe that
draft-ietf-emu-chbind brings us most if not all of the way there for
some important use cases.  However if you take a look at that draft,
you'll find that it's a lot better defined for the case where an EAP
method will transport the channel binding than for the case where a
secure association protocol is used.

In particular:

1) The secure association protocol by its nature happens after the
access-accept.  I've already started a session--told the peer to go
ahead with things before channel binding can be confirmed.  It's not
clear in existing secure association protocols where the EAP server gets
to interact with the peer again in order to tell it that channel binding
verification has failed.
So, it is unclear that the primary purpose of channel binding can be
performed in this case.

2) The document does not define sufficient messaging to community with
an AAA server to perform channel binding in a secure association
protocol.

So, basically, I think for channel binding to work  it needs to be
available in the method.

Moreover, whether channel binding is critical in a given deployment is
not actually dependent on whether the methods used in that deployment.
It's dependent on whether a deployment has multiple situations where a
peer could be significantly disadvantaged by authenticating to the wrong
NAS.  So, I cannot see good criteria for deciding when to add channel
binding and when not to add channel binding to new proposed methods.

Certainly, part of this is that I'm working on an EAP deployment where
channel binding is absolutely critical to the security of the
environment.  Especially since I don't see how to actually make it work
with a secure association protocol, I'm strongly in favor of a
requirement to support channel binding in new methods.

--Sam