Subject: RE: [eap] Proposed resolution to Issue 167: Cleartext Passwords

From: "Glen Zorn" <[email-masked]>
Date: Mon, 1 Sep 2003 01:55:04 -0700

Bernard Aboba <mailto:[email-masked]> writes:

> The text of Issue 167 is enclosed below.  The proposed resolution is
> as follows:
> 
> Proposed fix:
> 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 in the absence of a protected
> tunnel with server authentication."  

So, is it correct to surmise that SecurID cards are not supported by
EAP-GTC? 

> 
> Add Section 7.14:
> 
> "7.14 Cleartext Passwords
> 
> EAP does not support cleartext password authentication. This
> ommission 
  ^^^^^^^^^ omission

> is intentional. Where EAP is carried over physically
> insecure lower layers, including wireless LANs [IEEE80211] or the
> Internet, use of cleartext passwords would allow the password to be
> captured by an attacker with access to the lower layer.    
> 
> Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not
> provide confidentiality, even where the lower layer is physically
> secure, EAP frames may be subsequently encapsulated for transport
> over the Internet where they may be captured by an attacker.   
> 
> As a result, cleartext passwords cannot be securely used
> within EAP, except where encapsulated within a protected
> tunnel with server authentication."

I think that these three paragraphs also apply to some (if not all)
token card passcodes, as well as EAP-MD5/CHAP.  Of course, the passcode
or hash can only be used once, but...

> 
> ---------------------------------------------------------------
> Issue 167: Cleartext Passwords in EAP
> Submitter name: Bernard Aboba
> Submitter email address: [email-masked]
> Date first submitted: 8/14/2003
> Reference:
> http://mail.frascone.com/pipermail/public/eap/2003-August/001599.html
> 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."  
> 
> [Pasi Eronen]
> 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?  
> 
> [BA] 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.        
> 
> [Joe Salowey] 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 Salowey] 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 Salowey] 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. 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.
> _______________________________________________ eap mailing list
> [email-masked] http://mail.frascone.com/mailman/listinfo/eap      

Hope this helps,

~gwz

"They that can give up essential liberty to obtain a little temporary
safety deserve neither..." 
-- Benjamin Franklin, 1759

"It is forbidden to kill; therefore all murderers are punished unless
they kill in large numbers and to the sound of trumpets." 
-- Voltaire

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 1 Sep 2003 08:26:27 -0700 (PDT)

> So, is it correct to surmise that SecurID cards are not supported by

EAP Type 15 has been assigned to "RSA Security SecurID EAP" and
EAP Type 32 has been assigned to "SecurID EAP" according to:

http://www.iana.org/assignments/ppp-numbers

So it would appear that SecurID has two EAP Types assigned to it.

> or hash can only be used once, but...

I think what distinguishes a "cleartext password" is that once obtained,
it can be reused to gain subsequent access.

Where the passcode or hash can only be used once, or where a response must
be computed based on a random challenge it is necessary to do an offline
attack to obtain the underlying long-term secret. That is indeed a risk,
but I believe it's covered by including "Dictionary Attack Resistance" as
one of the security claims.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap