idnits 2.17.1 draft-ohba-core-eap-based-bootstrapping-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 10, 2012) is 4392 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-08 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Das 3 Internet-Draft ACS 4 Intended status: Standards Track Y. Ohba 5 Expires: September 11, 2012 Toshiba 6 March 10, 2012 8 Provisioning Credentials for CoAP Applications using EAP 9 draft-ohba-core-eap-based-bootstrapping-01 11 Abstract 13 This document first discusses the use cases where CoAP (Constrained 14 Application) requires a dynamic mechanism for provisioning 15 credentials for DTLS-PSK (Pre-Shared Key) ciphersuites and PSK mode 16 of IKEv2 and then provides an EAP (Extensible Authentication 17 Protocol) based framework to enable such scenarios. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 11, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 55 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Use Case 1: Non-integrated with Network Access 57 Authentication . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. Use Case 2: Integrated with Network Access 59 Authentication . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.3. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a web 75 protocol defined over UDP to realize the Representational State 76 Transfer (REST) architecture of the web in a suitable form for 77 constrained environments and M2M (Machine-to-Machine) applications. 78 CoAP supports a limited subset of HTTP functionality, which allows 79 straightforward mapping to HTTP. Unicast CoAP messages are secured 80 using Datagram TLS (DTLS) [RFC4347] and IPsec Encapsulating Security 81 Payload (ESP) [RFC4303]. 83 This document describes how EAP (Extensible Authentication Protocol) 84 can be used to provide credentials for DTLS-PSK (Pre-Shared Key) 85 ciphersuites and PSK mode of IKEv2 [RFC5996] that are used for 86 dynamically establishing unicast security associations. 88 Although CoAP supports multicast messaging in addition to unicast, 89 current CoAP specification does not clearly specify which security 90 protocol is used for securing multicast CoAP messages and how 91 multicast keys are established. This version of document focuses on 92 provisioning credentials for unicast security associations. 94 1.1. Specification of Requirements 96 In this document, several words are used to signify the requirements 97 of the specification. These words are often capitalized. The key 98 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 99 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 100 are to be interpreted as described in [RFC2119]. 102 2. Use Cases 104 The following uses cases are considered. 106 2.1. Use Case 1: Non-integrated with Network Access Authentication 108 This use case scenario is applicable where credentials provisioning 109 for CoAP is not facilitated by the access network authentication 110 mechanisms. Typically this type of scenario exists when there are no 111 business relationships exist between access network provider and 112 service provider. Service provider here is a provider that provides 113 CoAP-based application services. For example, access network 114 provider could be a DSL or cable provider whereas the service 115 provider could be an electric utility provider. The applicability of 116 such scenarios is depicted in more details in [ETSIM2M]. 118 Following are the advantages of credentials provisioning for CoAP in 119 this scenario: 121 o There is no requirement of having knowledge on how the access 122 network security is provided and managed. Hence there is no need 123 to have interface between access network device/gateway and 124 application device/gateway. 126 o The security credentials can be provisioned and managed directly 127 by the service provider. 129 o There is no need for manual provisioning of keys to the client and 130 server 132 o Provides a scalable architecture that does not require 133 establishing secure connection to other devices/gateways in the 134 network rather than CoAP application server. 136 2.2. Use Case 2: Integrated with Network Access Authentication 138 This use case scenario is applicable where credentials provisioning 139 for CoAP is facilitated by the access network authentication 140 mechanisms. Typically this type of scenario exists when there are 141 business relationships exist between access network provider and 142 service provider or both access network and service providers are 143 managed by the same entity or organization. For example, the access 144 network provider and the service provider both could be an electric 145 utility provider where access network is Wi-Fi mesh and the CoAP 146 application is a smart metering data application. Another example 147 could be that access network is a cellular network and there is 148 business relationship with the cellular provider and utility 149 provider. The applicability of such scenarios is depicted in more 150 details in [ETSIM2M]. 152 Following are the advantages of credentials provisioning for CoAP in 153 this scenario: 155 o The same credential and other provisioning parameters for network 156 access authentication can be used to generate the key for CoAP 157 applications 159 o No need for separate provisioning and management interface to the 160 end devices 162 o There is no need for manual provisioning of keys to the client and 163 server 165 o Provides a tightly coupled architecture that does not require 166 separate management and provisioning infrastructure. 168 3. Architecture 170 The credentials provisioing architecture is shown below where several 171 functional elements are used. The placement and consideration of 172 these functional elements do not provide any mapping to specific 173 network architecture or deployment scenarios. 175 CoAP client 176 +----+ +----+ +----+ 177 | UE |--------------------| AA |-----------------------| AS | 178 +----+ +----+ +----+ 179 | | 180 | CoAP server | 181 | +----+ | 182 +-----------------------| ApS|-------------------------+ 183 +----+ 185 Figure 1: Functional Architecture 187 UE (User Equipment): 189 A user terminal that has a CoAP client 191 ApS (Application Server): A CoAP server that provides a specific 192 application service for the UE 194 AS (Authentication Server): A server that authenticates the UE for 195 application services 197 AA (Authentication Agent): An agent that acts as an authentication 198 relay for the UE for application access authentication (e.g., 199 NAS (Network Access Server). 201 This architecture can support not only infrastructure-based 202 provisioning but also infrastructure-less provisioning. The latter 203 can be supported by implementing the AA and AS on the same device. 205 Also, as part of infrastructure-based provisioning, this architecture 206 can support automated recommissioning with the use of service 207 provider-independent authentication credentials that may be pre- 208 provisioned to the UE (e.g. manufacturer provisioned credential). 209 Each time recomissioning happens, new credentials that are specific 210 to the new application service provider need to be generated and 211 cryptographically bound to the service provider-independent 212 credentials. Note that the AS maintaining the service provider- 213 independent credentials is typically different from the AS 214 maintaining application service provider-specific credentials. 216 4. Proposed Solution 218 The proposed solution is based on the requirements described in 219 Section 4.1 and assumptions described in Section 4.2. 221 4.1. Requirements 223 1. Solution should have the capability of integration of network 224 access authentication and application access authentication 226 2. The following parameters are configured through the provisioning 227 process: 229 * Identity of CoAP client used for DTLS-PSK or IKEv2 231 * Identity of CoAP server used for DTLS-PSK or IKEv2 233 * Pre-shared key used for DTLS-PSK or IKEv2 235 3. EAP [RFC3748] must be supported for an application access 236 authentication protocol. A session key must be derived from the 237 EMSK key hierarchy [RFC5295]. 239 4.2. Assumptions 241 o UE and AS pre-configure authentication credentials required to 242 authenticate to each other. 244 o Communications between AA and AS are always secured. 246 o Communications between ApS and AS are always secured. 248 o Communications between UE and AS or ApS may not be secured prior 249 to credentials provisioning. 251 o UE can discover AA and ApS using mechanisms that are not specified 252 in this document. 254 4.3. Call Flow 256 A general call flow for the proposal solution is illustrated in 257 Figure 2. 259 UE AA AS 260 | | | 261 | /-------------------\ | /-----------------\ | 262 |/ (1a) EAP \|/ (1b) EAP \| 263 |\ /|\ /| 264 | \-------------------/ | \-----------------/ | 265 | | 266 | ApS | 267 | /-------------------\ | /-----------------\ | 268 |/ (2a) PSK Pull \|/ (2b) PSK Pull \| 269 |\ /|\ w/PSK[AS->ApS] /| 270 | \-------------------/ | \-----------------/ | 271 | | | 273 Figure 2: General Call Flow 275 Step 1: CoAP service access authentication is performed between the 276 UE and AS via the AA using EAP. For Use Case 2, the authentication 277 agent is integrated with network access authentication where the AA 278 is co-located with NAS (Network Access Server). In Figure 2, the UE 279 is an EAP peer, the AA is an EAP authenticator and the AS is an EAP 280 server. To transport EAP message between the UE and AA (Step 1a), 281 PANA [RFC5191] is used as EAP lower layer for Use Case 1, and for use 282 case 2, any lower layer transport may be used. When the AA and AS 283 are not co-located, a AAA protocol is used for transporting EAP 284 messages between the AA and AS (Step 1b). 286 Step 2: A pull key operation is performed between the UE and AS via 287 the ApS to distribute PSK from the AS to the ApS. The pull key 288 operation is initiated by the UE when the UE has CoAP application 289 data to send to the ApS for which a PSK is not configured yet. After 290 successful completion of Step 2, the PSK is ready to use for DTLS or 291 IKEv2 between the UE and ApS. 293 5. Security Considerations 295 TBD. 297 6. IANA Considerations 299 This document includes no request to IANA. 301 7. References 302 7.1. Normative References 304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, March 1997. 307 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 308 Levkowetz, "Extensible Authentication Protocol (EAP)", 309 RFC 3748, June 2004. 311 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 312 RFC 4303, December 2005. 314 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 315 Security", RFC 4347, April 2006. 317 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 318 Yegin, "Protocol for Carrying Authentication for Network 319 Access (PANA)", RFC 5191, May 2008. 321 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 322 "Internet Key Exchange Protocol Version 2 (IKEv2)", 323 RFC 5996, September 2010. 325 [I-D.ietf-core-coap] 326 Frank, B., Bormann, C., Hartke, K., and Z. Shelby, 327 "Constrained Application Protocol (CoAP)", 328 draft-ietf-core-coap-08 (work in progress), October 2011. 330 7.2. Informative References 332 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 333 "Specification for the Derivation of Root Keys from an 334 Extended Master Session Key (EMSK)", RFC 5295, 335 August 2008. 337 [ETSIM2M] European Telecommunications Standards Institute, "Machine- 338 to- Machine communications (M2M); Functional 339 architecture", ETSI TS 102 690, 2011. 341 Authors' Addresses 343 Subir Das 344 Applied Communication Sciences 345 1 Telcordia Drive 346 Piscataway, NJ 08854 347 U.S.A. 349 Email: subir@research.telcordia.com 351 Yoshihiro Ohba 352 Toshiba Corporate Research and Development Center 353 1 Komukai-Toshiba-cho 354 Saiwai-ku, Kawasaki, Kanagawa 212-8582 355 Japan 357 Phone: +81 44 549 2127 358 Email: yoshihiro.ohba@toshiba.co.jp