Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt]

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 8 Oct 2009 12:04:11 -0400

I don't think I understand you.

Are you implying that CA-certified certs are less secure than self-signed ones?! Or that getting your TPM-provided Public Key signed by a CA lessens its security?

And how can self-signed certs be possibly bound to "identity certs signed by a CA"?

I still don't understand your justification (or reasons) for mucking with a perfectly usable TLS model.

Perhaps you'd want to describe in a few sentences what it is that you're trying to accomplish with TPM-generated public keys, and how TLS as-is does not allow that? And why what you're trying to do would of interest to anybody else on the planet who uses TPM and/or TLS?

----- Original Message -----
From: Carolin Latze <[email-masked]>
To: Blumenthal, Uri
Sent: Thu Oct 08 04:02:09 2009
Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt]

They are still valid X.509... the only difference is that they are
self-signed and not CA-signed. And the reason to use self-signed
certificates is that you don't need to send another certificate request
without loosing security since the self-signed certificates are bound to
identity certificates that are signed by a CA.

Blumenthal, Uri wrote:
> And the reason you want to do this instead of using valid X.509 certs is...?
>
>
> ----- Original Message -----
> From: [email-masked] <[email-masked]>
> To: [email-masked] <[email-masked]>
> Sent: Wed Oct 07 11:16:52 2009
> Subject: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt]
>
> Hi all,
>
> after several experiments with TPMs as authentication devices in
> EAP-TLS, we figured out, that the specific modifications in order to use
> TPMs might be rather an extension to TLS than an EAP extension.
> Therefore, we gave it a try and defined a new TLS extension in order to
> use TPM certified keys directly with TLS. We are aware of the fact, that
> there is a possibility to request new valid X.509 certificates for those
> keys which allows to use them with standard TLS (and do not require a
> new extension), but since we want to avoid that request (and we think
> that this does not introduce any security issues), we propose this
> extension.
>
> We are always open for discussions, (critical) feedback, suggestions, ...
>
> Regards
> Carolin Latze
>
>
> -------- Original Message --------
> Subject: 	{Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt
> Date: 	Wed, 7 Oct 2009 16:45:01 +0200
> From: 	[email-masked] <[email-masked]>
> Reply-To: 	[email-masked] <[email-masked]>
> To: 	[email-masked] <[email-masked]>
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : Transport Layer Security (TLS) Extensions for the Trusted Platform Module (TPM)
> 	Author(s)       : C. Latze, et al.
> 	Filename        : draft-latze-tls-tpm-extns-00.txt
> 	Pages           : 10
> 	Date            : 2009-10-07
>
> Trusted Platform Modules (TPMs) become more and more widespread in
> modern desktop and laptop computers and provide secure storage and
> cryptographic functions.  As one nice feature of TPMs is that they
> can be identified uniquely, they provide a good base for device
> authentication in protocols like TLS.This document specifies a TLS
> extension that allows to use TPM certified keys with TLS in order to
> allow for a secure and comfortable device authentication in TLS.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-latze-tls-tpm-extns-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
>
>   

-- 
Carolin Latze
PhD Student				ICT Engineer

Department of Computer Science		Swisscom Strategy and Innovation
Boulevard de Pérolles 90		Ostermundigenstrasse 93
CH-1700 Fribourg      			CH-3006 Bern
	
phone: +41 26 300 83 30			+41 79 72 965 27
homepage: http://diuf.unifr.ch/people/latzec

---

From: Carolin Latze <[email-masked]>
Date: Fri, 09 Oct 2009 10:05:09 +0200

Ok,

> Are you implying that CA-certified certs are less secure than self-signed ones?! Or that getting your TPM-provided Public Key signed by a CA lessens its security?
[CL] No, nothing like that. I think my english might be a problem, but I
try to explain what I mean:

TPMs come with the possibility to create so called attestation identity
keys (AIKs) that will be signed by a certain certificate authority
called Privacy CA  resulting in an AIK certificate. The process of
signing by the Privacy CA includes verifying that those keys have been
generated by a genuine TPM. The private part of the AIK never leaves the
TPM, which means that the AIK certificates prove that they belong to a
genuine, given TPM. The AIK certificate is a valid X.509 certificate,
which can be verified using the standard X.509 verification functions.
So if you use those certificates in authentication protocols you can
authenticate devices (using their TPM). But, unfortunatly, those keys
have some restrictions which makes it impossible to use them in TLS
direclty:

1) they are restricted to SHA-1 signing (well, that should not be a
problem with TLS 1.2)
2) they only sign data that originates in the TPM (that means in order
to use them with TLS, every data that has to be signed has to originate
in the TPM, which is not impossible and might be useful in some cases,
but is rather complicated)

