Actually this is still kind of vague: what is "generated directly"? In a challenge-response, it is the password is encrypted/hashed - does this count as "directly"?
Also, *all of* sec. 4.5.1 should apply to this kind of methods, not just
server authentication. So I suggest to replace:
Due to the fact that the EAP peer needs to send clear text password
to the EAP server to authenticate against the legacy user
information, the security measures in the following sections MUST be
met.
By:
Many internal EAP methods have the peer send its password in the clear
To the EAP server. Other methods (e.g. challenge-response methods) are
vulnerable to attacks if an eavesdropper can intercept the traffic. For
any such methods, the security measures in the following sections MUST be
met.
Thanks,
Yaron
> -----Original Message-----
> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
> Joseph Salowey (jsalowey)
> Sent: Thursday, August 06, 2009 22:17
> To: emu@ietf.org
> Subject: [Emu] Issue #16: Server auth
>
> #16: Server auth
>
> Issue:
>
> 4.5.1: I suggest to mention that even in cases where passwords are *not*
> sent in the clear (e.g. challenge-response methods), server
> authentication is still a MUST.
>
> Comment:
>
> Suggested Text:
> "The EAP server MUST be authenticated before the peer can send the
> clear text password or information generated directly from the password
> to the server."
>
> --
> Ticket URL: <http://trac.tools.ietf.org/wg/emu/trac/ticket/16#comment:1>
> emu <http://tools.ietf.org/wg/emu/>
>
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
> Scanned by Check Point Total Security Gateway.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
