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

[Karthikeyan Bhargavan <[e-mail]>]

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