Network Working Group                                           C. Latze
Internet-Draft                                          U. Ultes-Nitsche
Intended status: Experimental                     University of Fribourg
Expires: January 28, 2010                                 F. Baumgartner
                                                     Swisscom Schweiz AG
                                                           July 27, 2009

 Extensible Authentication Protocol Method for Trusted Computing Groups
                     (TCG) Trusted Platform Modules

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 28, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Latze, et al.           Expires January 28, 2010                [Page 1]

Internet-Draft                   EAP-TPM                       July 2009


   This document describes an Extensible Authentication Protocol (EAP)
   [RFC3748] method for identity distribution, authentication and
   session key distribution using the Trusted Computing Group's (TCG)
   Trusted Platform Module (TPM).  The TPM has been defined by the TCG
   in order to establish a root of trust and measurements in (consumer)
   computers.  It provides several cryptographic functions and a secure
   storage for keys and hashes.  There is also a TPM specification for
   mobile devices called Mobile Trusted Module (MTM), which can also be
   used for EAP-TPM.  This new EAP method allows network authentication,
   which also supports user anonymity, the usage of different user
   identities for the authentication with different network operators,
   result indication, and a fast re-authentication.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  3
   3.  Terms and Abbreviations  . . . . . . . . . . . . . . . . . . .  3
   4.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Client Certificates  . . . . . . . . . . . . . . . . . . . . .  4
   6.  Authentication . . . . . . . . . . . . . . . . . . . . . . . .  5
     6.1.  Authentication without Zero-Configuration  . . . . . . . .  5
     6.2.  Authentication with Zero-Configuration . . . . . . . . . .  7
   7.  Failure, Fragmentation and Fast Re-Authentication  . . . . . .  9
   8.  Key Derivation . . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   11. Normative References . . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

Latze, et al.           Expires January 28, 2010                [Page 2]

Internet-Draft                   EAP-TPM                       July 2009

1.  Introduction

   This document specifies a new Extensible Authentication Protocol
   (EAP) [RFC3748] method based on Trusted Platform Modules (TPMs).
   TPMs are hardware chips attached to the motherboard of the majority
   of newly shipped computers.  They provide small secure storage,
   cryptographic functions and a root of trust and measurement.  In
   addition to TPMs there are also Mobile Trusted Modules (MTMs) that
   provide a subset of the TPMs functionality and are meant to be built
   into mobile handsets like mobile phones.

   TPMs/MTMs can be identified uniquely all over the world and may
   obtain an identity certificate that proofs that it comes from a
   genuine TPM/MTM.  Therefore, TPMs/MTMs are perfectly suited for
   certificate based authentication schemes.

   EAP-TPM provides support for different user identities which allows
   the user to hide its original identity at the authenticator as
   requested in [RFC4017].  Furthermore, it provides a zero-
   configuration mode where the user does not need to request any
   identity before authenticating to an EAP-TPM secured authenticator.

   EAP-TPM should be understood as a more comfortable but not less
   secure EAP-TLS.

2.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an

3.  Terms and Abbreviations

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

   Furthermore, this document uses the following terms and


      The EAP authentication server, that does the real authentication
      of the peer.

Latze, et al.           Expires January 28, 2010                [Page 3]

Internet-Draft                   EAP-TPM                       July 2009


      EAP-Peer - the one who wants to be authenticated.


      Mobile Trusted Module as specified in [MTMSpec]


      Trusted Platform Module as specified in [TCGMainSpec]


      EAP-Peer - the one who wants to be authenticated.

4.  Motivation

   EAP-TPM has the goal to make a secure authentication protocol like
   EAP-TLS more userfriendly without weakening its security.  EAP-TLS
   [RFC5216] as it is provides mutual authentication but requires the
   client to request its own valid X.509 certificates.  Two problems
   arise with that approach: First of all, the user has to be capable to
   request a certificate, which is a non-trivial task; second the user
   has to know the acceptable Certificate Authorities (CAs) in advance
   which is a strong constraint for a real world setup.  Therefore, the
   motivation for EAP-TPM was to develop an EAP method that is as
   secure, scalable, and automatable as EAP-TLS and comfortable in its
   usage for a naive "normal" user.

5.  Client Certificates

   The process of retrieving TPM certificates starts with retrieving an
   identity certificate as specified in the TCG Main Specification

   1.  The TPM has to create a new identity certificate request using
       TPM_MakeIdentity, which generates a new identity key that has to
       be signed by a Privacy CA.

   2.  The Trusted Subsystem (TSS) has to collect all the information
       needed by the Privacy CA to certify the formerly created identity
       key.  According to the TPM Main Specification, that function is
       called TSS_CollateIdentityRequest.

Latze, et al.           Expires January 28, 2010                [Page 4]

