Re: [TLS] New Authz extension to use DTCP certificates in TLS SD handshake message

[Darshak Thakore <[e-mail]>]

Hi Mark,
Thanks a lot for the review. This was exactly the feedback i was looking for. I will incorporate your points in the I-D and upload a new version in the next couple of days.
I've also attempted to clarify some of the points below.


From: Mark Brown <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, November 7, 2012 2:55 PM
To: Darshak Thakore <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [TLS] New Authz extension to use DTCP certificates in TLS SD handshake message

Darshak,
I have feedback and questions for you ranging from details to requirements. I did a quick scan of the DTCP and DTCP-IP documents, and I may have misunderstood them at places. I suspect that others on this TLS list might not want to invest a lot of time doing the same. You might refer to DTCP’s relevant sections more specifically (and at relevant places in your ID) to ease the recruitment of TLS readers.

DT>> I will update the I-D to reference the relevant sections from the DTCP specs



1. Section (3.2) What *should* be signed and why? Struct “dtcp_authz_data” does not contain a *signed* nonce, but simply concatenates it with the signed struct. Did you want to ensure freshness / avoid replay attacks, or am I misunderstanding your purpose? This purpose should be clarified in your ID.

DT>> The intent here is to cryptographically tie the DTCP certificate with the X.509 certificate of the sender in order to avoid replay and MITM attacks. Since this data will be going in the clear (within the SupplementalData handshake message) this structure contains the {DTCP Certificate, X.509 Certificate} and a signature covering both the elements that allows the receiver to verify that the possessor of the X.509 certificate is also the possessor of the DTCP Certificate. The signature will be generated using the private key associated with the DTCP certificate. I will update this section and try to clarify this.




2. Section (1) Regarding why you are using TLS and AUTHZ, your introduction raises more questions than it answers for me, even though I suspect that content protection and authorizations go together at a high level. First, IMHO, the DTCP and DTCP-IP documents seem to have a lot of overlap with the basic motivations for an encryption protocol, which is what TLS provides too. So, why two similar protocols? Is your goal primarily to tunnel the DTCP protocol within the TLS protocol? While authorization can be understood in several ways, protocol tunneling is a not typical meaning for authorization. Or is the primary goal to “determine the type of protected data to be exchanged”? If so, please describe the authorization decision that might take place in this determination, and document the semantics of “access_denied” alert messages for your authorizations.

DT>> That's a great question and goes to the heart of this proposal. No, the intent here is not to tunnel the DTCP-IP encryption protocol thru TLS. In fact the intent is to avoid the DTCP encryption protocol (specified as AKE – Authentication Key Exchange) since DTCP AKE is meant for content protection only and has limited use. The intent is to reuse the DTCP certificates as additional authorization data in a TLS handshake. As i had very briefly mentioned in the presentation, the devices that contain these DTCP certificates are becoming web enabled and have full HTML5 User Agents on them. When these devices are being used to access services over https, if a server can verify that the devices posses a valid DTCP certificate, then it can provide web enabled services to these devices that it would not typically provide to a normal user agent. A server would typically not deny access completely to a device that does not provide a DTCP certificate but may not provide a full spectrum of services.





3. Section (1): Which security/encryption features do you need? DTCP seems to require mutual authentication (my quick read is that it always uses EC Difffie Hellman key agreement between two non-X.509 certificates under a DTLA-lite certificate authority [CA]). However, DTCP does not provide TLS’s flexibility and it uses mismatched key strengths (80bit EC vs. 128 bit AES, see, e.g. http://www.nsa.gov/business/programs/elliptic_curve.shtml ). Asking, “Why use TLS at all?” might help clarify. Are you interested in the flexibility or strength of its ciphersuites, or its history of vulnerability and protocol analysis, or its history of standard use?  If so, which protocol’s session keys and encryptors will you use, and what do the keys mean to the overall security argument? Why does the DTCP certificate need to be “cryptographically tied to the X.509 certificate being used during the TLS [handshake]”?  Why not create the X.509 cert already bound to the DTCP cert? I think you should clarify your purpose and then document it in a revised Introduction.

DT>> To answer "Why use TLS at all?", its all of the above that you mentioned plus the fact that its defacto for http traffic. The session keys and encryptors will be used as per TLS.  The reason the DTCP certificate needs to be cryptographically tied to the X.509 certificate is to avoid MITM attack since the DTCP certificate is easily accessible. The idea here is to use DTCP certificate as additional authorization that entitles the device to receive additional services




4. Regarding DTCP nonstandard certificates (4.2.3.1, Fig 7) vs. X.509 certificates: IMHO, and perhaps DTCP agrees, ASN.1 BER/DER seems like language overkill for simple certs. Parsing ASN.1 found in Certificate handshake messages is an arcane, complex, software-oriented, and risky (read: pointer-arithmetic-rich) operation that can mix up tasks of first-time validation with every-time verification. But if you plan on generating both a DTLA certificate and an X.509 certificate for the same keypair, then you might consider simply using the existing TLS client (mutual) authentication instead of separately signing just your authorization token. Just look at the CertificateVerify (CV) message already defined for TLS, which runs a hash over the client’s and the server’s nonces, the rest of the handshake, and your SupplementalData, then signs. If you use the existing TLS CV message, then your DTCP protocol should be able to offload the standardized certificate validations onto the TLS protocol, for which ASN.1 parsers are already present in implementations, including management of the CA lists and OCSP checking.

DT>> We would not be generating a DTLA certificate and X.509 certificate for the same key pair (i wish… :). In fact the X.509 certificate will very likely be totally independent of the DTCP certificate (the client may not even use an X.509 certificate in which case there won't be any CV message). The proposal here is to exchange the DTCP certificates with minimal impact to the TLS semantics and that's why the use of SupplementalData is attractive since it puts the onus of processing the authorization data at the application layer.

I hope that provides some clarification. Once again thanks a lot for the feedback and i look forward to answering more questions

Regards,
Darshak Thakore



From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Darshak Thakore
Sent: Tuesday, November 06, 2012 10:09 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [TLS] New Authz extension to use DTCP certificates in TLS SD handshake message

Folks,
I am sending this email to obtain feedback and guidance on the following I-D, which proposes a new Authorization Data Format to the TLS SupplementalData Handshake extension to use DTCP certificates as authorization data. If this WG is not the forum to seek feedback on this proposal, please redirect me accordingly.

http://tools.ietf.org/html/draft-dthakore-authz-01

>From the Abstract:

  "This document specifies the use of DTCP certificate as an

   authorization extension in the Transport Layer Security Handshake

   Protocol, according to guidelines in RFC 5878.  Extensions carried in

   the client and server Hello messages confirm that both parties

   support the desired authorization data types.  Then if supported by

   both the client and server, DTCP certificates are exchanged in the

   supplemental data handshake TLS handshake message as specified in

   RFC4680."

Thanks in advance

Regards,

Darshak Thakore