In order to be able to use something like the AIKs in authentication,
the TPM standard propose to define new keys (with the property that the
private part never leaves the TPM) and sign them using the AIK. That
signing process is also defined in the standard and results in a special
structure called TCPA_CERTIFY_INFO. That structure proves that a
certified key has been signed by a valid AIK, which itself can be
verified using standard X.509 verification techniques. Unfortunatly,
TCPA_CERTIFY_INFO does not have the same format like X.509. The
certified key could be used in TLS directly, but how do we verify that
it belongs to a given TPM? There are several solutions that all rely on
the fact, that the AIK certificate proves that this certificate key
belongs to a genuine, given TPM:

1) Make it an X.509 certificate signed by the AIK (=> results in
complete easy to verify chain). This is not possible since the AIK
certificate carries the CA:false constraint.
2) Make it an X.509 proxy certificate of the AIK. Not possible since the
subject of the AIK is NULL.

Those would be the easy possibilities, but since they do not work, the
TCG defined a new X.509 extension to carry the TCPA_CERTIFY_INFO
structure called SKAE. Again two possibilities arise to make use of that
extension:

1) Generate a new X.509 certificate request around the certified key,
include the SKAE extension, and send the request to a CA to sign it.
This results in a standard X.509 certificate that can be used for TLS.
But if the server wants to ensure that this certificate is bound (= the
private key never leaves the TPM) to a certain genuine TPM, he has to
verify the SKAE extension too. That means he has to get the AIK
certificate too, which is not part of the chain. The SKAE extension
carries a hint where to find that certificate.  Now my opinion to that
approach: A second certificate request is needed (apart from the AIK
certificate request needed anyway), which is overkill (just my opinion,
I know, that other people do not have a problem with that) and - and
thats the bigger problem from my point of view - if the server really
wants to verify that the keys originates from a given, genuine TPM, he
has to download, request, get ... the AIK in addition to what he gets
out of the TLS handshake. So there has to be some kind of storage for
the AIK certificates, that either sends the AIK certificates to all the
servers or receives SKAE extensions from servers to validate them. I
think that might result in scalability problems (just my opinion).
2) Generate an X.509 self-signed certificate around the certified key
including the SKAE extension, use it in the handshake and send the AIK
certificate that verifies the SKAE extension within the supplemental
data handshake message. I think that approach has a better scalability.

BTW: Everything I described above is only needed if you want to use
those special keys. If you only want to use the TPM as a key storage and
secure provider for functions like signing etc, there is no need for any
modification to TLS and X.509. The reason why I want to use those
special keys is that they are available and have those nice properties
of being (provable) bound to a genuine, given TPM. If you ask me now to
ignore those keys if they introduce those difficulties then I think that
is a valid conclusion. I only think that there should be a possibility
to use them if they are available.
> And how can self-signed certs be possibly bound to "identity certs signed by a CA"?
[CL] Using that SKAE extension explained above.
> I still don't understand your justification (or reasons) for mucking with a perfectly usable TLS model.
[CL] I think I tried to explain that above
> Perhaps you'd want to describe in a few sentences what it is that you're trying to accomplish with TPM-generated public keys, and how TLS as-is does not allow that? And why what you're trying to do…
[CL] I think I tried to explain that too. I think, AIKs and certified
keys are a good possibility to authentication TPM equipped devices even
if they introduce some difficulties. But I also see the problem that TLS
has been available much longer than TPMs, so it would have been easy to
adapt the TPM to TLS needs instead to do it vice versa. I have not been
part of the TPM standardization although I try to discuss with TCG
people too. There might be good reason for the things they defined that
I do not see at the moment. And since TPMs are already shipped with all
the features described above I try to make it usable like that.