Internet-Draft                   EAP-TPM                       July 2009

   3.  This request will be sent to the Privacy CA, which verifies all
       the data and certifies the key and replies with an identity

   4.  The TPM will now activate the new identity using

   5.  Finally, the TSS has to retrieve a plain text copy of the new
       identity certificate using TSS_RecoverTPMIdentity.

   The detailed process is described in [TCGMainSpec] and not part of
   this document.

   According to [TCGMainSpec] those certificates are special purpose
   certificate, restricted to SHA-1 signing and MUST have the CA:false
   constraint.  As TLS only uses standards signature from version 1.2 on
   [RFC5246], EAP-TPM MUST be used with TLS 1.2.

6.  Authentication

   Authentication in EAP-TPM can be divided into authentication without
   zero-configuration, where the user MUST request his certificate(s)
   before connecting to an EAP-TPM authenticator, and authentication
   with zero-configuration, where the user will get a certificate during
   the authentication process.  The first scenario described in
   Section 6.1 is more suitable for an operator controlled setup with
   accounting as it allows to register certificates with users, whereas
   the second scenario described in Section 6.2 is more suitable for
   corporate environments or environment without accounting in general.

6.1.  Authentication without Zero-Configuration

Latze, et al.           Expires January 28, 2010                [Page 5]

