Hi Alan, My heartburn over the "MUST tranport the username and password" text is that it seems to be mandating some particular deployment and not mandating functionality. The introductory text talks about cases where the authentication server does not have cleartext access to, or a consistent transform of, the password. If the authentication server doesn't have cleartext access or a consistent transform of the password then what does requiring that the tunnel method transport the username and password to it solve? This requirement just seems to say that the tunnel method must be implemented in a way that it can separate the tunnel establishment stuff from the password authentication stuff and that is not a functional requirement.
If the requirement is that the tunnel method MUST support username and password authentication where the authentication server doesn't have cleartext access to, or a consistent transform of, the password then why not just say it directly? You have added a "That is," as an introduction to my suggested text which implies that it's just a restatement of the previous text; it isn't. The existing text says the tunnel method "MUST NOT expose the username and password to parties in the communication path between the peer and the EAP server...." As I said, exposing password-derived data is a way to comply with this requirement but it is flawed and insecure. That text also doesn't state anything about protecting the username and password when it's transporting it to the authentication server (which come to think of it is quite odd). My text does. I think it is better to just state what property we want in a tunnel method without ambiguity. I think my suggested replacement text is better than your compromise. Dan. On Wed, December 2, 2009 2:48 am, Alan DeKok wrote: > Dan Harkins wrote: >> Yes, I can propose a specific modification. In fact, I did already. > > It wasn't clear that the text was the suggested replacement. > >> It just got truncated from the thread. What I suggest is that in >> section 3.1, in the middle of the first paragraph (the text that Joe >> was quoting originally), remove this: >> >> "The tunnel method MUST support transporting the username >> and password to the authentication server. However, it >> MUST NOT expose the username and password to parties in the >> communication path between the peer and the EAP server and >> it MUST provide protection against man-in-the-middle and >> dictionary attacks." >> >> and put this in its stead: >> >> "The advantage any attacker gains against the tunneled method >> when employing a username and password for authentication MUST >> be through interaction and not computation". >> >> I believe that captures the property we want the tunnel method to >> have and is not so vague. > > Except it *removes* the requirement that the tunneled method transport > the username and password. Given the capabilities of widely deployed > systems, I think that this requirement should be kept. > >> It applies to active attacks against the >> authenticator, active attacks against the client, passive attacks >> between them and between the authenticator and any authentication >> server that may exist, and all forms of man-in-the-middle and >> dictionary attack that could be launched against the legitimate >> participants in this tunnel method. > > How about simply adding your text?: > > "The tunnel method MUST support transporting the username > and password to the authentication server. However, it > MUST NOT expose the username and password to parties in the > communication path between the peer and the EAP server and > it MUST provide protection against man-in-the-middle and > dictionary attacks. That is, the advantage any attacker gains > against the tunneled method when employing a username and password > for authentication MUST be through interaction and not > computation". > > I think this addresses your concerns, while simultaneously stating > clearly the specific requirements. > > Alan DeKok. > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
