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

["Mark Brown" <[e-mail]>]

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_m
an-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