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

[Darshak Thakore <[e-mail]>]

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" <[e-mail]> wrote:

>On 01/24/2013 06:56 PM, Darshak Thakore wrote:
>
>> 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.
>
>
>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
>_______________________________________________
>TLS mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tls