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

Carolin Latze <carolin.latze@unifr.ch> Fri, 09 October 2009 08:04 UTC

Return-Path: <carolin.latze@unifr.ch>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8058428C1D8 for <tls@core3.amsl.com>; Fri, 9 Oct 2009 01:04:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.048
X-Spam-Level:
X-Spam-Status: No, score=-6.048 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxE7I7GEO1KZ for <tls@core3.amsl.com>; Fri, 9 Oct 2009 01:04:46 -0700 (PDT)
Received: from siufsrv104.unifr.ch (siufsrv104.unifr.ch [134.21.214.74]) by core3.amsl.com (Postfix) with ESMTP id B4BA428C1D1 for <tls@ietf.org>; Fri, 9 Oct 2009 01:04:45 -0700 (PDT)
Received: from diufpc272.unifr.ch ([134.21.72.156]) by siufsrv104.unifr.ch stage1 with esmtp with id 1MwAUU-0005c9-FE from <carolin.latze@unifr.ch>; Fri, 09 Oct 2009 10:06:18 +0200
Message-ID: <4ACEEEB5.9000803@unifr.ch>
Date: Fri, 09 Oct 2009 10:05:09 +0200
From: Carolin Latze <carolin.latze@unifr.ch>
User-Agent: Thunderbird 2.0.0.23 (X11/20090916)
MIME-Version: 1.0
To: "Blumenthal, Uri" <uri@ll.mit.edu>
References: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BC8@LLE2K7-BE01.mitll.ad.local>
In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BC8@LLE2K7-BE01.mitll.ad.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "'tls@ietf.org'" <tls@ietf.org>
Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2009 08:04:47 -0000

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 would of interest to anybody else on the planet who uses TPM and/or TLS?
>   
[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.
>
> ----- Original Message -----
> From: Carolin Latze <carolin.latze@unifr.ch>
> 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: tls-bounces@ietf.org <tls-bounces@ietf.org>
>> To: tls@ietf.org <tls@ietf.org>
>> 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: 	Internet-Drafts@ietf.org <Internet-Drafts@ietf.org>
>> Reply-To: 	internet-drafts@ietf.org <internet-drafts@ietf.org>
>> To: 	i-d-announce@ietf.org <i-d-announce@ietf.org>
>>
>>
>>
>> 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.
>>
>>
>>
>>   
>>     
>
>