Internet DRAFT - draft-ohba-core-eap-based-bootstrapping

draft-ohba-core-eap-based-bootstrapping






Network Working Group                                             S. Das
Internet-Draft                                                       ACS
Intended status: Standards Track                                 Y. Ohba
Expires: September 11, 2012                                      Toshiba
                                                          March 10, 2012


        Provisioning Credentials for CoAP Applications using EAP
               draft-ohba-core-eap-based-bootstrapping-01

Abstract

   This document first discusses the use cases where CoAP (Constrained
   Application) requires a dynamic mechanism for provisioning
   credentials for DTLS-PSK (Pre-Shared Key) ciphersuites and PSK mode
   of IKEv2 and then provides an EAP (Extensible Authentication
   Protocol) based framework to enable such scenarios.

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on September 11, 2012.

Copyright Notice

   Copyright (c) 2012 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as



Das & Ohba             Expires September 11, 2012               [Page 1]

Internet-Draft     EAP-Based Credentials Provisioning         March 2012


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Specification of Requirements . . . . . . . . . . . . . . . 3
   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Use Case 1: Non-integrated with Network Access
           Authentication  . . . . . . . . . . . . . . . . . . . . . . 3
     2.2.  Use Case 2: Integrated with Network Access
           Authentication  . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 6
     4.1.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . 6
     4.2.  Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 6
     4.3.  Call Flow . . . . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8




























Das & Ohba             Expires September 11, 2012               [Page 2]

Internet-Draft     EAP-Based Credentials Provisioning         March 2012


1.  Introduction

   Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a web
   protocol defined over UDP to realize the Representational State
   Transfer (REST) architecture of the web in a suitable form for
   constrained environments and M2M (Machine-to-Machine) applications.
   CoAP supports a limited subset of HTTP functionality, which allows
   straightforward mapping to HTTP.  Unicast CoAP messages are secured
   using Datagram TLS (DTLS) [RFC4347] and IPsec Encapsulating Security
   Payload (ESP) [RFC4303].

   This document describes how EAP (Extensible Authentication Protocol)
   can be used to provide credentials for DTLS-PSK (Pre-Shared Key)
   ciphersuites and PSK mode of IKEv2 [RFC5996] that are used for
   dynamically establishing unicast security associations.

   Although CoAP supports multicast messaging in addition to unicast,
   current CoAP specification does not clearly specify which security
   protocol is used for securing multicast CoAP messages and how
   multicast keys are established.  This version of document focuses on
   provisioning credentials for unicast security associations.

1.1.  Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  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].


2.  Use Cases

   The following uses cases are considered.

2.1.  Use Case 1: Non-integrated with Network Access Authentication

   This use case scenario is applicable where credentials provisioning
   for CoAP is not facilitated by the access network authentication
   mechanisms.  Typically this type of scenario exists when there are no
   business relationships exist between access network provider and
   service provider.  Service provider here is a provider that provides
   CoAP-based application services.  For example, access network
   provider could be a DSL or cable provider whereas the service
   provider could be an electric utility provider.  The applicability of
   such scenarios is depicted in more details in [ETSIM2M].

   Following are the advantages of credentials provisioning for CoAP in



Das & Ohba             Expires September 11, 2012               [Page 3]

Internet-Draft     EAP-Based Credentials Provisioning         March 2012


   this scenario:

   o  There is no requirement of having knowledge on how the access
      network security is provided and managed.  Hence there is no need
      to have interface between access network device/gateway and
      application device/gateway.

   o  The security credentials can be provisioned and managed directly
      by the service provider.

   o  There is no need for manual provisioning of keys to the client and
      server

   o  Provides a scalable architecture that does not require
      establishing secure connection to other devices/gateways in the
      network rather than CoAP application server.

2.2.  Use Case 2: Integrated with Network Access Authentication

   This use case scenario is applicable where credentials provisioning
   for CoAP is facilitated by the access network authentication
   mechanisms.  Typically this type of scenario exists when there are
   business relationships exist between access network provider and
   service provider or both access network and service providers are
   managed by the same entity or organization.  For example, the access
   network provider and the service provider both could be an electric
   utility provider where access network is Wi-Fi mesh and the CoAP
   application is a smart metering data application.  Another example
   could be that access network is a cellular network and there is
   business relationship with the cellular provider and utility
   provider.  The applicability of such scenarios is depicted in more
   details in [ETSIM2M].

   Following are the advantages of credentials provisioning for CoAP in
   this scenario:

   o  The same credential and other provisioning parameters for network
      access authentication can be used to generate the key for CoAP
      applications

   o  No need for separate provisioning and management interface to the
      end devices

   o  There is no need for manual provisioning of keys to the client and
      server

   o  Provides a tightly coupled architecture that does not require
      separate management and provisioning infrastructure.



Das & Ohba             Expires September 11, 2012               [Page 4]

Internet-Draft     EAP-Based Credentials Provisioning         March 2012


