Subject: Security comment on draft-ietf-pppext-eap-srp-03.txt

From: Robert Moskowitz <[email-masked]>
Date: Tue, 16 Oct 2001 14:29:12 -0400

Hello, I am new to the pppext list.  I joined because I find my work in 
802.11 is dragging me over to EAP types.

I have reviewed RFC 1945 (SRP) and this Internet Draft.  The protocol 
presented here is good for most dialup uses of EAP, but is not for 
802.11.  I will give an abstract then some details:

Most client-server authentication models exist in an environment where the 
client has some outside assurance that it is engaged in an exchange with 
the server it 'thinks' it should be.  802.1x for 802.11 does not offer any 
such assurance.  Since the EAP packets are sent over layer 2, the only 
knowledge the supplicant has of the authenticator is its SSID which is 
totally spoofable.  This fact leads to a requirement that any EAP type used 
for 802.11 provide EXPLICIT mutual authentication.  That is not only does 
the supplicant need to know that the authentication server can prove that 
it has knowledge of the supplicant's identity, but the supplicant has to 
prove that it has knowledge of tha authentication server's identity.

EAP/TLS provides this.  EAP/SRP as defined in this draft does not.

Now to the attack.

in SRP, the authentication system has the supplicant's userid and password 
verifier.  This verifier is a public value.  If it is acquired by another 
attacker, that attacker can put up its own access point with its own 
authentication server and the supplicant will merrily authenticate to this 
rogue AP.

My recommendation is as follows:

Leave this EAP type as is for domains of AS trust, like dialup or wired 
networks (eg VLANs).

For shared media, like 802.11 a different exchange is needed.  The AS needs 
its UserID and Password and thus its Password Verifier (this is really 
nothing more than a Diffie-Hellman raw public key).  This information MUST 
be distributed to all supplicants.  Then first the supplicant must prove it 
has the AS's identity followed by the more 'normal' SRP exchange.

This does produce 2 session keys.  The first one is discarded.

This does have the 'problem' of distributing the AS's Password 
Validator.  This can be done in a number of ways including using a X.509 
cert with a D-H key value.

This is a quick writeup of the attack against this EAP Type in an WLAN 
world.  Note that it has NOTHING to do with the trust relationship of the 
AP to the AS, rather how does the STA KNOW it is talking to the AS it 
thinks it should be talking too.

All things considered, I believe that SRP is better than TLS for MOST 
applications in 802.11.  It is more workable for WISPer and SOHO.  It also 
has an interesting property for 'public' WLANs where the STA wants to prove 
it is connected to the public network it thinks it is connected to (like at 
IETF meetings).

---

From: Jacques Caron <[email-masked]>
Date: Tue, 16 Oct 2001 20:58:18 +0200

Hi,

At 20:29 16/10/2001, Robert Moskowitz wrote:
>totally spoofable.  This fact leads to a requirement that any EAP type 
>used for 802.11 provide EXPLICIT mutual authentication.  That is not only 
>does the supplicant need to know that the authentication server can prove 
>that it has knowledge of the supplicant's identity, but the supplicant has 
>to prove that it has knowledge of tha authentication server's identity.

I don't quite see the point for the server to know that the client know 
that the servers knows the client's verifier (urg). Actually, it already 
does, as the client should abort the connection if anything in the EAP 
exchange shows that the server doesn't know the verifier.

>authentication server and the supplicant will merrily authenticate to this 

The verifier is *not* a public value. It is supposed to be kept secret, 
like any crypted password (e.g. DES or MD5 crypted passwords in /etc/passwd 
derivatives on Unix systems). SRP adds security by making sure that even if 
the verifier becomes public, it is not possible to derive the clear text 
password, and to authenticate as the original user. If the verifier becomes 
compromised, the password should be changed.

>For shared media, like 802.11 a different exchange is needed.  The AS 
>needs its UserID and Password and thus its Password Verifier (this is 
>really nothing more than a Diffie-Hellman raw public key).  This 
>information MUST be distributed to all supplicants.  Then first the 
>supplicant must prove it has the AS's identity followed by the more 
>'normal' SRP exchange.

You're describing bi-directional SRP auth, which if I understood things 
correctly is covered by a patent. If that isn't a problem for you, then

>cert with a D-H key value.

And how would you distribute this? Not within EAP I guess...

>has an interesting property for 'public' WLANs where the STA wants to 
>prove it is connected to the public network it thinks it is connected to 
>(like at IETF meetings).

