On Fri, Apr 13, 2007 at 07:52:17PM -0400, Charles Clancy wrote:
Sam Hartman wrote:
The more I
read what you, Bernard and Charles say, the more I'm convinced that I
agree with your description of EAP and that my text is correct. The
more I talk, the more you're convinced that my text is wrong.
We're talking past each other somehow.
I think your text was correct, but incomplete. I think the SAP needs to
be included, as it does channel bindings under Nico's broader
definition. The SAP does an EAP lower-layer to EAP layer binding -- it
just doesn't provide the authorization you're looking for, hence why we
need EAP channel bindings to prevent the lying NAS problem.
Sam's suggested text:
My suggestion for Sam's suggested text:
The problem you call the "lying NAS problem" sounds like nothing other
than an MITM attack on the peer: the MITM pretends to be the NAS to the
peer and the peer to the real NAS, passing through any other traffic
between the peer and the server, and when all is done the lying NAS has
had access to all the plaintext that the peer might have sent to or
received from the network it connected to. This matches the generic
channel binding problem statement quite nicely.
The solution that's been described consists of: a) authentication of the
NAS to the peer at the lower layer, b) mutual authentication of the peer
and the EAP server, c) authentication of the NAS to the EAP server, d)
an authorization step where the peer sends the NAS' lower-layer ID to
the EAP server and where the EAP server decides whether the NAS that
authenticated to it is the same as that which authenticated to the
client and e) also decides whether the NAS is allowed to serve the peer.
This can be described as a use "end-point channel bindings" where the
application _knows_ that that's the type of channel binding provided by
the channel and where the end-point IDs are meaningful to the
application (the EAP server in this case).
More importantly: step (a) is difficult to arrange. How does one
authenticate BSSIDs, MAC addresses, etc.? It would be a lot simpler to
have an unauthenticated channel between the peer and the NAS and bind
that channel into the peer<->EAP server authentication. Thus "unique
channel bindings" too could be used in EAP channel binding.
Unless I misunderstood something and the above text is incorrect then I
think Sam's text is sufficient. A more detailed description of the EAP
channel binding problem and proposed solutions, and an analysis of how
that resembles the generic channel binding problem and solutions might
help. I would place such text in a sub-section of the introduction.
Finally, to address Lakshminath's comments, I would insist that all
EAP-related text in this document is and should be informative, and it
should be clearly labelled as such. If the EAP community finds this
document useful then it can choose to update RFC3748 to include this
document as a normative reference.
Ietf mailing list