ENROLL H. Tschofenig
Internet-Draft D. Kroeselberg
Expires: April 17, 2005 Siemens
October 17, 2004
Next Steps for ENROLL
draft-tschofenig-enroll-next-steps-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 April 17, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes framework specific aspects relevant for the
Credential and Provisioning (ENROLL) working group. State-of-the-art
work with possible relevance for ENROLL is given with a special focus
on the 3GPP Generic Authentication Architecture (GAA), which has a
relationship to the Trusted Transitive Introduction (TTI) model. The
main goal of this document is to initiate some discussions about the
focus of the working group and possible next steps.
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 1]
Internet-Draft Next Steps for ENROLL October 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Classification . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Secret stored in device during manufacturing . . . . . . . 6
3.2 Secret established over a secure network . . . . . . . . . 6
3.3 Secret established over an insecure network . . . . . . . 7
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 15
7.2 Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
A. 3GPP Generic Boostrapping Architecture . . . . . . . . . . . . 19
A.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 19
A.2 The Generic Bootstrapping Architecture (GBA) . . . . . . . 20
A.3 Application Security for HTTP Based Applications . . . . . 22
A.3.1 Use of HTTP Digest Authentication . . . . . . . . . . 23
A.3.2 Use of TLS . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 25
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 2]
Internet-Draft Next Steps for ENROLL October 2004
1. Introduction
This document describes framework specific aspects relevant for the
Credential and Provisioning (ENROLL) working group. State-of-the-art
work with possible relevance for ENROLL is given with a special focus
on the 3GPP Generic Authentication Architecture (GAA), which has a
relationship to the Trusted Transitive Introduction (TTI) model
defined in [I-D.pritikin-ttimodel].
The goal of this document is to discuss relevant scenarios for the
work of the ENROLL group, and to provide some views to the discussion
from the perspective of 3GPP networks. This explicitly does not
consider the imprinting process for mobile operators of GSM or 3GPP
networks, where SIM or USIM cards need to be initiated with security
credentials (secret keys) and have to be issued to the mobile users
by the network operators. This process is well-established; however,
the trust relations between security domains related to mobile
wireless networking tend to grow in complexity, and dynamic
establishment of trust relations, or dynamic addition (and removal)
of mobile users to new security domains seems to be the interesting
case to be considered by ENROLL.
A number of terms are used in [I-D.pritikin-ttimodel] to define a
model for introduction. One of them is out-of-band, which can,
however, have quite different meanings in different contexts. For
example, adding a mobile user by out-of-band means to a security
domain can be the process where a network operator sends a letter
with the initial credentials (USIM card, PIN) the user requires to
get access to the wireless network. In a different scenario, this
could be the dynamic, secure issuing of asymmetric credentials for
access to services in a security domain requiring the use of such
credentials. The user can receive such credentials either by the
security domain hosting the service itself, or by a third party that
has some trust relation in advance with both the security domain and
the mobile user.
Hence, as a generic starting point for models relevant to ENROLL, the
subsequent classification is taken from Section 4 of
[I-D.hanna-zeroconf-seccfg] on security configuration mechanisms.
A simple architecture is based on two entities, Alice and Bob. In a
more complex scenario three entities are considered. The two party
scenario is shown in Figure 1 and the three party scenario is shown
in Figure 2.
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 3]
Internet-Draft Next Steps for ENROLL October 2004
+-----------+ no prior +-----------+
| Entity | trust relation | Entity |
| Alice | ship | Bob |
+-----------+ +-----------+
Figure 1: Two Party Scenario
+-----------+
| Entity |
+--------------------------->| Carol |
| trust relationship +-----------+
| ^
| |
| |
| | trust
| | relationship
| |
| |
v v
+-----------+ no prior +-----+-----+
| Entity | trust relationship | Entity |
| Alice | | Bob |
+-----------+ +-----------+
Figure 2: Three Party Scenario
In Figure 2 the existence of a third party, Carol, is used to
dynamically establish a security association between Alice and Bob to
create a security association.
The relevance of these two models is shown in Section 3.
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 4]
Internet-Draft Next Steps for ENROLL October 2004
2. Terminology
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 [RFC2119].
The cryptographic initialisation or what is also called imprinting,
is a procedure of equipping the component with a secret value of a
cryptographic parameter. The type of the parameter varies a lot
depending on its subsequent use in security mechanisms. It may be an
unstructured randomly generated string, from where future key
material is derived. It may also be keying material related to an
asymmetric cryptographic mechanism, in which case it has a
well-defined structure.
In many mobile scenarios, the wireless link is the basic
communication channel between the devices. It is inherently
insecure, that is, passive eavesdropping, channel hi-jacking, as well
as active impersonation and tampering of data is possible. The
procedure of imprinting, where the initial secret cryptographic
parameters are set in the component, is the most sensitive part of
the communication. If tampering or eavesdropping the imprinting step
is possible, then the security of all future communication based on
imprinting is ruined.
Considering the initial provision of credentials for allowing mobile
users to access security domains, not only the term imprinting, but
also enrollment, or bootstrapping frequently occur. The authors of
this contribution are not aware of clear and commonly accepted
definitions of these terms, but rather assume that these vary
depending on the underlying use cases and scenarios where they are
used.
Therefore, one goal of the ENROLL working group should be to leverage
a common understanding of these terms.
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 5]
Internet-Draft Next Steps for ENROLL October 2004
3. Classification
This section defines a few classes of credential provisioning (or
imprinting) scenarios.
3.1 Secret stored in device during manufacturing
This scenario focuses on a cryptographic secret which is stored in
the device during manufacturing. This secret generally cannot be
changed and is made available to the user, e.g., by printing on a
separate letter (off-line, out-of-band provisioning). Any entity
possessing the password can change the configuration of the device.
The security of the whole process depends on the shipment of the the
letter with the relevant information.
This scenario in the view of the authors does not raise any specific
issues relevant for the work in the ENROLL working group.
3.2 Secret established over a secure network
In this scenario it is assumed that Alice and Bob can communicate
over a temporary secure channel or out-of-band channel. In this
context, the secure channel can be based on one of the following
technologies:
o Fixed connection such as cable, USB interface, bar-code reader,
smart-card reader
o Human involvement, communication of passkeys, entering passkeys
o Second wireless (e.g., infrared)
o Other proximity based technology (low power channel)
o Memory sticks (e.g., USB tokens)
An example for this approach is given with Windows Smart Network Key
[WSNK] where the process of imprinting can be triggered at a new
device (e.g., entity A in our example). As a result, Alice creates a
key and the corresponding parameters and writes this information into
an XML file and copies it to a USB stick. This USB stick is then
used to carry the parameters to Bob to complete the imprinting
procedure.
The content of the XML file heavily depends on the application
domain. In the context of wireless LAN equipment security parameters
used within IEEE 802.11i/802.11/802.1X are such as:
o SSID
o Encryption (WEP, TKIP, AES)
o EAP Method (EAP-TLS, PEAP-EAP-MSCHAPv2, PEAP-EAP-TLS)
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 6]
Internet-Draft Next Steps for ENROLL October 2004
o Authentication Type (open, shared, WPA, WPAPSK, WPA-NONE, WPA2,
WPA2PSK)
o IEEE 802.IX enabled?
and many non-security related parameters.
An approach to make this process generic for many application domains
is ambitious. As an example, the above parameter list includes a few
EAP methods. Apart from the fact that the list is, by no means,
complete it would also be necessary to specify a few parameters with
relevance for each individual EAP method. Switching to a new
application domain often requires to consider different types of
identities.
3.3 Secret established over an insecure network
With this class there is no separate secure channel. Still a number
of possiblities exist to establish a shared secret between Alice and
Bob. Often, an approach similar to SSH is mentioned where the user
has to compare a fingerprint of some exchanged parameters (e.g., the
public key). This approach is described in [SHAMAN], in Section 4.3
of [I-D.hanna-zeroconf-seccfg] or with the Shared Secret Provisioning
Protocol (SSPP) [I-D.moskowitz-shared-secret-provprotocol]. Thereby
a Diffie-Hellman alike protocol is executed between the two entities,
Alice and Bob. A cryptographic hash value computed over some
payloads is displayed at both devices and compared. This
fingerprinting approach is used to avoid man-in-the-middle attacks.
The size of the solution space for such a protocol is affected by the
type of environments where such a protocol is used and constraints
such as computational requirements, requirements affected by the type
of devices used, desired level of security, etc. Since SSPP is an
abstract protocol mappings are provided, for example, to SNMP (see
[I-D.moskowitz-sspp-snmp]). [I-D.moskowitz-radius-client-kickstart]
describes how session keys can be established between RADIUS clients
and RADIUS servers for Wireless LAN deployments.
Some architectures use a trusted third party to establish a security
association between Alice and Bob. These protocols use the existence
of a security association (and a trust relationship) between Alice
and Bob and a trusted entity, Carol. Figure 2 depicts the
architecture. A classic example of this architecture for network
access authentication with the help of EAP and EAP methods is
described in [I-D.ietf-eap-keying]. The same document describes the
interaction between the different protocols and the keying framework.
In [I-D.tschofenig-pana-bootstrap-kerberos] a mechanism is described
how to bootstrap Kerberos Ticket Granting Tickets based on an EAP
network access authentication protocol run. Subsequently, Kerberos
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 7]
Internet-Draft Next Steps for ENROLL October 2004
service tickets can be requested for access to services.
In Figure 5 the 3GPP Generic Authentication Architecture (GAA)
approach for establishing a security association between mobile users
and services in a security domain the users are not initially part
of, is described. Appendix A gives an overview of this architecture.
There are a number of interesting differences between the EAP/AAA
based approach and the 3GPP GAA framework that allows to leverage the
established huge security infrastructure for mobile phone users
With a three party architecture two types of message exchanges are
possible. We depict these two types in Figure 3 and in Figure 4.
+-----------+
| Entity |
| C |
+-----------+
^ /
| / Key
EAP | / Transport
over | / in
RADIUS/ | / RADIUS/
DIAMETER | / DIAMETER
| /
v v
+-----------+ EAP (IEEE 802.1X) +-----------+
| Entity |<------------------->| Entity |
| A | | B |
| |<===================>| |
+-----------+ Link Layer Security+-----------+
(IEEE 802.11i with
TKIP or AES CCMP)
Figure 3: EAP based Architecture
With the message exchange in Figure 3 Alice starts interacting with
Bob. Since there no relationship between Alice and Bob, it is
necessary to forward the EAP exchange to Carol whereby Alice has a
trust relationship with Carol. After a successful authentication and
authorization session keys must be delivered to Bob for subsequent
establishment of security associations. A number of protocols today
use this architecture, such as IEEE 802.1X [IEEE-802-1X-REV] (and
IEEE 802.11i), IKEv2 [I-D.ietf-ipsec-ikev2] or PANA
[I-D.ietf-pana-pana]. These protocols just label the involved
entities differently.
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 8]
Internet-Draft Next Steps for ENROLL October 2004
+-----------+
| Entity |
| C |
+-----------+
^ /
Request / /
Assertion/ /Assertion/
Ticket/ / /Ticket/
Token / /Token
/ /
/ /
/ /
/ v Authentication and
+-----------+ Key Exchange Protocol +-----------+
| Entity | (+Token,Ticket,Assertion) | Entity |
| A |---------------------------->| B |
| |<----------------------------| |
+-----------+ +-----------+
Figure 4: Token,Ticket,Assertion-based Architecture
With the architecture shown in Figure 4 Alice has to start
communication with an Carol first, whereby a direct or indirect trust
relationship between these two entities is assumed. First, some form
of Token, Ticket or Assertion is requested. Different protocols
label this item differently. This exchange typically requires mutual
authentication and authorization to be finished before Alice receives
the desired item. When a service access is required then Alice
interacts with Bob and presents this Token, Ticket or Assertion.
Kerberos (with the usage of Tickets) [RFC1510] and SAML (see for
example, [I-D.saml-tech-overview-1.1-03], [I-D.saml-core-1.1],
[I-D.saml-bindings-1.1]) with the usage of Assertions (or Artifacts
which are references to Assertions) are protocol examples.
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 9]
Internet-Draft Next Steps for ENROLL October 2004
4. Conclusion
The above sections give a number of sample classifications for
scenarios relevant to the ENROLL group, and reference numerous
examples. The main focus is on mobile scenarios, and on the "secret
established over insecure network" processes that are considered the
most interesting for current demands of introducing mobile users with
appropriate credentials to access security domains offering services
to the mobile users. Typically, a pre-established trust relation or
security relation between such users and services cannot be assumed.
As an example that is considered relevant for the ENROLL working
group, the 3GPP GAA is discussed in more detail in Appendix A.
Although no thorough analysis of the GAA framework is provided in
this initial draft version, a number of observations related to the
different terminologies are given below.
The TTI model draft [I-D.pritikin-ttimodel] defines the term
introduction as follows: 'When adding a device into a security domain
the first task is to exchange cryptographic and configuration
information between the security domain and the device. This process
we term an Introduction.'
One question that arises is what exactly a "security domain" is?
This, of course, heavily depends on the given usage scenario. For
example, introduction to a security domain fundamentally differs (as
well as the security domain does) for the use cases given in the
above section (e.g., storing secret information in a device during
manufacturing versus secret stored over insecure wireless link).
ENROLL needs to clearly state which types of security domains are
covered, and which are not. This draft contributes to this
clarification by providing additional use cases.
In 3GPP networks, a mobile device is 'added' to the home operator's
security domain as soon as the user gets the USIM card. In contrast,
through the 3GPP GAA framework (see Annex A for a detailed overview)
the mobile user is introduced to a service provider's security domain
as soon as a new security context is initiated based on the existing
security infrastructure of 3GPP networks.
The complexity described in [I-D.pritikin-ttimodel] for PKI
enrollment is for instance solved by the GAA by the ability to
dynamically issue public-key certificates to mobile users on demand,
which offers the advantage that only those users receive
certificate-based credentials who really request them. Issuing
certificates to the complete, huge, user base of mobile phone
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 10]
Internet-Draft Next Steps for ENROLL October 2004
networks would unnecessarily increase initial costs and
administrational effort. The 3GPP network operator, or some instance
with an already established trust relationship with such an operator,
can provide the role of an initiator in this case.
As it is not fully clear to the authors of this draft whether the
definition of Introduction made by [I-D.pritikin-ttimodel] matches
with the goals achieved by the 3GPP GAA, the related terms of a
petitioner, an introducer and a Registrar are not used for the GAA
example in Annex A. Instead, we use the roles of a mobile user, a
home network (of the mobile user) and some service provider or
application server as logical entities.
However, we expect that a good match for the different terminology
would be to associate the mobile user with the petitioner, the home
network with the introducer, and the application server with the
registrar.
The 3GPP GAA may be considered as some form of authentication and
authorization (AA) infrastructure the mobile user or petitioner is
expected to enroll with. Although being a more complex example, this
basically matches the 'pay for use' example in Section 4.5 of
[I-D.pritikin-ttimodel] which describes the initiation of a trust
relation between a mobile user and a public WLAN hotspot (provider of
the service 'Internet access') through a credit card company as the
initiator. [TS22.934] describes a similar scenario where a 3GPP
network operator supports this initiation.
One result of matching the 3GPP GAA to the TTI model is that both the
introducer and the registrar may issue the credentials that are
subsequently used by the petitioner for service access. This depends
on the exact grouping of the processes:
o If we just consider the process of issuing a certificate to the
mobile user, where the user first contacts the BSF to authenticate
and establish a new shared secret based trust relation with the
NAF responsible for certificate issuing, this NAF may be
considered as the Registrar issuing new credentials for subsequent
service access.
o If we consider service access and group the process of issuing
credentials (i.e., the user's communication with the BSF and -
based on this exchange éÌ subsequently with the NAF, the network
offering the GAA service may be considered as the initiator
issuing credentials, and these are subsequently used with the
registrar, i.e., some other NAF offering e.g. an HTTP-based
service to the mobile user.
Although there is no clear terminology differentiating between these
two examples given above, the authors of this draft tend to regard
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 11]
Internet-Draft Next Steps for ENROLL October 2004
the first example as introduction, or enrollment, and the second
example as a bootstrapping process.
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 12]
Internet-Draft Next Steps for ENROLL October 2004
5. Security Considerations
The document discusses state-of-the-art security architectures and
protocols. As such, it addresses a huge number of security issues.
No additional specific security vulnerabilities, threat models or
solutions are given in this section.
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 13]
Internet-Draft Next Steps for ENROLL October 2004
6. Acknowledgments
We would like to thank Wolfgang Buecker for his input to this
document.
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 14]
Internet-Draft Next Steps for ENROLL October 2004
7. References
7.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
7.2 Informative References
[I-D.hanna-zeroconf-seccfg]
Hanna, S., "Configuring Security Parameters in Small
Devices", draft-hanna-zeroconf-seccfg-00 (work in
progress), January 2002.
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-03 (work in
progress), July 2004.
[I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-16 (work in progress), September
2004.
[I-D.ietf-pana-pana]
Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", draft-ietf-pana-pana-05 (work in
progress), July 2004.
[I-D.ietf-tls-psk]
Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", draft-ietf-tls-psk-01
(work in progress), August 2004.
[I-D.moskowitz-radius-client-kickstart]
Moskowitz, R., "RADIUS Client Kickstart",
draft-moskowitz-radius-client-kickstart-01 (work in
progress), October 2003.
[I-D.moskowitz-shared-secret-provprotocol]
Moskowitz, R., "Shared Secret Provisioning Protocol",
draft-moskowitz-shared-secret-provprotocol-02 (work in
progress), November 2003.
[I-D.moskowitz-sspp-snmp]
Moskowitz, R., "SSPP over SNMP",
draft-moskowitz-sspp-snmp-01 (work in progress), October
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 15]
Internet-Draft Next Steps for ENROLL October 2004
2003.
[I-D.pritikin-ttimodel]
Pritikin, M., "Trusted Transitive Introduction Model",
draft-pritikin-ttimodel-01 (work in progress), July 2004.
[I-D.saml-bindings-1.1]
Maler, E., Philpott, R. and P. Mishra, "Bindings and
Profiles for the OASIS Security Assertion Markup Language
(SAML) V1.1", September 2003.
[I-D.saml-core-1.1]
Maler, E., Philpott, R. and P. Mishra, "Assertions and
Protocol for the OASIS Security Assertion Markup Language
(SAML) V1.1", September 2003.
[I-D.saml-tech-overview-1.1-03]
Maler, E. and J. Hughes, "Technical Overview of the OASIS
Security Assertion Markup Language (SAML) V1.1", March
2004.
[I-D.tschofenig-pana-bootstrap-kerberos]
Tschofenig, H., "Bootstrapping Kerberos",
draft-tschofenig-pana-bootstrap-kerberos-00 (work in
progress), July 2004.
[IEEE-802-1X-REV]
Institute of Electrical and Electronics Engineers, "DRAFT
Standard for Local and Metropolitan Area Networks:
Port-Based Network Access Control (Revision)", IEEE
802-1X-REV/D9, January 2004.
[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
[RFC3310] Niemi, A., Arkko, J. and V. Torvinen, "Hypertext Transfer
Protocol (HTTP) Digest Authentication Using Authentication
and Key Agreement (AKA)", RFC 3310, September 2002.
[SHAMAN] "Detailed technical specification of distributed mobile
terminal system security, Deliverable 10, Work Package 2,
IST-2000-25350 - SHAMAN", May 2002.
[TR33.919]
3rd Generation Partnership Project, "3rd Generation
Partnership Project; Technical Specification Group
Services and System Aspects; Generic Authentication
Architecture (GAA); System Description (Release 6)",
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 16]
Internet-Draft Next Steps for ENROLL October 2004
Technical Specification 3GPP TR 33.919 V2.1.0 (2004-07),
July 2004.
[TS22.934]
3rd Generation Partnership Project, "3rd Generation
Partnership Project; Technical Specification Group
Services and System Aspects; Feasibility study on 3GPP
system to Wireless Local Area Network (WLAN) interworking
(Release 6)", Technical Specification 3GPP TS 22.934
V6.2.0 (2003-09), September 2003.
[TS33.220]
3rd Generation Partnership Project, "3rd Generation
Partnership Project; Technical Specification Group
Services and System Aspects; Generic Authentication
Architecture (GAA); Generic bootstrapping architecture
(Release 6)", Technical Specification 3GPP TS 33.220
V6.2.0 (2004-09), September 2004.
[TS33.221]
3rd Generation Partnership Project, "3rd Generation
Partnership Project; Technical Specification Group
Services and System Aspects; Generic Authentication
Architecture (GAA); Support for subscriber certificates
(Release 6)", Technical Specification 3GPP TS 33.221
V6.1.0 (2004-09), September 2004.
[WSNK] "Windows Connect Now, Version 3, available at:
'http://www.microsoft.com/whdc/device/netAttach/WSNK.mspx'
(Oct. 2004)", October 2004.
Authors' Addresses
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 17]
Internet-Draft Next Steps for ENROLL October 2004
Dirk Kroeselberg
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Dirk.Kroeselberg@siemens.com
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 18]
Internet-Draft Next Steps for ENROLL October 2004
Appendix A. 3GPP Generic Boostrapping Architecture
A.1 Overview
This chapter presents the concepts behind the Generic Authentication
Architecture (GAA) specified in 3GPP [TR33.919] and the Generic
Bootstrapping Architecture (GBA) specified in 3GPP [TS33.220]. This
architecture is considered a relevant input scenario for ENROLL,
since it supports introduction of mobile users (in the form of
establishing shared secrets or public/private key pairs and
certificates) for client access to security domains offering
arbitrary (typically, but not limited to, HTTP-based) services. This
process is based on the available security infrastructure in 3G
mobile networks (i.e., on smartcard (USIM) based credentials).
The motivation for such an architecture arises from the fact that
there are many serives related to 3G mobile systems which all share a
requirement for mutual authentication between a client (the mobile
device) and an application server. While these authentication
mechanisms might differ from application to application, they all
require an a priori security relationship to be initiated either
dynamically or statically. For all known authentication mechanisms
this consists of either shared secret keys or the use of public key
cryptography. For example, HTTP digest requires passwords (or shared
secret keys) that have to be installed in the mobile user's device
before sending the first protected message. TLS assumes that the
server and optionally the client are in possession of a TLS
certificate before initiating a TLS-secured session.
The key issue with setting up initial security "credentials" between
the mobile user's device and an application server is the possible
complexity of the mobile (3GPP) scenario, where services can be
provide by either the home or the visited network, or by 3rd party
application providers with a relation to the home or visited network.
In general, no initial relation between these parties exists.
This lead to the definition of a generic architecture for dynamically
setting up security relations (in terms of shared secrets, or
public-key certificates) between a mobile device and an application
server, based on the existing security infrastructure of 3GPP
networks. In such environments, all users are equipped with security
credentials on a smartcard device (USIM), and the corresponding keys
are stored in an entity called HSS (home subscriber server) in the
home network that provides the USIM cards to mobile users.
The GAA provides means that allow a mobile user and an application
server to establish either shared secrets or to establish a security
relation based on user certificates. This generic "enrollment"
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 19]
Internet-Draft Next Steps for ENROLL October 2004
process is implemented in a unified, application independent
architecture that relieves single applications from defining their
specific ways of how to achieve a priori security relationships
between clients and servers. Authentication is based on the well
established AKA algorithm (e.g., used in EAP-AKA) so that the mobile
network operator reuses the USIM cards that are expected to be
largely spread among mobile phone users.
+--------------------+
| Generic |
| Authentication |
| Architecture (GAA) |
+-------+-+----------+
| |
+----------------+ +-----------------+
| |
+--------+-----------+ +--------+-----------+
| Generic | | Support for |
| Bootstrapping | | Subscriber |
| Architecture (GBA) | | Certificates (SSC) |
+--------------------+ +--------------------+
Figure 5: Components of the Generic Authentication Architecture
Thus, as shown in Figure 5, the GAA consists of two main components,
one that aims at installing shared secrets in a mobile device and in
an application server, and another who issues certificates to mobile
devices. The two components are called the Generic Bootstrapping
Architecture (GBA) [TS33.220], and Support for Subscriber
Certificates (SSC) [TS33.221], respectively. In the following
subsections we will discuss the architectural details of these
components. As we will see, the support for subscriber certificates
is just an example of an application that makes use of the GBA.
Finally, we will illustrate the usage of the GBA for HTTP based
services that perform client side authentication based on HTTP digest
as a simple example.
A.2 The Generic Bootstrapping Architecture (GBA)
The elements of the Generic Bootstrapping Architecture are displayed
in Figure 6. Apart from the mobile device and the HSS there are two
additional elements:
The Bootstrapping Server Function (BSF): This represents an element
that performs mutual authentication with the mobile user by means
of the HTTP digest AKA protocol (see [RFC3310]). The
authentication vectors required to run the AKA protocol are
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 20]
Internet-Draft Next Steps for ENROLL October 2004
fetched from the HSS (and are derived in the mobile device, or
USIM card, in parallel). One result of the aka procedure is a
pair of keys, IK and CK, from which keys are derived for later use
by the mobile device and NAF to secure any application related
communication.
The Network Application Function (NAF): This stands for a generic
application server that provides any kind of service (application)
to the mobile device. No assumptions are made about the protocol
used between mobile device and NAF, though one candidate that is
assumed to be used frequently is HTTP. The NAF fetches from the
BSF the key that resulted from the aka protocol run between BSF
and mobile device, and uses it in securing the application related
communication with the mobile device.
+-------+ +-------+
| | | |
+----------------+ BSF +--------------+ HSS |
| | | | |
| +---+---+ +-------+
+--+---+ |
| | |
|mobile| |
|device| |
+--+---+ |
| +---+---+
| | |
+----------------+ NAF |
| |
+-------+
Figure 6: Elements of the Generic Bootstrapping Architecture
A high level view on the resulting information flow of the generic
bootstrapping procedure is shown in Figure 7. In order to illustrate
some of the concepts when the mobile device contacts several NAFs we
have shown a communication flow where the mobile device addresses two
different NAFs. The mobile device starts by sending a request to the
first application server (NAF) indicating its intention to invoke
some application (1). The concrete form of this request depends on
the protocol used for this application. In general, the mobile
device will not know whether GAA bootstrapping has to be performed in
order to use the NAF. Therefore, the NAF indicates the use of
bootstrapping in a response to the initial request and does not
further process the request. After that the mobile device contacts
the BSF and runs the HTTP digest aka protocol with the BSF based on
the long term secret stored in the USIM located in the mobile device
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 21]
Internet-Draft Next Steps for ENROLL October 2004
(2). In the course of this procedure the BSF fetches one or more
authentication vectors from the HSS which are required to perform the
AKA protocol (3).
If the HTTP digest AKA protocol succeeds, the mobile device and BSF
are in the possession of keys that are later used in securing
messages exchanged between mobile device and NAF.
The mobile device now initiates a second attempt to send a request to
the application server NAF. When the NAF receives the message, it
requests the corresponding keys from the BSF (5). After having
received the keys from the BSF, NAF is able to verify the request
received by the mobile device and can henceforth use the keys to
protect any further communication (6). Again, the details of the
protection of these messages depend on the concrete protocol that is
used by the application.
+--------+ +-----+ +-----+ +-----+
| mobile | | NAF | | BSF | | HSS |
| device | | | | | | |
+--------+ +-----+ +-----+ +-----+
| | | |
| REQUEST | | |
|-------------------->| | |
(1) | Bootstrap required | | |
|<--------------------| | |
| | | |
| Perform http digest AKA | Fetch AV |
(2) |<------------------------------>|<---------->|
| | | (3) |
+-----------+ | +-----------+ |
|Derive keys| | |Derive keys| |
+-----------+ | +-----------+ |
| | | |
| REQUEST (secured) | | |
(4) |-------------------->| Get keys | |
| |<-------->| |
| Answer (secured) | (5) | |
(6) |<--------------------| | |
Figure 7: Elements of the Generic Bootstrapping Architecture
A.3 Application Security for HTTP Based Applications
In the previous section we described how a security relation between
a mobile device and an application server is established using the
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 22]
Internet-Draft Next Steps for ENROLL October 2004
Generic Bootstrapping Architecture. In this section we briefly
illustrate the use of the Generic Bootstrapping mechanism in case the
application protocol HTTP is run between the mobile device and the
NAF.
In the simplest case the (mutual) authentication between mobile
device and NAF can be performed using simple HTTP digest. In
addition, TLS may be used which offers a higher level of security due
to the encryption of the message exchange. TLS can either be used
with server-only authentication, i.e., the server uses a TLS server
certificate, and the client authenticates by other means like http
digest through the TLS tunnel, or with the client authenticating with
a TLS user certificate (mutual authentication).
A.3.1 Use of HTTP Digest Authentication
If HTTP is used as protocol between a mobile device and an
application server, HTTP Digest [RFC2617] is one natural candidate to
perform simple client-only or mutual authentication between mobile
device and application server. The role of the GBA in this scenario
would be to provide the client and HTTP server (the NAF) with a http
digest password (shared secret). Such information is not present for
step (1) in Figure 7, since client and server do not have any initial
security relation in place. After step (5) in Figure 7 has taken
place, both the client in the mobile device and the NAF share a
common secret to be used as http digest password.
A.3.2 Use of TLS
When it comes to securing HTTP related communication, the use of TLS
is another common option. Beyond authentication and integrity
protection, it provides encryption of the communication packets. In
a typical web scenario, the web server is authenticated using public
key cryptography based on certificates. Following this, a secure
tunnel, called the TLS record layer is established which carries all
future communication between the client and the server. Frequently,
the client is then authenticated by some separate protocol e.g.
based on a password and some challenge-response mechanism like for
instance HTTP Digest.
As already described in the above section the GBA can support this
hybrid approach by initiating a security relation for http digest.
The PKI-related aspects of the server-side PKI required for TLS
operation are not considered here, and are independend of the
functionality provided by the GBA.
Yet, TLS also offers the possibility for a client to present a
certificate on which the client authentication can be based.
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 23]
Internet-Draft Next Steps for ENROLL October 2004
However, today client certificates are often not used in the context
of TLS as only few users of mobile devices bother to acquire
certificates. There also exist proposals in the IETF to run TLS
based on pre-shared keys not using certificates at all
[I-D.ietf-tls-psk], i.e. both authentications (client to server and
server to client) are based on symmetric techniques.
The 3GPP GAA allows to provide mobile users with such certificates on
request. For this, the following steps are executed:
(1) The mobile user uses the GBA as depicted in Figure 7, where
the NAF is not the application server to be accessed via TLS, but
a server allowing the client to request the issuing of (enrollment
for) a Subscriber Certificate. Mutual authentication between the
NAF providing Subscriber Certificates and the mobile user is based
on the keys established after the user contacted the BSF. As a
result, the mobile user requests a Subscriber certificate from the
NAF.
(2) The mobile user subsequently uses the Subscriber Certificate
to authenticate the TLS session with the application server to be
finally contacted.
The detailed specification for provisioning of Subscriber
Certificates can be found in [TS33.221].
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 24]
Internet-Draft Next Steps for ENROLL October 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Tschofenig & Kroeselberg Expires April 17, 2005 [Page 25]