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
draft-latze-emu-eap-tpm-01
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-
Drafts.
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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 (http://trustee.ietf.org/license-info).
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
Abstract
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
RFC.
3. Terms and Abbreviations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Furthermore, this document uses the following terms and
abbreviations:
Authenticator
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
Client
EAP-Peer - the one who wants to be authenticated.
MTM
Mobile Trusted Module as specified in [MTMSpec]
TPM
Trusted Platform Module as specified in [TCGMainSpec]
User
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
[TCGMainSpec]:
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
certificate.
4. The TPM will now activate the new identity using
TPM_ActivateIdentity.
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 |
-------- -----------------
EAP-Request/Identity
<------------------------------------------
EAP-Response/Identity
(includes user's NAI)
--------------------------------------->
EAP-Request/TPM/Start
<------------------------------------------
EAP-Response/TPM/
TPM client_hello
--------------------------------------->
EAP-Request/TPM/
TPM server_hello,
TPM certificate,
[TPM server_key_exchange,]
TPM certificate_request,
TPM server_hello_done
<-------------------------------------------
EAP-Response/TPM/
TPM certificate,
TPM client_key_exchange,
TPM certificate_verify,
TPM change_cipher_spec,
TPM finished
---------------------------------------->
EAP-Request/TPM/
TPM change_cipher_spec,
TPM finished
<--------------------------------------------
EAP-Response/TPM
---------------------------------------->
EAP-Success
<--------------------------------------------
Figure 1: Successful EAP-TPM Authentication With Existing
Certificates
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:
struct{
CertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<3..2^16-1>;
}certificate_request;
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;
}no_such_certificate;
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>;
}need_certificate;
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
request_certificate:
struct {
ConnectionAllowed allowed;
opaque privacy_ca<1..2^16-1>;
}request_certificate
where
enum {
true(1), false(2)
}ConnectionAllowed
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|
------ --------------- ------------
EAP-Request/Identity
<----------------------------------------
EAP-Response/Identity
(incl. user's NAI)
------------------------------------->
EAP-Request/TPM/Start
<----------------------------------------
EAP-Response/TPM/
TPM client_hello
------------------------------------->
EAP-Request/TPM/
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
<-----------------------------------------
EAP-Response/TPM/
TPM no_such_certificate,
TPM need_certificate
------------------------------------->
EAP-Request/TPM/
TPM request_certificate
<-----------------------------------------
EAP-Response/TPM/
TPM certificate_request
------------------------------------->
certificate_request
------------------------------------->
client_certificate
<--------------------------------
EAP-Request/TPM/
TPM client_certificate
<------------------------------------------
EAP-Response/TPM/
TPM certificate,
TPM client_key_exchange,
TPM certificate_verify,
TPM change_cipher_spec,
TPM finished
------------------------------------>
EAP-Request/TPM/
TPM change_cipher_spec,
TPM finished
<------------------------------------------
EAP-Response/TPM
------------------------------------>
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
[RFC5216].
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
authentication.
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, <https://www.trustedcomputinggroup.org/
specs/mobilephone/
Latze, et al. Expires January 28, 2010 [Page 10]
Internet-Draft EAP-TPM July 2009
Revision_6-tcg-mobile-trusted-module-1_0.pdf>.
[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.
[TCGMainSpec]
TCG, "TCPA Main Specification Version 1.1b",
February 2002, <https://www.trustedcomputinggroup.org/
specs/TPM/TCPA_Main_TCG_Architecture_v1_1b.pdf>.
Authors' Addresses
Carolin Latze
University of Fribourg
Boulevard de Perolles 90
Fribourg, FR 1700
Switzerland
Email: carolin.latze@unifr.ch
Ulrich Ultes-Nitsche
University of Fribourg
Boulevard de Perolles 90
Fribourg, FR 1700
Switzerland
Email: uun@unifr.ch
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
Switzerland
Email: florian.baumgartner@swisscom.com
Latze, et al. Expires January 28, 2010 [Page 12]