Subject: [ietf-tls] Next version of SRP draft using extensions

From: "David Taylor" <[email-masked]>
Date: Mon, 25 Jun 2001 23:22:47 +1000

Hi all,

I am working on the next version of the SRP authentication draft, and have
changed it to use extended client and server hello messages, as per the
extensions draft.

The extensions draft says anyone proposing new extensions should post the
proposal to the list for review, so here is the scheme I have come up with
for SRP authentication.

The SRP draft adds a new extension type - srp(6) - to the ExtensionType
enumerated. This extension is used in both the client and server hello
messages, if SRP authentication is used.

The data structure sent in the extension is defined as:

   enum { client, server } ClientOrServerExtension;

   enum  { sha-1(0), (255) } PasswordMessageDigest;

   struct {
      select(ClientOrServerExtension) {
         case client:
            opaque srp_U<1..2^8-1>;
         case server:
            PasswordMessageDigest srp_md;
            opaque srp_s<1..2^8-1>
            opaque srp_N<1..2^16-1>;
            opaque srp_g<1..2^16-1>;
      }
   } SRPExtension;

and is used in the following handshake sequence:

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

Other things I have specified are:

The short handshake mechanism for re-using sessions for new connections, and
renegotiating keys for existing connections will still work with the SRP
authentication mechanism and handshake.

When a client attemps to re-use a session, it must still include the SRP
extension carrying the user name (U) in the client hello message, in case
the server cannot or will not allow re-use of the session, meaning a full
handshake sequence is required.

If a client requests an existing session and the server agrees to use it
(meaning the short handshake will be used), the server may omit the SRP
extension from the server hello message.

When encoding the numbers g, N, A, and B as opaque types, if the most
significant bit is set, an extra byte of value 0x00 (all bits cleared)
should be added as the most significant byte. This is done both to reduce
the ambiguity of the encoding of the numbers, and as a safeguard against
implementations that do not assume these numbers are positive.

The passwordMessageDigest enumerated is included for future expansion. At
the time of writing, SHA-1 is the only message disgest defined for use by
[RFC 2945].

Thanks for your comments,
David Taylor.

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