Dan Harkins wrote: > 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.
Any authentication system that stores passwords has a limited set of choices. They can store clear-text, or versions modified by a particular cryptographic algorithm (md5, unix crypt, salted, SRP, etc.). From the point of view of the client, the only authentication method which is *known* to be compatible with all possible storage mechanisms is to send clear-text passwords. I would wager that the majority of systems today store passwords in non-clear-text form. Unix crypt, Active Directory, etc. are all widely used examples of this. So no, I do not believe that the requirement is mandating a particular deployment. I believe it is mandating the lowest-common denominator, where clients can be sure that they will be authenticated everywhere that they have credentials stored. In any case, Section 4.5 of the draft discusses the reasons for transport of clear-text passwords in more detail. > 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? A huge number of real-world deployment problems. If the server has access to the clear-text password, it can implement the client side for *any* authentication method. It's not too much of stretch to believe that a server with access to password transform X can implement *both* the client and server side. > 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? Because that's a *reason* for the requirement. It's not a requirement. The reasons are given earlier in the draft (Section 4.5), and do not need to be repeated here. > 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...." Yes... > As I said, exposing password-derived data > is a way to comply with this requirement but it is flawed and insecure. We already discussed the security in a previous exchange. You had agreed that there were no *new* security problems from using this method. > 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. Section 4.5.1.1 gives that requirement. There is no need to re-state it in other places. > 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. The draft addresses your other concerns (historical reasons for using clear-text passwords, requirements on security of clear-text passwords, etc.). I find your suggested text vague, and would prefer to see specific requirements. My guess is that if you extend your text to describe the requirements for clear-text password security, you will be simply reproducing existing text from elsewhere in the document. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