---

From: <[email-masked]>
Date: Wed, 14 Oct 2009 13:08:21 +0200

TCG-compliant AIK Certificates are pretty much useless for authenticating
devices, since the whole point of Privacy CA and AIK Certificates is to 
hide the real device identity/identifier for privacy purposes.
A valid AIK Credential asserts that the AIK private key is in *some*
genuine conforming TPM, but doesn't really contain device identifiers 
that would be useful for authentication of a specific device. 

IMHO situations where you'd want to allow access to anyone who has
a genuine TPM (but nobody else) are pretty rare... (and would 
probably involve a "remote attestation" about what software the
device is currently running -- so don't really belong in TLS anyway).

Best regards,
Pasi
(not wearing any hats)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Carolin Latze
> Sent: 09 October, 2009 11:05
> To: Blumenthal, Uri
> Cc: [email-masked]'
> > Are you implying that CA-certified certs are less secure than self-
> signed ones?! Or that getting your TPM-provided Public Key signed by a
> CA lessens its security?
> >
> > Perhaps you'd want to describe in a few sentences what it is that
> you're trying to accomplish with TPM-generated public keys, and how TLS
> as-is does not allow that? And why what you're trying to do would of
> interest to anybody else on the planet who uses TPM and/or TLS?
> >
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Carolin Latze <[email-masked]>
Date: Wed, 14 Oct 2009 15:58:39 +0200

[email-masked] wrote:
> a genuine TPM (but nobody else) are pretty rare... 
[CL] At the moment, yes. But that might change in the future. I can
imagine scenarios, where it is sufficient to know that the client device
has a genuine TPM. Further remote attestation might follow later (or
might not be necessary). Maybe it is sufficient, that the client has an
AIK from a certain Privacy CA, because I, as a server, trust that
Privacy CA, and since the client has a genuine TPM, I also know that the
certificate really belongs to him (private key has not been copied to
other machine etc). I can also imagine scenarios, where you bind a
person to a device by contract or a scenario where you sell/provide
devices that should be able to connect to your TLS secured services, so
maybe, you run a Privacy CA yourself.... For me that depends on the
business case itself.... (and I can also imagine scenarios, where it
does not make any sense at all :-)).
> (and would 
>>> And how can self-signed certs be possibly bound to "identity certs
>>>       
>> signed by a CA"?
>>     
>>> I still don't understand your justification (or reasons) for mucking
>>>       
>> with a perfectly usable TLS model.
>>     
>>> Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-
>>>       
>> extns-00.txt]
>>     
>>> certificates is that you don't need to send another certificate
>>>       
>> request
>>     
>>> without loosing security since the self-signed certificates are bound
>>>       
>> to
>>     
>>>> And the reason you want to do this instead of using valid X.509
>>>>         
>> certs is...?
>>     
>>>> Subject: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-
>>>>         
>> 00.txt]
>>     
>>>> Hi all,
>>>>
>>>> EAP-TLS, we figured out, that the specific modifications in order to
>>>>         
>> use
>>     
>>>> Therefore, we gave it a try and defined a new TLS extension in order
>>>>         
>> to
>>     
>>>> use TPM certified keys directly with TLS. We are aware of the fact,
>>>>         
>> that
>>     
>>>> there is a possibility to request new valid X.509 certificates for
>>>>         
>> those
>>     
>>>> keys which allows to use them with standard TLS (and do not require
>>>>         
>> a
>>     
>>>> new extension), but since we want to avoid that request (and we
>>>>         
>> think
>>     
>>>> We are always open for discussions, (critical) feedback,
>>>>         
>> suggestions, ...
>>     
>>>> Regards
>>>> Carolin Latze
>>>>
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>         
>> directories.
>>     
>>>> 	Title           : Transport Layer Security (TLS) Extensions for
>>>>         
>> the Trusted Platform Module (TPM)
>>     

-- 
Carolin Latze
PhD Student				ICT Engineer