Definitely, EAP SRP is probably the ideal auth protocol for public WLANs.

Jacques.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 16 Oct 2001 15:31:52 -0400

>exchange shows that the server doesn't know the verifier.

Any server that has gained the public userid and public password verifier 
would pass this test.

>like any crypted password (e.g. DES or MD5 crypted passwords in 
>/etc/passwd derivatives on Unix systems). SRP adds security by making sure 
>that even if the verifier becomes public, it is not possible to derive the 
>clear text password, and to authenticate as the original user. If the 
>verifier becomes compromised, the password should be changed.

If the verifier becomes public, and the servers g and N, then any other 
server can process this verifier.  Also, there is nothing in RFC 2945 or 
eap-srp-03 that states the danger of password verifier leakage.  Quite the 
opposite.  It is called a public password verifier.  Many implementations 
will not make enough effort to keep it secret.

>correctly is covered by a patent. If that isn't a problem for you, then

Which patent?  EKE?  Can you point me to any statement to establish this?

>And how would you distribute this? Not within EAP I guess...

same way in TLS that a client gets its signer's certificate.  out of band.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Oct 2001 19:17:46 -0700 (PDT)

> the server it 'thinks' it should be.  

In general, the EAP exchange is between the client and the AAA server, not
between the client and the NAS. This is no different for PPP than for
802.1X. So if there is mutual authentication, it is between the client and
AAA server. The NAS acts as a "passthrough" and so is not authenticated as
part of the exchange. 

This actually makes sense because the client would typically not be able
to validate the identity of the NAS anyway -- what good would it do to
know that it was ap123.foo.net? What is important is that the NAS has a
trust relationship with the AAA infrastructure, and is not a "rogue" NAS. 
So the client is looking for the NAS to show that it has a trusted
relationship with the AAA server, by proving posession of a private key
(TLS) or shared secret (SRP). 

Typically, AAA protocols require that the communication between NAS and
AAA server be mutually authenticated. RADIUS accomplishes this via a
shared secret or IPsec; Diameter can handle this via TLS or IPsec. 

> 802.1x does not offer such assurance.  

802.1x is not any different from PPP in this respect. This is a property
of EAP, AAA and the individual methods and does not relate to the
encapsulation. 

> Since the EAP packets are sent over layer 2, the only 
> totally spoofable.  

Actually, since the SSID is typically not available to the EAP method, it
isn't possible to take this into account explicitly.  In EAP TLS, both
client and AAA server provide a claimed identity, then prove the claim. In
EAP SRP, only the client provides a claim of identity, and then both sides
prove knowledge of the shared secret. 

The problem arises when you have several accounts. For example, you could
have a userid on a corporate network, a userid on an ISP, and  a userID on
a public "hotspot" network. How do you know which credentials to use for a
given connection? 

It could be argued that in the case of PPP, you have dialed a phone
number; for VPN (e.g. L2TP), you have connected at an IP address; and
for 802.11 you have chosen to associate with an SSID -- and so
based on the selected destination, one could have an expectation about who
is on the other end, and select the credentials appropriately. 
Of course, phone numbers, DNS to IP address resolution and SSIDs can all
be spoofed. So I think that the issue is not related to the encapsulation. 

The issue is whether, given a rogue NAS, any useful information is
leaked by the client during the exchange. 

> Not only does the supplicant need to know that the authentication server
> can prove that it has knowledge of the supplicant's identity, but the 
> supplicant has to prove that it has knowledge of tha authentication 
> server's identity.
> 

Yes, you are correct that in SRP the AAA server does not make a claim of
identity, nor does it prove such a claim. Rather, it proves knowledge of
the client's credentials. 
 
> verifier.  This verifier is a public value.  

No, the SRP verifier is *not* public -- because if it is known, then SRP
is subject to dictionary attack. Rather, the SRP verifier, salt, prime
modulus is assumed to be in a protected credential store. This is superior
to a password stored in reversibly encrypted form or in the clear in that
one has to put more work into obtaining the password if the credential
store is compromised. 

At various points in the EAP SRP protocol, the client is supposed to
disconnect, if the AAA server doesn't behave as expected. Are you claiming
that there is information leakage which isn't addressed in the spec? 

> If it is acquired by another 

This is true, because you'd have all the information to impersonate the
credential store -- because the store would be compromised. That's like
saying that if I obtain your password in a network where passwords are
used, then I can get on the network. 

