Re: [TLS] new version of draft-dthakore-tls-authz

[Darshak Thakore <[e-mail]>]

Hi Mark,

Thanks for the feedback and the link to the paper. I agree that the dtcp_authz_data structure currently defined excludes the RandomNonce (or the equivalent running hash as you suggested) out of the signature and it should have included it. I can update the struct accordingly. Given that modification, would there still be a need to put in a running hash of all the messages?
My primary concern with including a running hash in the struct is that this structure is a payload of the SupplementalData message and as per RFC4680, it is an application's responsibility to provide this information. I'm not sure if we can assume that an application always has access to all messages at the TLS protocol layer.

Also one point of clarification, the client will not be generating its own nonce, rather it will take the nonce it has received from the server in the server's SupplementalData message and include it in its own SupplementalData message.

With that modification, the struct would be something like

      struct {
          opaque random_bytes[32];
      } RandomNonce;

      struct {
          RandomNonce nonce;
          opaque DTCPCert<1..2^24-1>;
          opaque ASN.1Cert<0..2^24-1>;
      } DigitallySigned;

      struct {
          DigitallySigned certs;
          opaque signature[40];
      } dtcp_authz_data;

When the server sends this in its SupplementalData message, it will generate the RandomNonce. When the client sends back its own SupplementalData message, it will include the one it received from the server.

With that, if we only consider the scenario of the client sending its DTCP Certificate, there are two possible options, one in which the client is also using its X.509 certificate (i.e. it will send its ClientCertificate and CertificateVerify messages also) and the other is where the client does not have an X.509 certificate to send.
For the first case, an example exchange would be something like:

  1.  Client sends ClientHello, Server Sends ServerHello
  2.  Server sends SupplementalData that only has a RandomNonce (N1)
  3.  Server sends Certificate, CertificateRequest and ServerHelloDone
  4.  Client sends SupplementalData that has [(N1, DTCP Cert, X.509 Cert) Signature covering all three elements]
  5.  Client sends Certificate message (needs to be the same X.509 Cert as above)
  6.  Client sends ClientKeyExchange, ChangeCipherSpec and Finished
  7.  Server sends ChangeCipherSpec and Finished

Would this address the replay attack?

Regards,
Darshak


From: Mark Brown <[e-mail]<mailto:[e-mail]>>
Date: Thursday, January 24, 2013 2:42 PM
To: Darshak Thakore <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [TLS] new version of draft-dthakore-tls-authz

Hi Darshak,

I’m still concerned with replay attacks, despite the updates.

The structures in 3.2 haven’t changed materially, and the explanations make me more sure there’s this problem: the specified RandomNonce won’t prevent replay attacks. You might consider prior protocol analyses, for example this paper: http://www2.cs.uidaho.edu/~jimaf/papers/replay02.pdf

To (over)simplify, follow the example of TLS CertificateVerify used for client authentication: instead of an arbitrary nonce, take a hash over *all* of the handshake messages sent/received so far (i.e. the output from the hash function run over these concatenated messages). Doing so gives a more useful session-identifying  “nonce”. Since the session messages “so far at this point” include client nonce, server nonce and server certificate, I’d estimate that you’ve overcome the 1995 Lowe attack (see http://en.wikipedia.org/wiki/Needham%E2%80%93Schroeder_protocol#Fixing_the_man-in-the-middle_attack ).

How to say this well? The text for CV gives a template, see: http://tools.ietf.org/html/rfc5246#section-7.4.8.
Your structures might be:

                The set of all Handshake Messages in the run so far, using http://tools.ietf.org/html/rfc5246#section-7.4 :

         handshake_hash      = Hash(handshake_messages);

                Your client_authz must contain an assertion as a component, such as:
         struct {
             opaque handshake_hash[hash_length];
             opaque DTCPCert<1..2^24-1>;
             [[opaque ASN.1Cert<1..2^24-1>]];
         } DTCPClientAssertion;

                Your client_authz SupplementalData message should contain the assertion plus its signature, e.g.:

         assertion_hash      = Hash(DTCPClientAssertion);

         signature          = ECDSA_Sign(assertion_hash);

         struct {
             DTCPClientAuthz client_assertion;
             opaque signature<1..2^16-1>;
         } dtcp_authz_data;


This last struct is very similar to http://tools.ietf.org/html/rfc5246#section-4.7 “DigitallySigned”, but omits the SignatureAndHashAlgorithm identifier for two reasons: 1) the signature and hash algorithms are DTCP’s not TLS’s and so the registry and code points may differ 2) the DTCPClientAssertion.DTCPCert should contain this information, and currently it’s a mandatory-include part of the message.

At this point, I’ve only presented an assertion that’s appropriate for client_authz, but I think that’s all that *should* be specified. I would eliminate sending server_authz from the server to the client for your use case.

Sincerely,
mark