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

<Pasi.Eronen@nokia.com> Wed, 14 October 2009 11:08 UTC

Return-Path: <Pasi.Eronen@nokia.com>
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 5B68C3A69AD for <tls@core3.amsl.com>; Wed, 14 Oct 2009 04:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.272
X-Spam-Level:
X-Spam-Status: No, score=-6.272 tagged_above=-999 required=5 tests=[AWL=-0.273, 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 yZcXL0rc1fAJ for <tls@core3.amsl.com>; Wed, 14 Oct 2009 04:08:32 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 47F823A6997 for <tls@ietf.org>; Wed, 14 Oct 2009 04:08:31 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9EB8IjQ006933; Wed, 14 Oct 2009 14:08:28 +0300
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 14:08:27 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 14:08:22 +0300
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 14 Oct 2009 13:08:21 +0200
From: <Pasi.Eronen@nokia.com>
To: <carolin.latze@unifr.ch>, <uri@ll.mit.edu>
Date: Wed, 14 Oct 2009 13:08:21 +0200
Thread-Topic: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt]
Thread-Index: AcpIt3HuwwDn9kfTQ4OZEzl2dElcHQEBdyiQ
Message-ID: <808FD6E27AD4884E94820BC333B2DB773C099FDECA@NOK-EUMSG-01.mgdnok.nokia.com>
References: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BC8@LLE2K7-BE01.mitll.ad.local> <4ACEEEB5.9000803@unifr.ch>
In-Reply-To: <4ACEEEB5.9000803@unifr.ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 14 Oct 2009 11:08:22.0783 (UTC) FILETIME=[A4EAD0F0:01CA4CBE]
X-Nokia-AV: Clean
Cc: 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: Wed, 14 Oct 2009 11:08:33 -0000

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: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
> ext Carolin Latze
> Sent: 09 October, 2009 11:05
> To: Blumenthal, Uri
> Cc: 'tls@ietf.org'
> Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-
> 00.txt]
> 
> 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.
> >>
> >>
> >>
> >>
> >>
> >
> >
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls