idnits 2.17.1 draft-ietf-ace-cmpv2-coap-transport-04.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 8, 2021) is 898 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) -- Looks like a reference, but probably isn't: '15' on line 198 -- Looks like a reference, but probably isn't: '16' on line 199 -- Looks like a reference, but probably isn't: '17' on line 200 -- Looks like a reference, but probably isn't: '18' on line 201 -- Looks like a reference, but probably isn't: '1' on line 391 -- Looks like a reference, but probably isn't: '2' on line 394 == Outdated reference: A later version (-23) exists of draft-ietf-lamps-cmp-updates-12 == Outdated reference: A later version (-21) exists of draft-ietf-lamps-lightweight-cmp-profile-06 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE M. Sahni, Ed. 3 Internet-Draft S. Tripathi, Ed. 4 Intended status: Standards Track Palo Alto Networks 5 Expires: May 12, 2022 November 8, 2021 7 CoAP Transfer for the Certificate Management Protocol 8 draft-ietf-ace-cmpv2-coap-transport-04 10 Abstract 12 This document specifies the use of Constrained Application Protocol 13 (CoAP) as a transfer mechanism for the Certificate Management 14 Protocol (CMP). purpose of certificate creation and management. 15 CoAP is an HTTP like client-server protocol used by various 16 constrained devices in the IoT space. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 12, 2022. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. CoAP Transfer Mechanism for CMP . . . . . . . . . . . . . . . 3 55 2.1. CoAP URI Format . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Discovery of CMP RA/CA . . . . . . . . . . . . . . . . . 3 57 2.3. CoAP Request Format . . . . . . . . . . . . . . . . . . . 4 58 2.4. CoAP Block-Wise Transfer Mode . . . . . . . . . . . . . . 4 59 2.5. Multicast CoAP . . . . . . . . . . . . . . . . . . . . . 4 60 2.6. Announcement PKIMessage . . . . . . . . . . . . . . . . . 5 61 3. Using CoAP over DTLS . . . . . . . . . . . . . . . . . . . . 5 62 4. Proxy Support . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . 8 69 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 The Certificate Management Protocol (CMP) [RFC4210] is used by the 75 PKI entities for the generation and management of certificates. One 76 of the requirements of Certificate Management Protocol is to be 77 independent of the transport protocol in use. CMP has mechanisms to 78 take care of required transactions, error reporting and protection of 79 messages. The Constrained Application Protocol (CoAP) defined in 80 [RFC7252], [RFC7959] and [RFC8323] is a client-server protocol like 81 HTTP. It is designed to be used by constrained devices over 82 constrained networks. The recommended transport for CoAP is UDP, 83 however [RFC8323] specifies the support of CoAP over TCP, TLS and 84 Websockets. 86 This document specifies the use of CoAP over UDP as a transport 87 medium for the CMP version 2 [RFC4210], CMP version 3 88 [I-D.ietf-lamps-cmp-updates] designated as CMP in this document and 89 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 90 This document, in general, follows the HTTP transfer for CMP 91 specifications defined in [RFC6712] and specifies the requirements 92 for using CoAP as a transfer mechanism for the CMP. 94 This document also provides guidance on how to use a "CoAP-to-HTTP" 95 proxy to ease adoption of CoAP transfer mechanism by enabling the 96 interconnection with existing PKI entities already providing CMP over 97 HTTP. 99 1.1. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 2. CoAP Transfer Mechanism for CMP 109 A CMP transaction consists of exchanging PKIMessages [RFC4210] 110 between PKI End Entities (EEs), Registration Authorities (RAs), and 111 Certification Authorities (CAs). If the EEs are constrained devices 112 then they may prefer, as a CMP client, the use of CoAP instead of 113 HTTP as the transfer mechanism. The RAs and CAs, in general, are not 114 constrained and can support both CoAP and HTTP Client and Server 115 implementations. This section specifies how to use CoAP as the 116 transfer mechanism for the Certificate Management Protocol. 118 2.1. CoAP URI Format 120 The CoAP URI format is described in section 6 of [RFC7252]. The CoAP 121 endpoints MUST support use of the path prefix "/.well-known/" as 122 defined in [RFC8615] and the registered name "cmp" to help with 123 endpoint discovery and interoperability. Optional path segments MAY 124 be added after the registered application name (i.e. after "/.well- 125 known/cmp") to provide distinction to support multiple PKI entities 126 on the same endpoint. A valid full operation path segment can look 127 like this: 129 coap://www.example.com/.well-known/cmp 130 coap://www.example.com/.well-known/cmp/operationalLabel 131 coap://www.example.com/.well-known/cmp/profileLabel 132 coap://www.example.com/.well-known/cmp/profileLabel/operationalLabel 134 Here operationalLabel may represent different CAs or Certificate 135 profiles or supported End Entity types and profileLabel may represent 136 different set of supported PKI operations on that particular path. 138 2.2. Discovery of CMP RA/CA 140 The EEs can be configured with enough information to form the CMP 141 server URI. The minimum information that can be configured is the 142 scheme i.e. "coap://" or "coaps://" and the authority portion of the 143 URI, e.g. "example.com:5683". If the port number is not specified in 144 the authority, then port 5683 MUST be assumed for the "coap://" 145 scheme and port 5684 MUST be assumed for the "coaps://" scheme. 146 Optionally, in the environments where a Local Registration Authority 147 (LRA) or a Local CA is deployed, EEs can also use the CoAP service 148 discovery mechanism [RFC7252] to discover the URI of the Local RA or 149 CA. The CoAP CMP endpoints supporting service discovery MUST also 150 support resource discovery in the CoRE Link Format as described in 151 [RFC6690]. The Link MUST include the 'ct' attribute defined in 152 section 7.2.1 of [RFC7252] with the value of "application/pkixcmp" as 153 defined in the CoAP Content-Formats IANA registry. 155 2.3. CoAP Request Format 157 The CMP PKIMessages MUST be DER encoded and sent as the body of the 158 CoAP POST request. A CMP client SHOULD send CoAP requests marked as 159 Confirmable message ([RFC7252] section 2.1). If the CoAP request is 160 successful then the server MUST return a "2.05 Content" response 161 code. If the CoAP request is not successful then an appropriate CoAP 162 Client Error 4.xx or a Server Error 5.xx response code MUST be 163 returned. A CMP RA or CA may chose to send a Piggybacked response 164 ([RFC7252] section 5.2.1) to the client or it MAY send a Separate 165 response ([RFC7252] section 5.2.2) in case it takes some time for CA 166 RA to process the CMP transaction. 168 When transferring CMP PKIMesssage over CoAP the media type 169 "application/pkixcmp" MUST be used. 171 2.4. CoAP Block-Wise Transfer Mode 173 A CMP PKIMesssage consists of a header, body, protection, and 174 extraCerts structures. These structures may contain many optional 175 and potentially large fields, a CMP message can be much larger than 176 the Maximum Transmission Unit (MTU) of the outgoing interface of the 177 device. In order to avoid IP fragmentation of messages exchanged 178 between EEs and RAs or CAs, the Block-Wise transfer [RFC7959] mode 179 MUST be used for the CMP Transactions over CoAP. If a CoAP-to-HTTP 180 proxy is in the path between EEs and CA or EEs and RA then it MUST 181 receive the entire body from the client before sending the HTTP 182 request to the server. This will avoid unnecessary errors in case 183 the entire content of the PKIMesssage is not received and the proxy 184 opens a connection with the server. 186 2.5. Multicast CoAP 188 CMP PKIMessages sent over CoAP MUST NOT use a Multicast destination 189 address. 191 2.6. Announcement PKIMessage 193 A CMP server may publish announcements, that can be event triggered 194 or periodic, for the other PKI entities. Here is the list of CMP 195 announcement messages prefixed by their respective ASN.1 identifier 196 (section 5.1.2 [RFC4210]) 198 [15] CA Key Update Announcement 199 [16] Certificate Announcement 200 [17] Revocation Announcement 201 [18] CRL Announcement 203 As there are no request messages specified for these announcement 204 messages, an EE MAY use CoAP Observe option [RFC7641] in the Get 205 request to the CMP server's URI followed by "/ann" to register itself 206 for any Announcements messages. If the server supports CMP 207 Announcements messages, then it can respond with response code 2.03 208 "Valid", otherwise with response code 4.04 "Not Found". If for some 209 reason server cannot add the client to its list of observers for the 210 announcements, it can omit the Observe option [RFC7641] in the 2.03 211 response to the client. A client on receiving 2.03 response without 212 Observe option [RFC7641] can try after some time to register again 213 for announcements from the CMP server. 215 Alternatively an EE MAY poll for the potential changes via "PKI 216 Information" request using "PKI General Message" defined in the 217 PKIMessage [RFC4210] for various type of changes like CA key update 218 or to get current CRL [RFC5280] to check revocation or using Support 219 messages defined in section 5.4 of Lightweight CMP Profile 220 [I-D.ietf-lamps-lightweight-cmp-profile] . This will help constrained 221 devices that are acting as EEs conserve resources by eliminating the 222 need to create an endpoint for receiving notifications from RA or CA. 223 It will also simplify the implementation of CoAP-to-HTTP proxy. 225 3. Using CoAP over DTLS 227 Although CMP protocol does not depend upon the underlying transfer 228 mechanism for protecting the messages but in cases when an end to end 229 secrecy is desired for the CoAP, CoAP over DTLS [I-D.ietf-tls-dtls13] 230 SHOULD be used. Section 9.1 of [RFC7252] defines how to use DTLS 231 [I-D.ietf-tls-dtls13] for securing the CoAP. Once a DTLS 232 [I-D.ietf-tls-dtls13] connection is established it SHOULD be used for 233 as long as possible to avoid the frequent overhead of setting up a 234 DTLS [I-D.ietf-tls-dtls13] connection for constrained devices. 236 4. Proxy Support 238 This section provides guidance on using a CoAP-to-HTTP proxy between 239 EEs and RAs or CAs in order to avoid changes to the existing PKI 240 implementation. Since the CMP payload is same over CoAP and HTTP 241 transfer mechanisms, a CoAP-to-HTTP cross-protocol proxy can be 242 implemented based on section 10 of [RFC7252] . The CoAP-to-HTTP proxy 243 can be either located closer to the EEs or closer to the RA or CA. 244 In case the proxy is deployed closer to the EEs then it may also 245 support service discovery and resource discovery as described in 246 section 2.2. The CoAP-to-HTTP proxy MUST function as a reverse 247 proxy, only permitting connections to a limited set of pre-configured 248 servers. It is out of scope of this document on how a reverse proxy 249 can route CoAP client requests to one of the configured servers. 250 Some recommended mechanisms are as follows: 252 o Use Uri-Path option to identify a server. 253 o Use separate hostnames for each of the configured servers and then 254 use the Uri-Host option for routing the CoAP requests. 255 o Use separate hostnames for each of the configured servers and then 256 use Server Name Indication ( [RFC8446] ) in case of "coaps://" 257 scheme for routing CoAP requests. 259 5. Security Considerations 261 The CMP protocol depends upon various mechanisms in the protocol 262 itself for making the transactions secure therefore security issues 263 of CoAP due to using UDP do not carry over to the CMP layer. However 264 the CoAP is vulnerable to many issues due to the connectionless 265 characteristics of UDP itself. The Security considerations for CoAP 266 are mentioned in the [RFC7252]. 268 In order to to reduce the risks imposed by DoS attacks, the 269 implementations SHOULD minimize fragmentation of messages, i.e. avoid 270 small packets containing partial CMP PKIMessage data. 272 A CoAP-to-HTTP proxy can also protect the PKI entities from various 273 attacks by enforcing basic checks and validating messages before 274 sending them to PKI entities. Proxy can be deployed at the edge of 275 End Entities" network or in front of an RA and CA to protect them. 277 6. IANA Considerations 279 This document requires a new entry to the CoAP Content-Formats 280 Registry code for the content-type "application/pkixcmp" for 281 transferring CMP transactions over CoAP from the identifier range 282 256-9999 reserved for IETF specifications. 284 Type name: application 286 Subtype name: pkixcmp 288 Encoding: Content may contain arbitrary octet values. The octet 289 values are the ASN.1 DER encoding of a PKI message, as defined in the 290 [RFC4210] specifications. 292 Reference: This document and [RFC4210] 294 This document references the cmp, a temporary entry, in the Well- 295 Known URIs [1] IANA registry. This document is expected to be 296 published together with [I-D.ietf-lamps-cmp-updates] that makes the 297 cmp registry entry permanent. Please add a reference of this 298 document to the Well-Known URIs [2] IANA registry for that entry 300 7. Acknowledgments 302 The authors would like to thank Hendrik Brockhaus, David von Oheimb, 303 and Andreas Kretschmer for their guidance in writing the content of 304 this document and providing valuable feedback. 306 8. References 308 8.1. Normative References 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, 312 DOI 10.17487/RFC2119, March 1997, 313 . 315 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 316 "Internet X.509 Public Key Infrastructure Certificate 317 Management Protocol (CMP)", RFC 4210, 318 DOI 10.17487/RFC4210, September 2005, 319 . 321 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 322 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 323 . 325 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 326 Infrastructure -- HTTP Transfer for the Certificate 327 Management Protocol (CMP)", RFC 6712, 328 DOI 10.17487/RFC6712, September 2012, 329 . 331 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 332 Application Protocol (CoAP)", RFC 7252, 333 DOI 10.17487/RFC7252, June 2014, 334 . 336 [RFC7641] Hartke, K., "Observing Resources in the Constrained 337 Application Protocol (CoAP)", RFC 7641, 338 DOI 10.17487/RFC7641, September 2015, 339 . 341 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 342 the Constrained Application Protocol (CoAP)", RFC 7959, 343 DOI 10.17487/RFC7959, August 2016, 344 . 346 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 347 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 348 May 2017, . 350 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 351 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 352 . 354 8.2. Informative References 356 [I-D.ietf-lamps-cmp-updates] 357 Brockhaus, H. and D. von Oheimb, "Certificate Management 358 Protocol (CMP) Updates", draft-ietf-lamps-cmp-updates-12 359 (work in progress), July 2021. 361 [I-D.ietf-lamps-lightweight-cmp-profile] 362 Brockhaus, H., Fries, S., and D. von Oheimb, "Lightweight 363 Certificate Management Protocol (CMP) Profile", draft- 364 ietf-lamps-lightweight-cmp-profile-06 (work in progress), 365 July 2021. 367 [I-D.ietf-tls-dtls13] 368 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 369 Datagram Transport Layer Security (DTLS) Protocol Version 370 1.3", draft-ietf-tls-dtls13-43 (work in progress), April 371 2021. 373 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 374 Housley, R., and W. Polk, "Internet X.509 Public Key 375 Infrastructure Certificate and Certificate Revocation List 376 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 377 . 379 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 380 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 381 Application Protocol) over TCP, TLS, and WebSockets", 382 RFC 8323, DOI 10.17487/RFC8323, February 2018, 383 . 385 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 386 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 387 . 389 8.3. URIs 391 [1] https://www.iana.org/assignments/well-known-uris/well-known- 392 uris.xhtml 394 [2] https://www.iana.org/assignments/well-known-uris/well-known- 395 uris.xhtml 397 Authors' Addresses 399 Mohit Sahni (editor) 400 Palo Alto Networks 401 3000 Tannery Way 402 Santa Clara, CA 95054 403 US 405 EMail: msahni@paloaltonetworks.com 407 Saurabh Tripathi (editor) 408 Palo Alto Networks 409 3000 Tannery Way 410 Santa Clara, CA 95054 411 US 413 EMail: stripathi@paloaltonetworks.com