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

From: Darshak Thakore <[email-masked]>
Date: Thu, 24 Jan 2013 17:56:52 +0000

Hello all,

I have uploaded a new version of the draft that specifies a new SupplementalData authorization extension to exchange DTCP Certificates.
This version addresses a number of comments that were received during the IETF-85 meeting and subsequently on the mailing list.

The following points are addressed in the new draft

  1.  Added details about the format of DTCP Certificates and provided section references to the DTCP Specs. This should help readers navigate to the relevant parts of the DTCP Spec more easily since most of the information in the DTCP Specs is irrelevant to this I-D (besides the actual DTCP certificate details)
  2.  Added a section to explain the use cases for this TLS extension and how it allows devices with existing DTCP Certificates to leverage it for different uses (besides its use and independent of its use for content protection)
  3.  Provided clarification that this extension is only meant to exchange DTCP certificates as additional authorization information during a TLS exchange. It is *not* meant to tunnel any secondary protocol within TLS, nor does it replace the role of X.509 certificates in the TLS protocol
  4.  Provided clarification in Section 3.2 about the dtcp_authz_data stuct

I would greatly appreciate any comments/feedback on it.

Best Regards,
Darshak

---

From: "Mark Brown" <[email-masked]>
Date: Thu, 24 Jan 2013 15:42:18 -0600

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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 25 Jan 2013 11:56:53 +0100

> I would greatly appreciate any comments/feedback on it.

Some comments:
1. What is the [[]] notation?

You use it in:
         struct {
             opaque DTCPCert<1..2^24-1>;
             [[opaque ASN.1Cert<1..2^24-1>]];
             opaque signature<1..2^16-1>;
         } DigitallySigned;
and later you mention that the certificate is optional. If you want to
make the certificate optional you do:
         struct {
             opaque DTCPCert<1..2^24-1>;
             opaque ASN.1Cert<0..2^24-1>;
             opaque signature<1..2^16-1>;
         } DigitallySigned;

Otherwise your structure cannot be parsed (TLS structures are different
from ASN.1).

2. How does the random nonce protect from replay attacks? My I
understanding is that it isn't used at all. What kind of replay attacks
are you considering at? Why use a new nonce and not the TLS nonces?

3. One cannot get an overview of your additions. I'd suggest another
figure, similar to figure 1, that will focus on the exchange that is
relevant only for your extension (that way it would be apparent what you
are protecting with the nonce).

e.g.
        ClientHello (with client_authz) -------->

                                       ServerHello(with server_authz)
                                             SupplementalData (with ???)

4. You say "cryptographically tie its dtcp_authz_data with the TLS
session being established."

How do you mean by cryptographically tie? (usually such a phrase implies
a commitment - e.g., a signature))

regards,
Nikos

---

From: Darshak Thakore <[email-masked]>
Date: Mon, 28 Jan 2013 01:12:05 +0000

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;

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

                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.:

         struct {

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

---

From: Darshak Thakore <[email-masked]>
Date: Mon, 28 Jan 2013 01:40:43 +0000

Hi Nikos,

On #1, Yes the intent of the [[]] was to make the certificate optional.
Thanks for the suggestion, i've changed that and will get reflected in the
next draft.

On #2, In my earlier response to Mark's comments, i provided a sample TLS
exchange that shows how the nonce is used. The reason a separate nonce is
specified is because an application that is generating the
SupplementalData payload may not have access to the TLS nonces. The server
generates the nonce and the client will include it in its dtcp_authz_data
payload. With the update mentioned in the earlier email, the signature
that the client includes in its SupplementalData message will cover the
nonce also along with its DTCP Cert and the optional X.509 cert.

On #3, I can include a figure that demonstrates the example exchange i
included earlier. Should something like that go into the appendix?

On #4, When a client sends a SupplementalData payload like [(Nonce, DTCP
Cert, X.509 Cert) Signature covering the three elements] followed by a
Certificate message that includes the same X.509 Cert used above, a server
can verify that the possessor of the X.509 Certificate also posseses the
DTCP Cert (proven by the Signature above generated using the private key
associated with the DTCP Cert).

Regards,
Darshak 

On 1/25/13 3:56 AM, "Nikos Mavrogiannopoulos" <[email-masked]> wrote:

>> I have uploaded a new version of the draft that specifies a new
>>SupplementalData authorization extension to exchange DTCP Certificates.
>> This version addresses a number of comments that were received during
>>the IETF-85 meeting and subsequently on the mailing list.
>> 
>>   1.  Added details about the format of DTCP Certificates and provided
>>section references to the DTCP Specs. This should help readers navigate
>>to the relevant parts of the DTCP Spec more easily since most of the
>>information in the DTCP Specs is irrelevant to this I-D (besides the
>>actual DTCP certificate details)
>>   2.  Added a section to explain the use cases for this TLS extension
>>and how it allows devices with existing DTCP Certificates to leverage it
>>for different uses (besides its use and independent of its use for
>>content protection)
>>   3.  Provided clarification that this extension is only meant to
>>exchange DTCP certificates as additional authorization information
>>during a TLS exchange. It is *not* meant to tunnel any secondary
>>protocol within TLS, nor does it replace the role of X.509 certificates
>>in the TLS protocol
>_______________________________________________
>TLS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tls

---

From: "Mark Brown" <[email-masked]>
Date: Mon, 28 Jan 2013 14:56:49 -0600

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Darshak Thakore
Sent: Sunday, January 27, 2013 7:12 PM
To: [email-masked]
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.

      struct {          

          opaque random_bytes[32];

      } RandomNonce;

      struct {

          RandomNonce nonce; 

      } 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.

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

Regards,

Darshak

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

Hi Darshak,

         struct {

         } DTCPClientAssertion;

         struct {

         } dtcp_authz_data;

Sincerely,

mark