idnits 2.17.1 draft-ohba-core-eap-based-bootstrapping-00.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 == Line 8 has weird spacing: '...cations for R...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 1, 2011) is 4677 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-06 Summary: 2 errors (**), 0 flaws (~~), 4 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 Telcordia 4 Intended status: Standards Track Y. Ohba 5 Expires: January 2, 2012 Toshiba 6 July 1, 2011 8 Bootstrapping CoAP Applications for Resource-Constrained Devices using 9 EAP 10 draft-ohba-core-eap-based-bootstrapping-00 12 Abstract 14 This document describes a mechanism to use EAP (Extensible 15 Authentication Protocol) for bootstrapping DTLS-PSK (Pre-Shared Key) 16 ciphersuites and PSK mode of IKEv2 that are used for establishing a 17 secure communication channel between a CoAP (Constrained Application) 18 client and a CoAP server to protect CoAP messaging. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 2, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 56 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Use Case 1: Non-integrated with Network Access 58 Authentication . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Use Case 2: Integrated with Network Access 60 Authentication . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.3. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a web 76 protocol defined over UDP to realize the Representational State 77 Transfer (REST) architecture of the web in a suitable form for 78 constrained environments and M2M (Machine-to-Machine) applications. 79 CoAP supports a limited subset of HTTP functionality, which allows 80 straightforward mapping to HTTP. Unicast CoAP messages are secured 81 using Datagram TLS (DTLS) [RFC4347] and IPsec Encapsulating Security 82 Payload (ESP) [RFC4303]. 84 This document describes how EAP (Extensible Authentication Protocol) 85 can be used to bootstrap DTLS-PSK (Pre-Shared Key) ciphersuites and 86 PSK mode of IKEv2 [RFC5996] that are used for dynamically 87 establishing unicast security associations. 89 Although CoAP supports multicast messaging in addition to unicast, 90 current CoAP specification does not clearly specify which security 91 protocol is used for securing multicast CoAP messages and how 92 multicast keys are established. This version of document focuses on 93 bootstrapping unicast security associations. 95 1.1. Specification of Requirements 97 In this document, several words are used to signify the requirements 98 of the specification. These words are often capitalized. The key 99 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 100 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 101 are to be interpreted as described in [RFC2119]. 103 2. Use Cases 105 The following uses cases are considered. 107 2.1. Use Case 1: Non-integrated with Network Access Authentication 109 This use case scenario is applicable where CoAP applications 110 bootstrap is not facilitated by the access network authentication 111 mechanisms. Typically this type of scenario exists when there are no 112 business relationships exist between access network provider and 113 service provider. Service provider here is a provider that provides 114 CoAP-based application services. For example, access network 115 provider could be a DSL or cable provider whereas the service 116 provider could be an electric utility provider. The applicability of 117 such scenarios is depicted in more details in [ETSIM2M]. 119 Following are the advantages of bootstrapping applications in this 120 scenario: 122 o There is no requirement of having knowledge on how the access 123 network security is provided and managed. Hence there is no need 124 to have interface between access network device/gateway and 125 application device/gateway. 127 o The security credentials can be provisioned and managed directly 128 by the service provider. 130 o There is no need for manual provisioning of keys to the client and 131 server 133 o Provides a scalable architecture that does not require 134 establishing secure connection to other devices/gateways in the 135 network rather than CoAP application server. 137 2.2. Use Case 2: Integrated with Network Access Authentication 139 This use case scenario is applicable where CoAP applications 140 bootstrap is facilitated by the access network authentication 141 mechanisms. Typically this type of scenario exists when there are 142 business relationships exist between access network provider and 143 service provider or both access network and service providers are 144 managed by the same entity or organization. For example, the access 145 network provider and the service provider both could be an electric 146 utility provider where access network is Wi-Fi mesh and the CoAP 147 application is a smart metering data application. Another example 148 could be that access network is a cellular network and there is 149 business relationship with the cellular provider and utility 150 provider. The applicability of such scenarios is depicted in more 151 details in [ETSIM2M]. 153 Following are the advantages of bootstrapping applications in this 154 scenario: 156 o The same credential and other provisioning parameters for network 157 access authentication can be used to generate the key for CoAP 158 applications 160 o No need for separate provisioning and management interface to the 161 end devices 163 o There is no need for manual provisioning of keys to the client and 164 server 166 o Provides a tightly coupled architecture that does not require 167 separate management and provisioning infrastructure. 169 3. Architecture 171 The bootstrapping architecture is shown below where several 172 functional elements are used. The placement and consideration of 173 these functional elements do not provide any mapping to specific 174 network architecture or deployment scenarios. 176 CoAP client 177 +----+ +----+ +----+ 178 | UE |--------------------| AA |-----------------------| AS | 179 +----+ +----+ +----+ 180 | | 181 | CoAP server | 182 | +----+ | 183 +-----------------------| ApS|-------------------------+ 184 +----+ 186 Figure 1: Functional Architecture 188 UE (User Equipment): 190 A user terminal that has a CoAP client 192 ApS (Application Server): A CoAP server that provides a specific 193 application service for the UE 195 AS (Authentication Server): A server that authenticates the UE for 196 application services 198 AA (Authentication Agent): An agent that acts as an authentication 199 relay for the UE for application access authentication (e.g., 200 NAS (Network Access Server). 202 This architecture can support not only infrastructur-based 203 bootstrapping but also infrastructure-less bootstrapping. The latter 204 can be supported by implementing the AA and AS on the same device. 206 Also, as part of infrastructure-based bootstrapping, this 207 architecture can support automated recommissioning with the use of 208 service provider-independent authentication credentials that may be 209 pre-provisioned to the UE (e.g. manufacturer provisioned credential). 210 Each time recomissioning happens, new authentication credentials that 211 are specific to the new application service provider need to be 212 generated and cryptographically bound to the service provider- 213 independent authentication credentials. Note that the AS maintaining 214 the service provider-independent authentication credentials is 215 typically different from the AS maintaining application service 216 provider-specific authentication credentials. 218 4. Proposed Solution 220 The proposed solution is based on the requirements described in 221 Section 4.1 and assumptions described in Section 4.2. 223 4.1. Requirements 225 1. Solution should have the capability of integration of network 226 access authentication and application access authentication 228 2. The following parameters are configured through the bootstrapping 229 process: 231 * Identity of CoAP client used for DTLS-PSK or IKEv2 233 * Identity of CoAP server used for DTLS-PSK or IKEv2 235 * Pre-shared key used for DTLS-PSK or IKEv2 237 3. EAP [RFC3748] must be supported for an application access 238 authentication protocol. A session key must be derived from the 239 EMSK key hierarchy [RFC5295]. 241 4.2. Assumptions 243 o UE and AS pre-configure authentication credentials required to 244 authenticate to each other. 246 o Communications between AA and AS are always secured. 248 o Communications between ApS and AS are always secured. 250 o Communications between UE and AS or ApS may not be secured prior 251 to bootstrapping CoAP. 253 o UE can discover AA and ApS using mechanisms that are not specified 254 in this document. 256 4.3. Call Flow 258 A general call flow for the proposal solution is illustrated in 259 Figure 2. 261 UE AA AS 262 | | | 263 | /-------------------\ | /-----------------\ | 264 |/ (1a) EAP \|/ (1b) EAP \| 265 |\ /|\ /| 266 | \-------------------/ | \-----------------/ | 267 | | 268 | ApS | 269 | /-------------------\ | /-----------------\ | 270 |/ (2a) PSK Pull \|/ (2b) PSK Pull \| 271 |\ /|\ w/PSK[AS->ApS] /| 272 | \-------------------/ | \-----------------/ | 273 | | | 275 Figure 2: General Call Flow 277 Step 1: CoAP service access authentication is performed between the 278 UE and AS via the AA using EAP. For Use Case 2, the authentication 279 agent is integrated with network access authentication where the AA 280 is co-located with NAS (Network Access Server). In Figure 2, the UE 281 is an EAP peer, the AA is an EAP authenticator and the AS is an EAP 282 server. To transport EAP message between the UE and AA (Step 1a), 283 PANA [RFC5191] is used as EAP lower layer for Use Case 1, and for use 284 case 2, any lower layer transport may be used. When the AA and AS 285 are not co-located, a AAA protocol is used for transporting EAP 286 messages between the AA and AS (Step 1b). 288 Step 2: A pull key operation is performed between the UE and AS via 289 the ApS to distribute PSK from the AS to the ApS. The pull key 290 operation is initiated by the UE when the UE has CoAP application 291 data to send to the ApS for which a PSK is not configured yet. After 292 successful completion of Step 2, the PSK is ready to use for DTLS or 293 IKEv2 between the UE and ApS. 295 5. Security Considerations 297 TBD. 299 6. IANA Considerations 301 This document includes no request to IANA. 303 7. References 304 7.1. Normative References 306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", BCP 14, RFC 2119, March 1997. 309 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 310 Levkowetz, "Extensible Authentication Protocol (EAP)", 311 RFC 3748, June 2004. 313 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 314 RFC 4303, December 2005. 316 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 317 Security", RFC 4347, April 2006. 319 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 320 Yegin, "Protocol for Carrying Authentication for Network 321 Access (PANA)", RFC 5191, May 2008. 323 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 324 "Internet Key Exchange Protocol Version 2 (IKEv2)", 325 RFC 5996, September 2010. 327 [I-D.ietf-core-coap] 328 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 329 "Constrained Application Protocol (CoAP)", 330 draft-ietf-core-coap-06 (work in progress), May 2011. 332 7.2. Informative References 334 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 335 "Specification for the Derivation of Root Keys from an 336 Extended Master Session Key (EMSK)", RFC 5295, 337 August 2008. 339 [ETSIM2M] European Telecommunications Standards Institute, "Machine- 340 to- Machine communications (M2M); Functional 341 architecture", ETSI TS 102 690, 2011. 343 Authors' Addresses 345 Subir Das 346 Telcordia Technologies Inc. 347 1 Telcordia Drive 348 Piscataway, NJ 08854 349 U.S.A. 351 Email: subir@research.telcordia.com 353 Yoshihiro Ohba 354 Toshiba Corporate Research and Development Center 355 1 Komukai-Toshiba-cho 356 Saiwai-ku, Kawasaki, Kanagawa 212-8582 357 Japan 359 Phone: +81 44 549 2127 360 Email: yoshihiro.ohba@toshiba.co.jp