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]