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. Nico -- _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf