Subject: RE: [eap] Issue 167: Cleartext Passwords in EAP

From: <[email-masked]>
Date: Fri, 15 Aug 2003 14:56:18 +0300

Hi,

GTC can also be used with PEAP/TTLS to support password
databases that store a one-way hash of the password. 
When used this way, it's not that insecure either (not 
worse than e.g. SSH). This use is mentioned e.g. in 
http://www.ilabs.interop.net/WLAN_Sec/Inner_Auth-lv03.pdf

I think it's safe to assume that in the absence of some
other solution, people will use GTC for this with IKEv2 
as well. 

This is probably not such a bad idea in many cases, 
since the alternative is to store the password (or 
password-equivalent) in clear (deploying SRP or 
something similar doesn't seem realistic any time soon).

So, perhaps something like "The EAP GTC method MUST NOT 
be used to provide support for cleartext passwords in the
absence of a protected tunnel with server authentication,
such as PEAP or IKEv2." would be sufficient?

Best regards,
Pasi

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: Thursday, August 14, 2003 11:30 PM
> To: [email-masked]
> Subject: [eap] Issue 167: Cleartext Passwords in EAP
> 
> 
> Issue 167: Cleartext Passwords in EAP
> Submitter name: Bernard Aboba
> Submitter email address: [email-masked]
> Date first submitted: 8/14/2003
> Reference:
> Document: RFC2284bis
> Comment type: T
> Priority: S
> Section: 5.5, 5.6
> Rationale/Explanation of issue:
> 
> Reading Section 5.5 and 5.6, it is not made crystal clear 
> that the EAP OTP and GTC methods are not intended to provide 
> support for cleartexst passwords.
> 
> In Section 5.5, add to the end of the "Description" paragraph:
> 
> "The EAP OTP method is intended for use with the One-Time 
> Password system only, and MUST NOT be used to provide support 
> for cleartext passwords."
> 
> In Section 5.6, add to the end of the "Description" paragraph:
> 
> "The EAP GTC method is intended for use with the Token Cards 
> supporting challenge/response authentication and MUST NOT be 
> used to provide support for cleartext passwords."
> 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 15 Aug 2003 06:33:08 -0700 (PDT)

> such as PEAP or IKEv2." would be sufficient?

Several problems with this:

a. On the AAA server side, protocols such as RADIUS do not mandate
confidentiality, and there is no support for "hiding" of the EAP-Message
attribute in the way that the User-Password attribute is hidden.  That
means that any cleartext password sent via an EAP method will be exposed
on the wire from the NAS to the RADIUS server.  Since protocols such as
EAP TTLS support "early termination" where the tunnel is terminated on a
different server (e.g. a proxy) than the final exchange, this results in a
cleartext password sent over a portion of the path.

b. Even if the RADIUS User-Password attribute is used, this creates a
number of vulnerabilities, including known plaintext attacks. If the
Request Authenticator repeats on any NAS with the same shared secret an
attacker would potentially be able to crack the User-Password attribute,
which is encrypted with a stream cipher dependent only on the shared
secret and the RA.

The introduction of cleartext passwords into EAP therefore represents a
substantial security vulnerability -- and one which was purposefully left
out of RFC 2284.

---

From: "Joseph Salowey" <[email-masked]>
Date: Fri, 15 Aug 2003 08:00:19 -0700

If you are going to advocate the use of passwords you're protected tunel
must be server authenticated and extend all the way to the AAA that does
the password validation.  Intermediaries/NASes should never see the
password.  Specifing that EAP-OTP and EAP-GTC should not be used for
cleartext passwords is good because they can be used without PEAP/TTLS.

I think it is up to PEAP/TTLS to define how and if clear text passwords
may be used within these tunnels and can define specific mechanisms to
do this.  If they do allow this then they should specify that the that
the protected tunnel MUST extend all the way to the EAP-Server that
validates the passwords and authenticates this server to the client.
Tunnel client MUST NOT send a cleartext password unless it has
authenticated the EAP-Server and has determined that it is authorized to
receive the password.   

Additional comments in line:

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernard Aboba
> Sent: Friday, August 15, 2003 6:33 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [eap] Issue 167: Cleartext Passwords in EAP
> 
> 
> absence of a 
> > protected tunnel with server authentication, such as PEAP 
> or IKEv2." 
> > would be sufficient?
> 
> a. On the AAA server side, protocols such as RADIUS do not 
> mandate confidentiality, and there is no support for "hiding" 
> of the EAP-Message attribute in the way that the 
> User-Password attribute is hidden.  That means that any 
> cleartext password sent via an EAP method will be exposed on 
> the wire from the NAS to the RADIUS server.  Since protocols 
> such as EAP TTLS support "early termination" where the tunnel 
> is terminated on a different server (e.g. a proxy) than the 
> final exchange, this results in a cleartext password sent 
> over a portion of the path.
> 

[Joe] Even worse the intemediaries/NAS know the password. However it is
possible to deploy PEAP and TTLS so the protection is all the way to the
validating server.  

> b. Even if the RADIUS User-Password attribute is used, this 
> creates a number of vulnerabilities, including known 
> plaintext attacks. If the Request Authenticator repeats on 
> any NAS with the same shared secret an attacker would 
> potentially be able to crack the User-Password attribute, 
> which is encrypted with a stream cipher dependent only on the 
> shared secret and the RA.
>
[Joe] I completely agree.
 
> The introduction of cleartext passwords into EAP therefore 
> represents a substantial security vulnerability -- and one 
> which was purposefully left out of RFC 2284.
> 
[Joe] While I would rather not see cleartext passwords, I'm not sure
that this represent a substantial security vulnerability if deployed
properly.  In this case that would be in a server side authenticated
tunnel such as (TTLS/PEAP) that extends all the way to the EAP server
validating the password. This was not available when 2284 was concieved.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 15 Aug 2003 08:41:22 -0700 (PDT)

> cleartext passwords is good because they can be used without PEAP/TTLS.

Agreed.

> do this.

Yes. Presumably those individual specifications will address the security
issues involved.

> If they do allow this then they should specify that the that

Yup.

> authenticated the EAP-Server and has determined that it is authorized to

Agreed.

> possible to deploy PEAP and TTLS so the protection is all the way to the

Yes.

> validating the password. This was not available when 2284 was concieved.

If the password is completely protected end-to-end via a tunnel, it's not
really a "cleartext password".  Perhaps we need some language to make that
clear?

---

From: John Vollbrecht <[email-masked]>
Date: Wed, 20 Aug 2003 18:16:36 -0400

> really a "cleartext password".  Perhaps we need some language to make that
Perhaps a solution ist to let the tunnel methods describe their security 
requirements, but saying  in 2284bis that:" if not in a tunnel OTP and GTC 
(or any other that might be invented) must not contain cleartest password. "