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]