Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt]
Carolin Latze <carolin.latze@unifr.ch> Wed, 14 October 2009 14:00 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 7106B3A6A03 for <tls@core3.amsl.com>; Wed, 14 Oct 2009 07:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level:
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[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 9oyeH-1gJiin for <tls@core3.amsl.com>; Wed, 14 Oct 2009 07:00:55 -0700 (PDT)
Received: from sr-svx-320.unifr.ch (sr-svx-320.unifr.ch [134.21.214.75]) by core3.amsl.com (Postfix) with ESMTP id 6B7CF3A691B for <tls@ietf.org>; Wed, 14 Oct 2009 07:00:55 -0700 (PDT)
Received: from diufpc272.unifr.ch ([134.21.72.156]) by sr-svx-320.unifr.ch stage1 with esmtp with id 1My4PB-0006e8-TQ for <tls@ietf.org> from <carolin.latze@unifr.ch>; Wed, 14 Oct 2009 16:00:41 +0200
Message-ID: <4AD5D90F.4000005@unifr.ch>
Date: Wed, 14 Oct 2009 15:58:39 +0200
From: Carolin Latze <carolin.latze@unifr.ch>
User-Agent: Thunderbird 2.0.0.23 (X11/20090916)
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
References: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BC8@LLE2K7-BE01.mitll.ad.local> <4ACEEEB5.9000803@unifr.ch> <808FD6E27AD4884E94820BC333B2DB773C099FDECA@NOK-EUMSG-01.mgdnok.nokia.com>
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773C099FDECA@NOK-EUMSG-01.mgdnok.nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
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 14:00:57 -0000
Pasi.Eronen@nokia.com wrote: > 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... [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 > 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 >> -- 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
- [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-t… Carolin Latze
- Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-t… Blumenthal, Uri
- Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-t… Eric Rescorla
- [TLS] [Fwd: Re: [Fwd: {Virus?} I-D Action:draft-l… Carolin Latze
- Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-t… Blumenthal, Uri
- Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-t… Carolin Latze
- Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-t… Pasi.Eronen
- Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-t… Carolin Latze