3.  Architecture

   The credentials provisioing architecture is shown below where several
   functional elements are used.  The placement and consideration of
   these functional elements do not provide any mapping to specific
   network architecture or deployment scenarios.


   CoAP client
   +----+                    +----+                       +----+
   | UE |--------------------| AA |-----------------------| AS |
   +----+                    +----+                       +----+
     |                                                      |
     |                      CoAP server                     |
     |                       +----+                         |
     +-----------------------| ApS|-------------------------+
                             +----+


                     Figure 1: Functional Architecture

   UE (User Equipment):

        A user terminal that has a CoAP client

   ApS (Application Server):   A CoAP server that provides a specific
        application service for the UE

   AS (Authentication Server):   A server that authenticates the UE for
        application services

   AA (Authentication Agent):   An agent that acts as an authentication
        relay for the UE for application access authentication (e.g.,
        NAS (Network Access Server).

   This architecture can support not only infrastructure-based
   provisioning but also infrastructure-less provisioning.  The latter
   can be supported by implementing the AA and AS on the same device.

   Also, as part of infrastructure-based provisioning, this architecture
   can support automated recommissioning with the use of service
   provider-independent authentication credentials that may be pre-
   provisioned to the UE (e.g. manufacturer provisioned credential).
   Each time recomissioning happens, new credentials that are specific
   to the new application service provider need to be generated and
   cryptographically bound to the service provider-independent
   credentials.  Note that the AS maintaining the service provider-
   independent credentials is typically different from the AS



Das & Ohba             Expires September 11, 2012               [Page 5]

Internet-Draft     EAP-Based Credentials Provisioning         March 2012


   maintaining application service provider-specific credentials.


4.  Proposed Solution

   The proposed solution is based on the requirements described in
   Section 4.1 and assumptions described in Section 4.2.

4.1.  Requirements

   1.  Solution should have the capability of integration of network
       access authentication and application access authentication

   2.  The following parameters are configured through the provisioning
       process:

       *  Identity of CoAP client used for DTLS-PSK or IKEv2

       *  Identity of CoAP server used for DTLS-PSK or IKEv2

       *  Pre-shared key used for DTLS-PSK or IKEv2

   3.  EAP [RFC3748] must be supported for an application access
       authentication protocol.  A session key must be derived from the
       EMSK key hierarchy [RFC5295].

4.2.  Assumptions

   o  UE and AS pre-configure authentication credentials required to
      authenticate to each other.

   o  Communications between AA and AS are always secured.

   o  Communications between ApS and AS are always secured.

   o  Communications between UE and AS or ApS may not be secured prior
      to credentials provisioning.

   o  UE can discover AA and ApS using mechanisms that are not specified
      in this document.

4.3.  Call Flow

   A general call flow for the proposal solution is illustrated in
   Figure 2.






Das & Ohba             Expires September 11, 2012               [Page 6]

Internet-Draft     EAP-Based Credentials Provisioning         March 2012


   UE                       AA                   AS
    |                       |                     |
    | /-------------------\ | /-----------------\ |
    |/    (1a) EAP         \|/   (1b) EAP        \|
    |\                     /|\                   /|
    | \-------------------/ | \-----------------/ |
    |                                             |
    |                      ApS                    |
    | /-------------------\ | /-----------------\ |
    |/   (2a) PSK Pull     \|/   (2b) PSK Pull   \|
    |\                     /|\   w/PSK[AS->ApS]  /|
    | \-------------------/ | \-----------------/ |
    |                       |                     |


                        Figure 2: General Call Flow

   Step 1: CoAP service access authentication is performed between the
   UE and AS via the AA using EAP.  For Use Case 2, the authentication
   agent is integrated with network access authentication where the AA
   is co-located with NAS (Network Access Server).  In Figure 2, the UE
   is an EAP peer, the AA is an EAP authenticator and the AS is an EAP
   server.  To transport EAP message between the UE and AA (Step 1a),
   PANA [RFC5191] is used as EAP lower layer for Use Case 1, and for use
   case 2, any lower layer transport may be used.  When the AA and AS
   are not co-located, a AAA protocol is used for transporting EAP
   messages between the AA and AS (Step 1b).

   Step 2: A pull key operation is performed between the UE and AS via
   the ApS to distribute PSK from the AS to the ApS.  The pull key
   operation is initiated by the UE when the UE has CoAP application
   data to send to the ApS for which a PSK is not configured yet.  After
   successful completion of Step 2, the PSK is ready to use for DTLS or
   IKEv2 between the UE and ApS.


5.  Security Considerations

   TBD.


6.  IANA Considerations

   This document includes no request to IANA.


7.  References




Das & Ohba             Expires September 11, 2012               [Page 7]

Internet-Draft     EAP-Based Credentials Provisioning         March 2012


7.1.  Normative References

   [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.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

   [RFC5191]  Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
              Yegin, "Protocol for Carrying Authentication for Network
              Access (PANA)", RFC 5191, May 2008.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 5996, September 2010.

   [I-D.ietf-core-coap]
              Frank, B., Bormann, C., Hartke, K., and Z. Shelby,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-08 (work in progress), October 2011.

7.2.  Informative References

   [RFC5295]  Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
              "Specification for the Derivation of Root Keys from an
              Extended Master Session Key (EMSK)", RFC 5295,
              August 2008.

   [ETSIM2M]  European Telecommunications Standards Institute, "Machine-
              to- Machine communications (M2M); Functional
              architecture", ETSI TS 102 690, 2011.













Das & Ohba             Expires September 11, 2012               [Page 8]

Internet-Draft     EAP-Based Credentials Provisioning         March 2012


Authors' Addresses

   Subir Das
   Applied Communication Sciences
   1 Telcordia Drive
   Piscataway, NJ  08854
   U.S.A.

   Email: subir@research.telcordia.com


   Yoshihiro Ohba
   Toshiba Corporate Research and Development Center
   1 Komukai-Toshiba-cho
   Saiwai-ku, Kawasaki, Kanagawa  212-8582
   Japan

   Phone: +81 44 549 2127
   Email: yoshihiro.ohba@toshiba.co.jp
































Das & Ohba             Expires September 11, 2012               [Page 9]