Subject: [TLS] Key Control Vulnerability in SRP (Triple Handshake Variant)

From: Karthikeyan Bhargavan <[email-masked]>
Date: Fri, 8 Aug 2014 16:01:34 -0400

Hi,

The following is specific to SRP, but perhaps of interest to those working with TLS-SRP.
(The email address for the SRP spec authors seems to be out of date, and I’m hoping they are on this list.) 

While investigating the triple handshake attack on various TLS cipher suites, we came upon two scenarios in which one of the participants of the SRP protocol can unilaterally control the generated session key. We wonder if this is already well known about SRP? In the key exchange literature, the violated property is often called “contributiveness” and the attack is sometimes called “key control.” It is a somewhat theoretical attack and the only exploit we know of is as a first step in a triple handshake attack, but it is an avoidable vulnerability nevertheless.

We describe two scenarios below, adopting the notation of http://srp.stanford.edu/design.html
The key observation is that SRP only asks clients to verify that A and B are not 0; it does not require
any additional public-key validation steps (and indeed TLS-SRP in OpenSSL does not perform any other checks, although SRP in GnuTLS does). Consequently, an attacker (acting as a client or as a server) can mount a specific kind of small subgroup confinement attack resulting in key control, both as a client and as a server.

Since SRP uses Sophie-Germain MODP groups, we advocate that both parties in SRP should fully validate that the received Diffie-Hellman public keys belong to the prime-order subgroup [2..N-2].  In the context of TLS-SRP, the session-hash extension will also prevent these scenarios, but that extension cannot protect  other uses of SRP.

Case 1: Compromised Verifier v, Degenerate server public-key g^b
-----------------------------------------------------------------------------------------

Suppose an attacker has obtained the verifier v for a client. 
Now the attacker impersonates the host in the SRP exchange and chooses 
B = kv + 1 or B = kv or B = kv + (N-1) and in all three cases the generated key K will be *independent* 
of the user’s session specific value A. For the example with B = kv + 1, see:

User -> Host:  I, A = g^a                  (identifies self, a = random number)
Host -> User:  s, B = kv + 1               (sends salt, b = 0)

        Both:  u = H(A, B)

        User:  x = H(s, p)                     (user enters password)
        User:  S = (B - kg^x) ^ (a + ux) = 1   (computes session key)
        User:  K = H(S) = H(1)

        Host:  S = (Av^u) ^ b              (computes session key)
        Host:  K = H(S)= H(1)

Case 2: Degenerate verifier v
————————————————————

Suppose an attacker registers at the SRP host with a triplet (I, s, v) where v is either 0 or 1 or N-1.
Further, assume that the user always chooses A = 0 or 1 or N-1. Now, all sessions between the user and host will result in a generated key that is independent of the server’s session specific choice of g^b. 
For the example with v = 1 and A = 1, see:

User -> Host:  I, A = g^0 = 1              (identifies self, a = 0)
Host -> User:  s, B = kv + g^b             (sends salt, b = random number)
        User:  K = H(S) = H(1)
        Host:  S = (Av^u) ^ b = 1              (computes session key)
        Host:  K = H(S)= H(1)

Problem(?) and Fix
—————————————

It is possible that the above scenarios known and considered innocuous. Indeed, by themselves, they do not appear to break the stated security goals of SRP. However Key Control vulnerabilities like these typically lead to failures when composed with other protocols in compound authentication schemes. In this case, TLS-SRP becomes one of the key exchanges (along with RSA and DHE) that is vulnerable to the triple handshake attack (renegotiation after resumption). In particular, after a TLS-SRP exchange, the master secret is not guaranteed to be unique across sessions, and hence it should not be used for (say) cryptographic binding in PEAP/EAP-TTLS. 

The fix seems simple on the surface (ensure that the DH public keys are in [2,p-2])  but perhaps this requires more analysis, lest it violate the one-guess-per-session guarantee of SRP. The client should validate that B-kv is not 0,1,N-1. Similarly, the server should reject verifier values of 0,1,N-1.

Best,
Karthik

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 8 Aug 2014 13:55:44 -0700

> The following is specific to SRP, but perhaps of interest to those working
[...]
>
> While investigating the triple handshake attack on various TLS cipher
> suites, we came upon two scenarios in which one of the participants of the
> SRP protocol can unilaterally control the generated session key.

Hi Karthikeyan,

Thanks for the observation.

I haven't followed the triple-handshake discussion closely.  My
impression is that it's a TLS issue - not an SRP issue - which should
be fixed by something like [1].

Is that correct?

Trevor

[1] http://datatracker.ietf.org/doc/draft-bhargavan-tls-session-hash/

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Fri, 8 Aug 2014 17:11:31 -0400

> ….

Yes, [1] is the current proposal to prevent all triple-handshake-style key synchronisation attacks

The observation here is meant to document that TLS-SRP (not just TLS-RSA and TLS-DHE) also
allows key control, but that this can be easily avoided by some cheap implementation checks.

The main concern may be for for other uses of SRP where [1] may not apply, but I don’t know enough about
such applications to comment.

Best,
-Karthik

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 8 Aug 2014 14:55:19 -0700

> allows key control, but that this can be easily avoided by some cheap implementation checks.

Maybe, but you said yourself this would "require more analysis".

I think if a protocol like TLS is going to reuse a session key, it's
the protocol's job to ensure this is safe.  There are generic ways to
do so (e.g. hashing the transcript into session key).

So I'm not convinced we should be going through the math of all key
agreements and trying to tweak them for an unusual property like "key
control".

Trevor