Subject: [TLS] FWD: Suggested change to "SRP for TLS"

From: Eric Rescorla <[email-masked]>
Date: Fri, 15 Jun 2007 08:31:01 -0700

Forwarded for a non-subscriber...
---------------------------------------------------------------------------
Eric,

Regarding "Using SRP for TLS Authentication" (draft-ietf-tls-srp-13), I have
a small change I think would make the protocol more useful.  I don't follow
the TLS WG mailing list and I don't know the draft's authors. I figured I'd
tell you and you could forward this message to appropriate parties.

I suggest allowing for client-retained salt that is not transmitted as part
of the protocol.  This would be indicated when a zero-length (or zero
value?) srp_s parameter was transmitted as part of the server key exchange
message.

Those who agree with this idea can stop reading now.

In the protocol specified by the I-D and more generally in SRP, the salt is
retained by the server and supplied to the client after the client
identifies itself. However, the salt plays no other role in the server's
actions. It isn't needed for any server computation during the protocol
proper and isn't needed in the notional registration phase when the verifier
is created by the client then transmitted to and stored by the server.

Server-retained salt in classic SRP has the important practical advantage
that it is often easier for servers than clients to have stable storage.
However, withholding salt from servers greatly reduces (eliminates) the
threat of insider password-guessing attacks.

SRP users likely will have passwords no stronger and no less shared among
hosts than in existing password-based systems.  Given this, and that the
raison d'être of verifier-based systems is to reduce insider attacks,
client-retained salt may be appropriate for some applications.

My shamefully perfunctory suggestions for changes to the I-D are below.

Cheers,
-Allan
Allan M. Schiffman [email-masked]
CommerceNet
169 University Ave.
Palo Alto, CA 94301
+1.650.289.4055

-------------------------------------------------------------------------
-------------------------------------------------------------------------
    Suggested changes to draft-ietf-tls-srp-13
    accommodating client-retained salt

First, I note that client-retained salt affects the client/server initial
registration phase (outside the scope of the I-D).  In the registration
protocol, the client would inform the server that it commits to retaining
the salt.

Add to the end of section 2.2:
    In a minor departure from SRP, we accommodate applications that withhold
    the salt from servers by allowing for the zero-length s parameter to be
    interpreted as "client-retained salt".

Append to section 2.5.3:
   The client SHOULD abort the handshake with an "illegal_parameter" alert
   if it has arranged to use client-retained salt and the length of s is
   non-zero.

The first part of section 2.6 should be replaced with:
   The pre-master secret is calculated by the client as follows:

        I, P = <read from user>
        N, g, s, B = <read from server>
        S = <s if non-zero length, otherwise as retained by client>
        a = random()
        A = g^a % N
        u = SHA1(PAD(A) | PAD(B))
        k = SHA1(N | PAD(g))
        x = SHA1(S | SHA1(I | ":" | P))
        <premaster secret> = (B - (k * g^x)) ^ (a + (u * x)) % N

Append to section 2.8.2:
    A zero-length srp_s element indicates that the seed is client-retained.
-------------------------------------------------------------------------

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 15 Jun 2007 15:02:58 -0700

Allan wrote:
[...]
> of the protocol.
[...]

Hi Allan,

I believe this is already allowed (in essence), so changes to the 
protocol and draft are not needed:

It is perfectly legal for a client-side password-generator to combine a 
user-entered password with a stored, shared secret to generate the 
actual "SRP password" that is handed to SRP.

I think this accomplishes your goal of strengthening the user-entered 
password with a stored secret, and is cleaner, since:
  - it treats the stored secret orthogonally to the SRP salt (i.e., both 
can be used)
  - it does not require protocol changes
  - it does not provide additional information to someone watching the 
network (whether a client-stored shared secret is in use or not)

Trevor

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 15 Jun 2007 15:04:53 -0700

[FIXED TYPO]

Allan wrote:
[...]
[...]

Hi Allan,

network (whether a client-stored secret is in use or not)

Trevor

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 15 Jun 2007 15:06:43 -0700

[FIXED TYPO AGAIN, SORRY!]

Allan wrote:
[...]
[...]

Hi Allan,

It is perfectly legal for a client-side password-generator to combine a
user-entered password with a stored secret to generate the
actual "SRP password" that is handed to SRP.

Trevor