If we assume that the verifiers are compromised, then the attacker can
mount a dictionary attack on them and obtain some fraction of the
passwords directly. At that point you have more to worry about than 
rogue NASen ;)

> Leave this EAP type as is for domains of AS trust, like dialup or wired 

The issue, if it exists, is valid for all encapsulations. 

> cert with a D-H key value.

What you've just described is very similar to SRP-Z, which is covered by a
Stanford patent. And yes, it is better because each side claims an
identity and proves the claim.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 16 Oct 2001 23:10:29 -0400

>AAA server. The NAS acts as a "passthrough" and so is not authenticated as

yes.  in EAP the 'server' is the AAA box, not the NAS or AP.  And in a NAS 
situation, the client has partial knowledge of what AAA server it is 
dealing with be the phone number dialed.  There is very good control over 
phone numbers.  Games like busy forwarding on someone elses lines DOES 
happen, but rarely.  With APs, SSIDs do not have the same level of 
trust.  Not by a long shot.

>(TLS) or shared secret (SRP).

Ah, but the NAS owns the phone number.  So in fact the client DOES know 
something about the name of the NAS.  It belongs to Mindspring or UUnet, etc.

>shared secret or IPsec; Diameter can handle this via TLS or IPsec.

Not at issue for THIS point.  There is a separate issue here in corporate 
deployments of 802.1x with lots of APs.  But that is not the nature of this 
discussion.

>of EAP, AAA and the individual methods and does not relate to the

802.1x is not like PPP.  Or rather only when deployed over a media like PPP 
is deployed.  If done to a switch with real wires it is like PPP.  If done 
over 802.11, nope.

>prove knowledge of the shared secret.

Of course not.  It is too late, the STA has associated with an AP based on 
SSID with no real knowledge how authentication will proceed.  An 
expectation, but a weak one.

>a public "hotspot" network. How do you know which credentials to use for a

And EAP lacks an announcement of here you are.  So the STA uses the 
SSID.  'The SSID is CORPORATE, therefore use my company ID'.  This 
according to some draft stuff I have seen is how XP works with TLS certs  ( 
:) ).

>be spoofed. So I think that the issue is not related to the encapsulation.

It is hard to spoof phone numbers.  Most VPNs are configured to IP address, 
not domain names.  SSIDs are not only spoofable, one expects to see duplicates.

>leaked by the client during the exchange.

The issue is given the public nature of the verifier, rogue AP-AAA pairings 
are easy to implement.  Rogue NAS-AAA are not.

>the client's credentials.

which with SRP are public credentials unless we change wording in the draft 
and clearly state that this stuff is either for dedicated media use only or 
else protect them as much as passwords.

>modulus is assumed to be in a protected credential store.

Where in the RFC or the draft does it say this?  In fact 2845 says:

    SRP also has the added advantage of permitting the host to store
    passwords in a form that is not directly useful to an attacker.  Even
    if the host's password database were publicly revealed, the attacker
    would still need an expensive dictionary search to obtain any
    passwords.  The exponential computation required to validate a guess
    in this case is much more time-consuming than the hash currently used
    by most UNIX systems.  Hosts are still advised, though, to try their
    best to keep their password files secure.

Advised.  Not you had better!  Theft is only a problem in a shared media 
environment where there is no other reliable check that you are accessing 
the proper authentication server.

>This is superior

Oh, no.  That is the beauty of this risk.  There is no leakage in the 
protocol and everyone things everything is fine.  The analysis is that the 
credentials work on any AAA server.  So you trick the client to go to the 
rogue server through a rogue access point.  This can be done in 802.11 
fairly easily, but not in so easily in PPP.  I do not know enough about 
PPPoE implementations to know if this also has a similar risk.

>used, then I can get on the network.

But there is a body of knowledge about passwords and their theft.  'public 
verifier' (words from the RFC) is a dangerous term.

>passwords directly. At that point you have more to worry about than

See the security considerations in 2945.  Of course Tom Wu's analysis might 
be too kind and you might be right.  In which case stronger words are 
needed here than exist in the RFC or the draft.  The draft does say:

    The security of the credentials stored in the authenticator's data-
    base relies on the entropy in the chosen password, the difficulty of
    hash inversion of a salted string, and the security of the system
    containing the database.  For this reason, the chosen password SHOULD
    be restricted to limit the effectiveness of dictionary attacks
    against a disclosed database.  However, since typical passwords have
    only a few bits of entropy, the database itself MUST be protected
    against disclosure.