Internet-Draft                   EAP-TPM                       July 2009

          --------                           -----------------
          | Peer |                           | Authenticator |
          --------                           -----------------

          (includes user's NAI)
          TPM client_hello
                                        TPM server_hello,
                                        TPM certificate,
                                        [TPM server_key_exchange,]
                                        TPM certificate_request,
                                        TPM server_hello_done
          TPM certificate,
          TPM client_key_exchange,
          TPM certificate_verify,
          TPM change_cipher_spec,
          TPM finished
                                        TPM change_cipher_spec,
                                        TPM finished

         Figure 1: Successful EAP-TPM Authentication With Existing

   Figure 1 shows the full authentication using EAP-TPM in case the peer
   could be authenticated successfully.  The authentication with already
   existing certificates is very similar to EAP-TLS [RFC5216]:

   The authentication will start with the authenticator asking the peer
   for its identity sending EAP-Request/Identity.  The peer will answer
   with EAP-Response/Identity containing his Network Address Identifier
   (NAI) [RFC4282].  Afterwards the authenticator sends the EAP-Request/

Latze, et al.           Expires January 28, 2010                [Page 6]

Internet-Draft                   EAP-TPM                       July 2009

   TPM/Start message to indicate the real beginning of EAP-TPM, which
   will be followed by a normal TLS handshake.

   Finally the EAP authentication is closed with EAP-Response/TPM sent
   by the client and EAP-Success sent by the authenticator.

6.2.  Authentication with Zero-Configuration

   Section 6.1 requires valid certificates on the client before starting
   the authentication.  This section deals with authentication without
   existing certificates.  The peer tries to authenticate to an
   authenticator starting as described in Section 6.1.  During the
   authentication, the authenticator has to send a TPM
   certificate_request message in order to request the peer's
   certificate.  TLS [RFC5246] allows to include acceptable certificate
   authority in this certificate_request message:

       CertificateType certificate_types<1..2^8-1>;
       DistinguishedName certificate_authorities<3..2^16-1>;

   In EAP-TPM with zero configuration, the authenticator has to specify
   acceptable Privacy CAs (PCAs) within the certificate_authorities
   field in the certificate_request message.  After receiving the EAP-
   Request/TPM, TPM server_hello, TPM certificate, [TPM
   server_key_exchange,] TPM certificate_request, TPM server_hello_done
   messages, the peer has to check whether it has a valid certificate
   from one of the PCAs specified in TPM
   certificate_request->certificate_authorities or not.  In case it has
   such a certificate, the authentication goes on as shown in figure
   Figure 1.  In case the peer does not possess a valid certificate from
   one of the acceptable PCAs, it has to answer with EAP-Response/TPM/
   TPM no_such_certificate, TPM need_certificate, where
   no_such_certificate is an alert with level warning(1) and description
   no_certificate(41) [RFC5246]:

   struct {
      AlertLevel level;
      AlertDescription description;

   This message will be followed by TPM need_certificate, which
   specifies the PCA the peer wants to ask for a certificate:

   struct {
      opaque privacy_ca<1..2^16-1>;

Latze, et al.           Expires January 28, 2010                [Page 7]

Internet-Draft                   EAP-TPM                       July 2009

   The PCA specified in the need_certificate message MUST be one of the
   PCAs proposed in TPM certificate_request.  The authenticator will now
   ask the peer for its certificate request message and request the
   certificate at the desired PCA on behalf of the peer.  He starts the
   certificate request process with an EAP-Request/TPM/TPM

   struct {
      ConnectionAllowed allowed;
      opaque privacy_ca<1..2^16-1>;

   enum {
      true(1), false(2)

   The peer MUST check the privacy_ca value.  If it does not match the
   PCA specified in need_certificate, the peer MUST close the
   authentication immediately.  If the privacy_ca value matches and
   allowed is set to true(1), the peer is allowed to request a new
   certificate as shown in figure Figure 2.  It sends its
   certificate_request described in Section 5 inside EAP-Response/TPM/
   TPM certificate_request to the authenticator, which will then request
   the peer's certificate at the PCA.  The PCA sends the peer's
   certificate back to the authenticator, who will forward the
   certificate to the peer in the EAP-Request/TPM/TPM client_certificate
   message.  Afterwards, the authentication goes on as shown in figure
   Figure 1.
   ------                          ---------------          ------------
   |Peer|                          |Authenticator|          |Privacy CA|
   ------                          ---------------          ------------
   (incl. user's NAI)
   TPM client_hello
                              TPM server_hello,
                              TPM certificate,
                              [TPM server_key_exchange,]
                              TPM certificate_request,
                              TPM server_hello_done

Latze, et al.           Expires January 28, 2010                [Page 8]

Internet-Draft                   EAP-TPM                       July 2009

   TPM no_such_certificate,
   TPM need_certificate
                              TPM request_certificate
   TPM certificate_request
                              TPM client_certificate
   TPM certificate,
   TPM client_key_exchange,
   TPM certificate_verify,
   TPM change_cipher_spec,
   TPM finished
                              TPM change_cipher_spec,
                              TPM finished
                              EAP Success

    Figure 2: Successful EAP-TPM Authentication With Zero Configuration

7.  Failure, Fragmentation and Fast Re-Authentication

   Failed authentication requests, fragmentation and fast re-
   authentication are handled in exactly the same way as in EAP-TLS

8.  Key Derivation

   Key derivation in EAP-TPM occurs similar to key derivation in EAP-TLS
   [RFC5216].  The encryption keys are calculated using a pseudo random

Latze, et al.           Expires January 28, 2010                [Page 9]

Internet-Draft                   EAP-TPM                       July 2009

   function (PRF) that takes the master secret obtained during the TLS
   handshake and a random number which is the concatenation out of the
   random value in client_hello and server_hello as argument.  The
   initialisation vector (IV) which may be used for symmetric encryption
   will be calculated out of a PRF using an empty string and the random
   number mentioned above as argument.

9.  Security Considerations

   EAP-TPM as described in this document fulfills the mandatory and
   recommended requirements for wireless LANs specified in [RFC4017].
   The mandatory criteria "Generation of symmetric keying material",
   "Key strength", "Shared state equivalence", "Resistance to dictionary
   attacks", "Protection against man-in-the-middle attacks" and
   "Protected cipher suite negotiation" are fulfilled like in EAP-TLS
   since there is no difference to EAP-TLS regarding those points.  The
   "Mutual authentication support" is also fulfilled by definition since
   EAP-TPM is only made for mutual authentication.  The recommended
   requirements of [RFC4017] are also fulfilled: "Fragmentation" is
   provided as in EAP-TLS and "End-user identity hiding" is provided by
   the fact that the user may use different identities for every

   Furthermore, the request of an identity certificate MUST be
   acknowledged by the user in order to ensure that he is informed about
   the identities of his device.

   As the certificate request mentioned Section 6.2 has to be relayed
   over the authentication server, it might be possible for a malicious
   server to tamper with that request.  But as [TCGMainSpec] specifies
   some security measures for that certificate request (encrypted with
   the TPM key), the authentication server will not be able to modify
   the request without the peer or privacy CA noticing it.

10.  Acknowledgements

   The authors want to thank Bernhard Hoeneisen and Alan DeKok for their
   discussions regarding administrative matters and for the comments and
   Joe Salowey for suggestions about how to improve the specification.

11.  Normative References

   [MTMSpec]  TCG, "TCG Mobile Trusted Module Specification Version
              1.0", June 2008, <

Latze, et al.           Expires January 28, 2010               [Page 10]

Internet-Draft                   EAP-TPM                       July 2009


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC4017]  Stanley, D., Walker, J., and B. Aboba, "Extensible
              Authentication Protocol (EAP) Method Requirements for
              Wireless LANs", RFC 4017, March 2005.

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282, December 2005.

   [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
              Authentication Protocol", RFC 5216, March 2008.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

              TCG, "TCPA Main Specification Version 1.1b",
              February 2002, <

Authors' Addresses

   Carolin Latze
   University of Fribourg
   Boulevard de Perolles 90
   Fribourg, FR  1700


   Ulrich Ultes-Nitsche
   University of Fribourg
   Boulevard de Perolles 90
   Fribourg, FR  1700


Latze, et al.           Expires January 28, 2010               [Page 11]

Internet-Draft                   EAP-TPM                       July 2009

   Florian Baumgartner
   Swisscom Schweiz AG
   Ostermundigenstrasse 93
   Bern, BE  3006


Latze, et al.           Expires January 28, 2010               [Page 12]