idnits 2.17.1 draft-selander-ace-eals-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 date (September 12, 2017) is 2418 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) == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-07 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-04 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-07 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-03 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-07 == Outdated reference: A later version (-06) exists of draft-seitz-ace-oscoap-profile-04 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group G. Selander 3 Internet-Draft Ericsson AB 4 Intended status: Standards Track S. Raza 5 Expires: March 16, 2018 RISE SICS 6 M. Vucinic 7 Inria 8 M. Furuhed 9 Nexus 10 M. Richardson 11 Sandelman Software Works 12 September 12, 2017 14 Enrollment with Application Layer Security 15 draft-selander-ace-eals-01 17 Abstract 19 This document specifies public key certificate enrollment procedures 20 authenticated with application-layer security protocols suitable for 21 Internet of Things deployments. The protocols leverage existing IoT 22 standards including Constrained Application Protocol (CoAP), Concise 23 Binary Object Representation (CBOR) and the CBOR Object Signing and 24 Encryption (COSE) format. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 16, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. CMC protocol . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Simple Enrollment . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Re-enrollment . . . . . . . . . . . . . . . . . . . . . . 5 65 2.3. Full Enrollment . . . . . . . . . . . . . . . . . . . . . 6 66 2.4. Compiling Certificate Content . . . . . . . . . . . . . . 6 67 3. Establishment of OSCOAP Input Parameters . . . . . . . . . . 7 68 3.1. EDHOC . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.2. ACE . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4. Application to 6TiSCH . . . . . . . . . . . . . . . . . . . . 10 71 5. Application to BRSKI . . . . . . . . . . . . . . . . . . . . 11 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 10.2. Informative References . . . . . . . . . . . . . . . . . 12 79 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 Asymmetric cryptography with Public Key Infrastructure (PKI) is a de- 85 facto key exchange and mutual authentication solution in the 86 Internet. Though solutions based on PSK are still state-of-the-art 87 in sensor networks they are not scalable to Internet-connected 88 billions of things. Therefore, most IoT security standards support 89 asymmetric cryptographic protocols. The greatest challenge with 90 asymmetric cryptography and PKI is enrollment, the process of 91 certifying keys. Enrollment is even more challenging in the IoT as 92 things are resource-constrained and traditional enrollment techniques 93 are not compatible with recent IoT security protocols. Without 94 secure enrollment, PKI will not be trustworthy and in turn the 95 cybersecurity of the entire system will be at stake even though the 96 underlying cryptographic cipher suites are most secure. 98 Security at the application layer provides an attractive option for 99 protecting Internet of Things (IoT) deployments, in particular in 100 constrained environments [RFC7228] and when using CoAP [RFC7252]; for 101 example where transport layer security is not sufficient 102 [I-D.hartke-core-e2e-security-reqs], or where it is beneficial that 103 the security protocol is independent of lower layers, such as when 104 securing CoAP over mixed transport protocols. 106 Application layer security protocols suitable for constrained devices 107 are in development, including the secure communication protocol 108 OSCOAP [I-D.ietf-core-object-security]. OSCOAP defines an extension 109 to the Constrained Application Protocol (CoAP) providing encryption, 110 integrity and replay protection end-to-end between CoAP client and 111 server based on a shared secret. The shared secret can be 112 established in different ways e.g. using a trusted third party such 113 as in ACE [I-D.ietf-ace-oauth-authz], or using a key exchange 114 protocol such as EDHOC [I-D.selander-ace-cose-ecdhe]. OSCOAP and 115 EDHOC can leverage other constrained device primitives developed in 116 the IETF: CoAP, CBOR [RFC7049] and COSE [RFC8152], and makes only a 117 small additional implementation footprint. 119 Lately, there has been a discussion in several IETF working groups 120 about certificate enrollment protocols suitable for IoT devices, to 121 support the use case of an IoT device joining a new network domain 122 and establishing credentials valid in this domain. This document 123 describes Enrollment with Application Layer Security (EALS), a 124 certificate enrollment protocol based on CMC [RFC5272] and using 125 OSCOAP as a secure channel. This document also describes how ACE and 126 EDHOC can be used for establishing an authenticated and authorized 127 channel. 129 This work is inspired by the Enrollment over Secure Transport (EST) 130 protocol [RFC7030], which also is based on CMC, but EALS is secured 131 on application layer instead of on transport layer. 133 1.1. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. These 138 words may also appear in this document in lowercase, absent their 139 normative meanings. 141 2. CMC protocol 143 2.1. Simple Enrollment 145 This section describes the simple enrollment protocol, which is an 146 embedding of the Simple PKI Request/Response protocol of CMC 147 [RFC5272] in Object Secure CoAP (OSCOAP) 148 [I-D.ietf-core-object-security]. 150 The simple enrollment protocol is a 2-pass protocol between an EALS 151 client (e.g. an IoT device) and an EALS server (a Certification 152 Authority (CA)), see Figure 1. The protocol assumes that both EALS 153 client and EALS server implement CoAP and the Object-Security option 154 of CoAP (OSCOAP). 156 OSCOAP assumes the existence of a shared secret between an EALS 157 client and server. The shared secret may be obtained by running a 158 key agreement algorithm or by an aid of a trusted third party. 159 Mutual authentication and authorization occurs during this key 160 agreement stage. The simple enrollment protocol may also be run 161 directly with a pre-shared key. In that case, authentication and 162 authorization of EALS client and server is implicit to the shared key 163 protecting the /eals resource. 165 EALS client EALS server 167 | | 168 | POST /eals (Object-Security; Payload: PKCS #10) | 169 +------------------------------------------------------>| 170 | | 171 | 2.04 Changed (Object-Security; Payload: PKCS #7) | 172 |<------------------------------------------------------+ 173 | | 175 Figure 1: The Simple Enrollment Protocol. 177 The simple enrollment protocol consists of a CoAP message exchange. 179 The EALS client sends a CoAP request: 181 o Method is POST 183 o Uri-Path is "eals" 185 o Object-Security option is present 186 o Payload is the CMC Simple PKI Request [RFC5272] (i.e. a PKCS #10 187 certification request). 189 If successful, the EALS server sends a CoAP response: 191 o Code is 2.04 (Changed) 193 o Content-Format is "application/pkcs7-mime" (TBD) 195 o Object-Security option is present 197 o Payload is a certs-only CMC Simple PKI Response [RFC5272] (i.e the 198 issued certificate) 200 OSCOAP protects the CoAP message exchange between the endpoints over 201 any transport and via intermediary nodes. The OSCOAP protection 202 requires that a security context is established between client and 203 server. The security context can be derived from a set of Input 204 Parameters (Section 3.3 of [I-D.ietf-core-object-security]), 205 including at least the following: 207 o Master Secret 209 o Sender ID 211 o Recipient ID 213 where the Master Secret is a uniformly random byte string, and the 214 Sender ID and Recipient ID are byte strings identifying the 215 endpoints. In Section 3 we give examples of how to the OSCOAP input 216 parameters can be established. 218 The server MUST verify that the Master Secret is associated to the 219 Distinguished Name for which the client is requesting a certificate. 221 Note 1: The encodings and formats used by CMC may later be updated 222 with other equivalents more adapted to constrained environments. 224 2.2. Re-enrollment 226 Re-enrollment and re-keying of clients occurs using the same exchange 227 as during the simple enrollment protocol. Re-enrollment request 228 follows the same format as during the simple enrollment. In case of 229 success, re-enrollment response contains certs-only CMC Simple PKI 230 Response, as in the case of simple enrollment with content-format set 231 to "application/pkcs7-mime". 233 TBD. Requirements on parsing PKCS messages and X.509 certificates 234 TBD. Error handling with CoAP error codes 236 TBD. Server-side key generation 238 2.3. Full Enrollment 240 It is straightforward to extend the simple enrollment to the CMC Full 241 PKI Request/Response protocol. 243 In this case, to authorize the PKCS#10 request to the CA, it is 244 enveloped in a CMC message and signed with a pre-installed device 245 private key and certificate by the device itself. 247 The public key in the device certificate acts as a unique identifier 248 of the device. By trusting the CA issuing the pre-installed 249 certificate, the enrolment CA can acknowledge the signed request. 250 The trusted factory CA will also ensure the origin of the device. 252 An alternative to authorize the PKCS#10 request to the CA, is to use 253 a security gateway that can envelope the request in a CMC message 254 using a certificate trusted by the CA. 256 The details are FFS. 258 2.4. Compiling Certificate Content 260 A CA have several means of compiling certificate content during 261 issuance. The subject Distinguished Name (DN) information for the 262 certificate may be based on the content of the request alone. 264 Alternatively, complementary data can be added to the request by the 265 CA from an external source trusted by the CA, or taken from records 266 of pre-registered information on end-entities that is stored in the 267 CA system and which can be uniquely matched to the data in the 268 request. Due to the constrained device capabilities the amount of 269 subject DN data in a request may be very limited. The method of 270 adding complementary data for the certificate can be a choice of the 271 CA, assuming the source of complementary data can be provided in a 272 trustworthy way. 274 With the option to add complementary data to a certificate request, 275 the end-entity provided data can be diminished by e.g. submitting 276 only the public key in the PKCS#10 content. The public key can be 277 used to match the device to pre-registered data or for retrieval of 278 subject data from other sources. 280 3. Establishment of OSCOAP Input Parameters 282 In this section we present two application layer protocols for 283 establishing OSCOAP input parameters (Section 3.3 of 284 [I-D.ietf-core-object-security]), in particular the OSCOAP master 285 secret. 287 3.1. EDHOC 289 EDHOC [I-D.selander-ace-cose-ecdhe] is a key establishment protocol, 290 corresponding to the handshake protocol of TLS, encoded with CBOR and 291 using COSE that may be transported with e.g. CoAP. EDHOC provides 292 mutual authentication of client and server and establishes a shared 293 secret with forward secrecy which may be used as OSCOAP master secret 294 in the CMC protocol (Section 2). 296 The asymmetric keys authenticated version of EDHOC is described in 297 section 4 of [I-D.selander-ace-cose-ecdhe], a simplified version of 298 the protocol is shown in Figure 2. 300 Party U Party V 301 | S_U, N_U, E_U, EXT_1 | 302 +--------------------------------------------------------->| 303 | | 304 | S_U, S_V, N_V, E_V, AEAD(EXT_2, ID_V, Sig(V; E_U, E_V)) | 305 |<---------------------------------------------------------+ 306 | | 307 | S_V, AEAD(EXT_3, ID_U, Sig(U; E_V, E_U)) | 308 +--------------------------------------------------------->| 309 | | 311 Figure 2: EDHOC with asymmetric key authentication (simplified). S = 312 session identifer, N = nonce, E = ephemeral public key, ID = 313 identifier, and EXT = application defined extension. 315 The session identifiers S_U and S_V may be used as OSCOAP input 316 parameters Sender ID and Recipient ID of party U, and v.v. as 317 described in Appendix B2 of [I-D.selander-ace-cose-ecdhe]. 319 Figure 3 shows an example of using the EDHOC protocol to establish a 320 mutually authenticated and authorized channel for the simple 321 enrolment protocol. In this case the EALS server is EDHOC client 322 (the mapping with interchanged roles is straightforward and left 323 FFS). This setting has the following properties: 325 1. The EALS server initiates the EDHOC protocol. This allows the 326 EALS server to orchestrate many concurrent enrollments, and 327 control the associated network load. 329 2. The EALS client is authenticated first (EDHOC message_2). This 330 allows the EALS server to authenticate the EALS client, and with 331 this information to authorize the EALS client before completing 332 the EDHOC protocol. The EALS server may in this case also relay 333 authorizaton information about the EALS client, such as an 334 ownership voucher, to the client in EDHOC extension EXT_3. 336 EALS EALS 337 client server 339 | | 340 | | 341 +--------------------------------------->| 342 | | 343 | EDHOC message_1 | 344 |<---------------------------------------+ 345 | | 346 | EDHOC message_2 | 347 +--------------------------------------->| Third party 348 | | < - - - - - - - - > 349 | EDHOC message_3 (EXT_3 = Authz info) | authorization 350 |<---------------------------------------+ 351 | | 353 Figure 3: EALS extension of EDHOC. 355 Appendix B1 of [I-D.selander-ace-cose-ecdhe] shows how to embed EDHOC 356 in a CoAP message exchange, a similar embedding can be applied here. 358 TBD Detail the protocol 360 3.2. ACE 362 The ACE protocol framework [I-D.ietf-ace-oauth-authz] is an 363 adaptation of OAuth 2.0 to IoT deployments. ACE describes different 364 message flows for a Client to get authorized access to a Resource 365 Server (RS) by leveraging an Authorization Server (AS). 367 The Token Introspection flow (Section 7 of 368 [I-D.ietf-ace-oauth-authz]) allows an RS to access authorization 369 information relating to a client provided Access Token. If the 370 access token is valid, the RS obtains information about the access 371 rights and a symmetric key used by the client, and also a Client 372 Token containing the same shared key protected for the legitimate 373 client (Section 7.4 of [I-D.ietf-ace-oauth-authz], Figure 4). 375 This message flow assumes that the Client and AS, as well as the RS 376 and AS, has or can establish a mutually authenticated secure channel 377 such that: 379 o The AS can encrypt the symmetric key for the Client in the Client 380 Token, and the Client can verify the Client Token is issued by the 381 AS; 383 o The RS and AS can exchange encrypted, integrity and replay 384 protected introspection messages. In this case, the establishment 385 of the secure channel can take place immediately before 386 introspection, triggered by the RS receiveing the Access Token. 388 Resource Authorization 389 Client Server Server 390 | | | 391 | | | 392 +--------------->| | 393 | POST | | 394 | Access Token | | 395 | |<- - - - - - - >| 396 | |(Authentication)| 397 | | | 398 | +--------------->| 399 | | Introspection | 400 | | Request | 401 | | | 402 | +<---------------+ 403 | | Introspection | 404 | | Response | 405 | | + Client Token | 406 |<---------------+ | 407 | 2.01 Created | | 408 | + Client Token | 410 Figure 4: ACE Token Introspection with Client Token. 412 By mapping the EALS client and server to the ACE client and resource 413 server, respectively, this application of ACE enables the 414 authorization of EALS client and establishment of a shared key, which 415 can be used as master secret with OSCOAP in the CMC protocol 416 (Section 2). In this case, the access token contains access rights 417 to /eals, but is not (yet) bound to a particular resource server. 419 The access token could be pre-provisioned to the client, e.g. during 420 manufacture. Information about binding to resource server comes with 421 the introspection response. 423 Section 2 of [I-D.seitz-ace-oscoap-profile] defines additional common 424 header parameters for COSE_Key structure that are used to carry 425 OSCOAP input parameters Sender and Recipient ID. The OSCOAP master 426 secret is transported as part of the symmetric COSE_Key object. This 427 document uses the same construct: COSE_Key object with OSCOAP input 428 parameters present is transported as part of the Introspection 429 Response and in the Client Token. 431 For the benefit of the client authorizing the enrollment, this 432 document defines an additional common parameter for the Client Token 433 called Voucher, extending the definition in Section 7.4 of 434 [I-D.ietf-ace-oauth-authz]: 436 voucher 437 OPTIONAL. Contains authorization information about the server, 438 e.g. ownership voucher. The encoding is TBD. 440 .-------------------+----------+-----------------. 441 | Parameter name | CBOR Key | Major Type | 442 |-------------------+----------+-----------------| 443 | voucher | TBD | 2 (byte string) | 444 '-------------------+----------+-----------------' 446 Figure 5: CBOR mapping of parameters extending the client token. 448 Additionally, the certificate attributes presented by the Client in 449 the enrolment request (Section 2) may be carried in the Client Token. 450 The encoding is TBD. 452 4. Application to 6TiSCH 454 One candidate embedding of EALS into a bootstrapping architecture is 455 as described in [I-D.ietf-6tisch-minimal-security]. The new device 456 (a.k.a. Pledge) requests to be admitted into the network managed by 457 the Join Registrar/Coordinator. The Pledge maps to an EALS/CoAP 458 client, and the Join Registrar/Coordinator maps to an EALS/CoAP 459 server. 461 When a pledge first joins a constrained network, it typically does 462 not have IPv6 connectivity to reach the Join Registrar/Coordinator. 463 For that reason, pledge communicates with the Join Proxy, a one hop 464 neighbor of the pledge. Join Proxy statelessly relays the exchanges 465 between the pledge and the Join Registrar/Coordinator. 467 As in the model of [I-D.ietf-6tisch-minimal-security], the Join Proxy 468 plays the role of a CoAP proxy. Default CoAP proxy, however, keeps 469 state information in order to relay the response back to the 470 originating client, in this case the pledge. To mitigate Denial of 471 Service attacks at the Join Proxy, [I-D.ietf-6tisch-minimal-security] 472 mandates the use of a new CoAP option, Stateless-Proxy option, that 473 allows the Join Proxy to operate without keeping per-client state. 475 The use of EDHOC as described in Section 3.1 enables mutual 476 authentication and authorization of Pledge and Join Registrar/ 477 Coordinator, and supports the use of the Stateless-Proxy option in 478 order to provide the CoAP Proxy functionality described in this 479 section. 481 5. Application to BRSKI 483 Another application of EALS is to the BRSKI 484 [I-D.ietf-anima-bootstrapping-keyinfra] problem statement. BRSKI 485 specifies an automated bootstrapping of a remote secure key 486 infrastructure (BRSKI) using vendor installed X.509 certificate, in 487 combination with a vendor authorized service on the Internet. BRSKI 488 is referencing Enrolment over Secure Transport (EST) [RFC7030] to 489 enable zero-touch joining of a device in a network domain. The same 490 approach can be applied using EDHOC instead of EST, as is outlined in 491 this document. 493 The audit/ownership vouchers specified in 494 [I-D.ietf-anima-bootstrapping-keyinfra] are carried as part of EDHOC 495 application-defined extensions, as described in Section 3.1. Nonces 496 of the EDHOC protocol can be used for freshness also of the 497 authorization step. 499 The limitations of applicability to energy-constrained devices due to 500 credential size applies also to this document, and further work is 501 needed to specify certificate formats relevant to constrained 502 devices. Having said that, one rationale for this document is a more 503 optimized message exchange, and potentially also code footprint, 504 which is favorable in low-power deployments. 506 6. Security Considerations 508 7. Privacy Considerations 510 8. IANA Considerations 511 9. Acknowledgments 513 The authors wants to thank the participants of the 6tisch security 514 design team for discussions and input contributing to this document. 516 10. References 518 10.1. Normative References 520 [I-D.ietf-ace-oauth-authz] 521 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 522 H. Tschofenig, "Authentication and Authorization for 523 Constrained Environments (ACE)", draft-ietf-ace-oauth- 524 authz-07 (work in progress), August 2017. 526 [I-D.ietf-core-object-security] 527 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 528 "Object Security of CoAP (OSCOAP)", draft-ietf-core- 529 object-security-04 (work in progress), July 2017. 531 [I-D.selander-ace-cose-ecdhe] 532 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 533 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 534 cose-ecdhe-07 (work in progress), July 2017. 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, 538 DOI 10.17487/RFC2119, March 1997, 539 . 541 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 542 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 543 October 2013, . 545 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 546 Application Protocol (CoAP)", RFC 7252, 547 DOI 10.17487/RFC7252, June 2014, 548 . 550 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 551 RFC 8152, DOI 10.17487/RFC8152, July 2017, 552 . 554 10.2. Informative References 556 [I-D.hartke-core-e2e-security-reqs] 557 Selander, G., Palombini, F., and K. Hartke, "Requirements 558 for CoAP End-To-End Security", draft-hartke-core-e2e- 559 security-reqs-03 (work in progress), July 2017. 561 [I-D.ietf-6tisch-minimal-security] 562 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 563 "Minimal Security Framework for 6TiSCH", draft-ietf- 564 6tisch-minimal-security-03 (work in progress), June 2017. 566 [I-D.ietf-anima-bootstrapping-keyinfra] 567 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 568 S., and K. Watsen, "Bootstrapping Remote Secure Key 569 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 570 keyinfra-07 (work in progress), July 2017. 572 [I-D.seitz-ace-oscoap-profile] 573 Seitz, L., Palombini, F., and M. Gunnarsson, "OSCOAP 574 profile of the Authentication and Authorization for 575 Constrained Environments Framework", draft-seitz-ace- 576 oscoap-profile-04 (work in progress), July 2017. 578 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 579 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 580 . 582 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 583 "Enrollment over Secure Transport", RFC 7030, 584 DOI 10.17487/RFC7030, October 2013, 585 . 587 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 588 Constrained-Node Networks", RFC 7228, 589 DOI 10.17487/RFC7228, May 2014, 590 . 592 Appendix A. Examples 594 Authors' Addresses 596 Goeran Selander 597 Ericsson AB 598 Farogatan 6 599 Kista SE-16480 Stockholm 600 Sweden 602 Email: goran.selander@ericsson.com 603 Shahid Raza 604 RISE SICS 605 Isafjordsgatan 22 606 Kista SE-16440 Stockholm 607 Sweden 609 Email: shahid.raza@ri.se 611 Malisa Vucinic 612 Inria 613 2 Rue Simone Iff 614 Paris 75012 615 France 617 Email: malisa.vucinic@inria.fr 619 Martin Furuhed 620 Nexus 621 Telefonv. 26 622 Stockholm SE-12626 623 Sweden 625 Email: martin.furuhed@nexusgroup.com 627 Michael Richardson 628 Sandelman Software Works 629 470 Dawson Avenue 630 Ottawa, ON K1Z5V7 631 Canada 633 Email: mcr+ietf@sandelman.ca