I can see systems that will enforce a reasonable level of entropy get this 
wrong.  And since the RFC is more lenient, there should be something here 
stating why.  Perhaps reference to a paper or two.

>identity and proves the claim.

I have talked to Tom Wu about this.  As long as it is 2 exchanges, not one 
exchange with 2 identites, it is not covered by the patent.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Oct 2001 20:39:09 -0700 (PDT)

> something about the name of the NAS.  It belongs to Mindspring or UUnet, etc.

There are documented cases of phone number hijacking -- see "The Masters
of Deception". So I'd claim that depending on this assurance is suspect.

> according to some draft stuff I have seen is how XP works with TLS certs  ( 

Actually, EAP *does* support this -- there is nothing to stop a client
from sending an EAP-Request/Identity to a AAA server. In PPP this is
expected. In 802.1X it is not. 

> The issue is whether, given the public nature of the verifier....

If the SRP verifier is public, then SRP does not provide dictionary attack
protection. So precautions need to be taken.

> else protect them as much as passwords.

Agree with "protect them as much as passwords." This is essential to get
the claimed benefits from SRP. 

> Advised.  Not you had better!  

Point taken. I think that the language should be considerably
stronger. Since the major advantage of SRP is dictionary attack
resistance, this seems like a MUST to me. 

> PPPoE implementations to know if this also has a similar risk.

OK, it's just verifier leakage then. But we should probably go over it
again with a fine tooth comb to make sure.

> verifier' (words from the RFC) is a dangerous term.

Agree. The term is not really appropriate -- and some warning text should
be inserted in the draft. How about this?

"EAP SRP implementations MUST protect the verifier against
compromise. While an attacker would still need to carry out a dictionary
attack against a compromised verifier in order to recover the shared
secret, such a compromise does enable an attacker to impersonate an EAP
authenticator. Therefore, EAP SRP implementations MUST NOT treat the
verifier as public information."

> stating why.  Perhaps reference to a paper or two.

Any suggested papers to reference?

> exchange with 2 identites, it is not covered by the patent.

OK. Are  you saying that there should be language encouraging use of 2
exchanges, one for each direction?

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 17 Oct 2001 00:28:55 -0400

>of Deception". So I'd claim that depending on this assurance is suspect.

We had a case here in Detroit of a Plumber getting in a busy forward order 
to his lines on one of his competitor's lines, so yes things are possible 
in PSTN, but not easy like SSIDs.  There is really a scale of difference in 
the attack.

>expected. In 802.1X it is not.

Maybe because it is so weak an assurance, why bother?

> > Where in the RFC or the draft does it say this?  In fact 2845 says:

oops 2945.

>resistance, this seems like a MUST to me.

agreed.

>again with a fine tooth comb to make sure.

I have, but I am not a cryptographer.  Perhaps a question directed to Tom 
might provide an analysis paper.

>verifier as public information."

yes.

>Any suggested papers to reference?

No.  Rather on suggestions on who to ask, like Tom Wu.

>exchanges, one for each direction?

Yes.  And perhaps an example of how to do it in fewer than 8 packets by 
doing multiple operations.  But then I am not really fluent in EAP and it 
might not allow that.

I would like to have a submission like this for the Nov 802 meeting in Austin.

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 17 Oct 2001 07:54:54 -0400

>exchanges, one for each direction?

I forgot to mention one VERY  important aspect of this in light of the 
dictionary attack against the password verifier.

Every client will have the server's password verifier.  It is PUBLIC.  Thus 
the password has to have adequate entropy to be resilient against 
dictionary attacks.  a 64 bit random number SHOULD do it.  But probably 96 
bits or even 128 bits is best.

A random password for a server is not a problem.  It is entered once into 
the server and promptly forgotten.  Of course, like any private key, the 
server needs to protect it very well (Dah, like this is any different from 
TLS).

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 17 Oct 2001 08:43:08 -0700 (PDT)

> Every client will have the server's password verifier.  It is PUBLIC.  

You're assuming two one-way authentications, correct? In SRP, the client
does *not* have the server's verifier, only its own. Also, you are
assuming that the server's verifier is the same for every client. 

> Thus 

How about this:

"If two authentications are being done, once in each direction, then the
client will need to store the server's verifier, in addition to its own. 
If the server verifier is the same for each client, then this constitutes
a public quantity, and needs to have adequate entropy to be resilient
against dictionary attack. The server verifier MUST have at least 64 bits
of entropy, and SHOULD have at least 128 bits."