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

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

Hi Darshak,

 

Thanks for the solid response. Sounds like you're saying: 

 

1)      For server_authz you'll generate the RandomNonce message you specify
below as a challenge in a challenge-response protocol

2)      For client_authz you'll repeat the server's RandomNonce value, plus
the certs you're interested in sending, within the envelope (so to speak) of
that which is DigitallySigned (per your spec below)

3)      To accomplish authorization, the server will verify the signature
and validate the RandomNonce value as being "the value that I sent to this
client."

 

Does this overcome replay attacks? Not an easy question. We should consider
if a MITM could splice in bad RandomNonce values or somehow gain advantage
by replaying old signed ones. MITM would *have* to make the server believe
that an old RandomNonce value, call it N1, was valid. It seems unlikely,
IMO, unless MITM could force a collision such that server thought "Yeah, I
just sent this N1 to the client," even when it was the same N1 value some
client had signed a while ago. This seems reasonably safe when considering
your suggestions from a protocol point of view.

 

So far, then, I think your suggestions are just fine, IMO.

 

How about when considering the implementation point of view? Did you assume
that the application layer is going to implement the random number generator
(RNG) and the store of N1, N2, . corresponding to TLS handshake H1, H2, . in
a "hardened" way?

 

Where I'm headed with this is to suggest that the implementation would be
best if you used some existing TLS implementation for the RNG. To explain,
I'd start by observing that NIST SP800-90A approves of two DRBG's: AES and
SHA. If you seed them properly, these functions will do the job very well.
Should the application layer implement SHA? Not if the TLS layer already has
done so. And how should it be seeded? The TLS layer already does this very
well - using two computers' contributions toward entropy instead of just
one, which is a higher bar than most applications like to hit. And how
should the relation between N1, N2, . and H1, H2, . be implemented? The TLS
layer already does this quite well (each TLS session state includes the
running hash I suggested, on a per-handshake basis). If you grant that TLS
does a nice job of seeding and maintaining a DRBG on a per-session basis,
then should the TLS layer or the application layer reach into the TLS state
structures and duplicate the current hash state and finalize it into a hash
output?

 

Because problems with weak RNGs implemented by non-crypto developers are
historically problematic, I'd recommend sticking with the running handshake
message hash as the RNG for this application of tls_authz. Then you could be
quite sure your validation step (in 3) would be quite strong for years to
come. 

 

--mark

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Darshak Thakore
Sent: Sunday, January 27, 2013 7:12 PM
To: [e-mail]
Subject: Re: [TLS] new version of draft-dthakore-tls-authz

 

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]>
Date: Thursday, January 24, 2013 2:42 PM
To: Darshak Thakore <[e-mail]>, "[e-mail]" <[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_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