Hi Joe, An authentication server is an optional optimization. Do you agree that it should be possible to deploy "the tunnel method" without having such a thing? If that's the case then why the mention of this thing? If the section is about transporting clear text usernames and passwords then why not just say "The tunnel method MUST support clear text username and password authentication"? Like I said, this whole thing about transporting stuff to an authentication server sounds, to me at least, like it's mandating a particular deployment.
(It's odd, I'm hung up on the words "authentication server", and there is insistence that that phrase remain to support clear text passwords. Authentication server...clear text passwords...no I don't see the connection). I should be able to implement "the tunnel method", including support for clear text passwords!, such that it does not support a stand-alone authentication server, which is how EAP has traditionally been defined. It may not be particularly useful for many "real-world deployments" but it might be very useful for some particular situation. And I don't know why such a thing should be disallowed if all you really want to say is that clear text passwords MUST be supported. Regarding the 2nd paragraph, "reveal information about" is certainly better text "expose" and I can live with this. And I appreciate the inclusion of my text. Thanks. regards, Dan. On Fri, December 4, 2009 8:44 am, Joseph Salowey (jsalowey) wrote: > This section is about transporting clear text usernames and passwords > within the tunnel, so password transport requirement needs to stay. I'm > fine with more accurate text for describing the attacks. I propose the > following text: > > "The tunnel method MUST support transporting clear text username and > password to the authentication server. It MUST NOT reveal information > about the username and password to parties in the communication path > between the peer and the EAP Server. The advantage any attacker gains > against the tunneled method when employing a username and password for > authentication MUST be through interaction and not computation. " > > Cheers, > > Joe > >> -----Original Message----- >> From: Alan DeKok [mailto:al...@deployingradius.com] >> Sent: Thursday, December 03, 2009 11:36 PM >> To: Dan Harkins >> Cc: Joseph Salowey (jsalowey); emu@ietf.org >> Subject: Re: [Emu] Issue #7: Password Authentication >> >> Dan Harkins wrote: >> > A "clear-text" password will have to be sent "in the >> tunnel" because >> > otherwise authentication would not be possible! >> >> There are many authentication protocols which do not >> require the sending of a clear-text password. CHAP, MS-CHAP, >> EKE, SRP, or your own proposal. So I'm a little surprised >> that you think authentication can happen only via sending a >> clear-text password. >> >> Your suggested text permits the tunneled protocol to >> support *only* one of these other methods, and to *not* >> support sending of a clear-text password. For reasons I gave >> before, we cannot standardize on a tunneled protocol that >> fails to support clear-text passwords. >> >> I welcome text to clarify the security requirements. But I >> am opposed to removing the stated requirement for clear-text >> passwords. Everything else we've discussed is secondary to >> that point. >> >> Alan DeKok. >> > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
