Subject: [ietf-tls] Proposal: SRP authentication for TLS

From: David Taylor <[email-masked]>
Date: Tue, 20 Jan 1998 20:39:11 +1100

Following my message from yesterday, I have the proof of concept working. Here are some details of the changes I made to the handshake.

I don't claim this is a secure solution, or that it is not open to attack - I would appreciate it if the list members would look over it and see where it needs to be improved, and whether it it worth pursuing.

TLS Handshake Sequence
----------------------

          Client                                 Server
            |                                      |
       Client Hello (U) ------------------------>  |
            |  <---------------------------- Server Hello
            |  <---------------------------- Server Key Exchange (g, N, s)
       Client Key Exchange (A) ----------------->  |
            |  <---------------------------- Server Key Exchange (B)
            |  <---------------------------- Server Hello Done
       change cipher spec                          |
       Finished -------------------------------->  |
            |                                change cipher spec
            |  <---------------------------- Finished
            |                                      |

The identifiers in () refer to variables defined in RFC-2945.

This new handshake sequence has a number of differences from the standard TLS handshake sequence:

   o  The client hello message has the user name appended to the
      message. This is allowable as stated in section 7.4.1.2 of RFC-2246.

   o  The client must respond with a message before it receives the server
      hello done message, due to the data exchange sequence requirements
      stated in section 3 of RFC-2945: The server cannot send B until it
      has received A from the client. If this was not the case, the server
      could send B in the first server key exchange message.

   o  The server key exchange message is sent twice, due to the reasons
      stated above.

   o  The client and server messages are now interleaved due to the
      reasons stated above.

   o  There is no server authentication in this version of a TLS
      handshake.

The Client Hello Message
------------------------

Appended to the standard client hello message is the user name. This is encoded as:

   opaque username<1..2^8-1>

This data will be included in the record length, so the server knows to read it.

The Server Key Exchange Messages
--------------------------------

The server key exchange message in the first round contains the generator (g), the prime (N), and the salt value read from the "password" file.

The server key exchange message in the second round contains the servers ephemeral public key (B).

The associated data structures are modified as follows:

enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;

enum { first, second } KeyExchangeRound;

struct {
   select (KeyExchangeRound) {
      case first:
         opaque srp_salt<1..2^8-1>
         opaque srp_N<1..2^16-1>;
         opaque srp_g<1..2^16-1>;
      case second:
         opaque srp_b<1..2^16-1>;
   };
} ServerSRPParams;     /* SRP parameters */

srp_N
   The prime modulus used for the SRP operation.

srp_g
   The generator used for the SRP operation.

srp_b
   The servers ephemeral public key.

struct {
   select (KeyExchangeAlgorithm) {
      case diffie_hellman:
         ServerDHParams params;
         Signature signed_params;
      case rsa:
         ServerRSAParams params;
         Signature signed_params;
      case srp:
         ServerSRPParams params;
   };
} ServerKeyExchange;

The Client Key Exchange Messages
--------------------------------

The client key exchange message for the first round carries the clients ephemeral public key (A), which is calculated using information known locally and received in the first server key exchange message. This message must be sent between the first and second server key exchange messages.

The associated data structures are modified as follows:

struct {
   select (KeyExchangeAlgorithm) {
      case rsa: EncryptedPreMasterSecret;
      case diffie_hellman: ClientDiffieHellmanPublic;
      case srp: SRPClientEphemeralPublic;
   } exchange_keys;
} ClientKeyExchange;

struct {
   opaque srp_A<1..2^16-1>;
} SRPClientEphemeralPublic;

The Pre-Master Secret
---------------------

After the second server key exchange message, both sides have enough information to calculate the shared secret. If this is sent through the interleaved SHA-1 hash function as explained in 3.1 of RFC-2945, it is suitable for use as a pre-master secret.

Cipher Suites
-------------

   CipherSuite     TLS_SRP_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x31 };
   CipherSuite     TLS_SRP_WITH_RC4_128_SHA            = { 0x00,0x32 };
   CipherSuite     TLS_SRP_WITH_IDEA_CBC_SHA           = { 0x00,0x33 };
   CipherSuite     TLS_SRP_WITH_3DES_EDE_CBC_MD5       = { 0x00,0x35 };
   CipherSuite     TLS_SRP_WITH_RC4_128_MD5            = { 0x00,0x36 };
   CipherSuite     TLS_SRP_WITH_IDEA_CBC_MD5           = { 0x00,0x37 };

These numbers are for example only, and will be changed to something more appropriate.

Regards,
David Taylor.

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]