idnits 2.17.1 draft-ietf-ace-cmpv2-coap-transport-03.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 (October 1, 2021) is 938 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 197 -- Looks like a reference, but probably isn't: '16' on line 198 -- Looks like a reference, but probably isn't: '17' on line 199 -- Looks like a reference, but probably isn't: '18' on line 200 == 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 (==), 5 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: April 4, 2022 October 1, 2021 7 CoAP Transfer for the Certificate Management Protocol 8 draft-ietf-ace-cmpv2-coap-transport-03 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 April 4, 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 The Certificate Management Protocol (CMP) [RFC4210] is used by the 74 PKI entities for the generation and management of certificates. One 75 of the requirements of Certificate Management Protocol is to be 76 independent of the transport protocol in use. CMP has mechanisms to 77 take care of required transactions, error reporting and protection of 78 messages. The Constrained Application Protocol (CoAP) defined in 79 [RFC7252], [RFC7959] and [RFC8323] is a client-server protocol like 80 HTTP. It is designed to be used by constrained devices over 81 constrained networks. The recommended transport for CoAP is UDP, 82 however [RFC8323] specifies the support of CoAP over TCP, TLS and 83 Websockets. 85 This document specifies the use of CoAP over UDP as a transport 86 medium for the CMP version 2 [RFC4210], CMP version 3 87 [I-D.ietf-lamps-cmp-updates] designated as CMP in this document and 88 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 89 This document, in general, follows the HTTP transfer for CMP 90 specifications defined in [RFC6712] and specifies the requirements 91 for using CoAP as a transfer mechanism for the CMP. 93 This document also provides guidance on how to use a "CoAP-to-HTTP" 94 proxy to ease adoption of CoAP transfer mechanism by enabling the 95 interconnection with existing PKI entities already providing CMP over 96 HTTP. 98 1.1. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 2. CoAP Transfer Mechanism for CMP 108 A CMP transaction consists of exchanging PKIMessages [RFC4210] 109 between PKI End Entities (EEs), Registration Authorities (RAs), and 110 Certification Authorities (CAs). If the EEs are constrained devices 111 then they may prefer, as a CMP client, the use of CoAP instead of 112 HTTP as the transfer mechanism. The RAs and CAs, in general, are not 113 constrained and can support both CoAP and HTTP Client and Server 114 implementations. This section specifies how to use CoAP as the 115 transfer mechanism for the Certificate Management Protocol. 117 2.1. CoAP URI Format 119 The CoAP URI format is described in section 6 of [RFC7252]. The CoAP 120 endpoints MUST support use of the path prefix "/.well-known/" as 121 defined in [RFC8615] and the registered name "cmp" to help with 122 endpoint discovery and interoperability. Optional path segments MAY 123 be added after the registered application name (i.e. after "/.well- 124 known/cmp") to provide distinction to support multiple PKI entities 125 on the same endpoint. A valid full operation path segment can look 126 like this: 128 coap://www.example.com/.well-known/cmp 129 coap://www.example.com/.well-known/cmp/operationalLabel 130 coap://www.example.com/.well-known/cmp/profileLabel 131 coap://www.example.com/.well-known/cmp/profileLabel/operationalLabel 133 Here operationalLabel may represent different CAs or Certificate 134 profiles or supported End Entity types and profileLabel may represent 135 different set of supported PKI operations on that particular path. 137 2.2. Discovery of CMP RA/CA 139 The EEs can be configured with enough information to form the CMP 140 server URI. The minimum information that can be configured is the 141 scheme i.e. "coap://" or "coaps://" and the authority portion of the 142 URI, e.g. "example.com:5683". If the port number is not specified in 143 the authority, then port 5683 MUST be assumed for the "coap://" 144 scheme and port 5684 MUST be assumed for the "coaps://" scheme. 145 Optionally, in the environments where a Local Registration Authority 146 (LRA) or a Local CA is deployed, EEs can also use the CoAP service 147 discovery mechanism [RFC7252] to discover the URI of the Local RA or 148 CA. The CoAP CMP endpoints supporting service discovery MUST also 149 support resource discovery in the CoRE Link Format as described in 150 [RFC6690]. The Link MUST include the 'ct' attribute defined in 151 section 7.2.1 of [RFC7252] with the value of "application/pkixcmp" as 152 defined in the CoAP Content-Formats IANA registry. 154 2.3. CoAP Request Format 156 The CMP PKIMessages MUST be DER encoded and sent as the body of the 157 CoAP POST request. A CMP client SHOULD send CoAP requests marked as 158 Confirmable message ([RFC7252] section 2.1). If the CoAP request is 159 successful then the server MUST return a "2.05 Content" response 160 code. If the CoAP request is not successful then an appropriate CoAP 161 Client Error 4.xx or a Server Error 5.xx response code MUST be 162 returned. A CMP RA or CA may chose to send a Piggybacked response 163 ([RFC7252] section 5.2.1) to the client or it MAY send a Separate 164 response ([RFC7252] section 5.2.2) in case it takes some time for CA 165 RA to process the CMP transaction. 167 When transferring CMP PKIMesssage over CoAP the media type 168 "application/pkixcmp" MUST be used. 170 2.4. CoAP Block-Wise Transfer Mode 172 A CMP PKIMesssage consists of a header, body, protection, and 173 extraCerts structures. These structures may contain many optional 174 and potentially large fields, a CMP message can be much larger than 175 the Maximum Transmission Unit (MTU) of the outgoing interface of the 176 device. In order to avoid IP fragmentation of messages exchanged 177 between EEs and RAs or CAs, the Block-Wise transfer [RFC7959] mode 178 MUST be used for the CMP Transactions over CoAP. If a CoAP-to-HTTP 179 proxy is in the path between EEs and CA or EEs and RA then it MUST 180 receive the entire body from the client before sending the HTTP 181 request to the server. This will avoid unnecessary errors in case 182 the entire content of the PKIMesssage is not received and the proxy 183 opens a connection with the server. 185 2.5. Multicast CoAP 187 CMP PKIMessages sent over CoAP MUST NOT use a Multicast destination 188 address. 190 2.6. Announcement PKIMessage 192 A CMP server may publish announcements, that can be event triggered 193 or periodic, for the other PKI entities. Here is the list of CMP 194 announcement messages prefixed by their respective ASN.1 identifier 195 (section 5.1.2 [RFC4210]) 197 [15] CA Key Update Announcement 198 [16] Certificate Announcement 199 [17] Revocation Announcement 200 [18] CRL Announcement 202 As there are no request messages specified for these announcement 203 messages, an EE MAY use CoAP Observe option [RFC7641] in the Get 204 request to the CMP server's URI followed by "/ann" to register itself 205 for any Announcements messages. If the server supports CMP 206 Announcements messages, then it can respond with response code 2.03 207 "Valid", otherwise with response code 4.04 "Not Found". If for some 208 reason server cannot add the client to its list of observers for the 209 announcements, it can omit the Observe option [RFC7641] in the 2.03 210 response to the client. A client on receiving 2.03 response without 211 Observe option [RFC7641] can try after some time to register again 212 for announcements from the CMP server. 214 Alternatively an EE MAY poll for the potential changes via "PKI 215 Information" request using "PKI General Message" defined in the 216 PKIMessage [RFC4210] for various type of changes like CA key update 217 or to get current CRL [RFC5280] to check revocation or using Support 218 messages defined in section 5.4 of Lightweight CMP Profile 219 [I-D.ietf-lamps-lightweight-cmp-profile] . This will help constrained 220 devices that are acting as EEs conserve resources by eliminating the 221 need to create an endpoint for receiving notifications from RA or CA. 222 It will also simplify the implementation of CoAP-to-HTTP proxy. 224 3. Using CoAP over DTLS 226 Although CMP protocol does not depend upon the underlying transfer 227 mechanism for protecting the messages but in cases when an end to end 228 secrecy is desired for the CoAP, CoAP over DTLS [I-D.ietf-tls-dtls13] 229 SHOULD be used. Section 9.1 of [RFC7252] defines how to use DTLS 230 [I-D.ietf-tls-dtls13] for securing the CoAP. Once a DTLS 231 [I-D.ietf-tls-dtls13] connection is established it SHOULD be used for 232 as long as possible to avoid the frequent overhead of setting up a 233 DTLS [I-D.ietf-tls-dtls13] connection for constrained devices. 235 4. Proxy Support 237 This section provides guidance on using a CoAP-to-HTTP proxy between 238 EEs and RAs or CAs in order to avoid changes to the existing PKI 239 implementation. Since the CMP payload is same over CoAP and HTTP 240 transfer mechanisms, a CoAP-to-HTTP cross-protocol proxy can be 241 implemented based on section 10 of [RFC7252] . The CoAP-to-HTTP proxy 242 can be either located closer to the EEs or closer to the RA or CA. 243 In case the proxy is deployed closer to the EEs then it may also 244 support service discovery and resource discovery as described in 245 section 2.2. The CoAP-to-HTTP proxy MUST function as a reverse 246 proxy, only permitting connections to a limited set of pre-configured 247 servers. It is out of scope of this document on how a reverse proxy 248 can route CoAP client requests to one of the configured servers. 249 Some recommended mechanisms are as follows: 251 o Use Uri-Path option to identify a server. 252 o Use separate hostnames for each of the configured servers and then 253 use the Uri-Host option for routing the CoAP requests. 254 o Use separate hostnames for each of the configured servers and then 255 use Server Name Indication ( [RFC8446] ) in case of "coaps://" 256 scheme for routing CoAP requests. 258 5. Security Considerations 260 The CMP protocol depends upon various mechanisms in the protocol 261 itself for making the transactions secure therefore security issues 262 of CoAP due to using UDP do not carry over to the CMP layer. However 263 the CoAP is vulnerable to many issues due to the connectionless 264 characteristics of UDP itself. The Security considerations for CoAP 265 are mentioned in the [RFC7252] . 267 In order to to reduce the risks imposed by DoS attacks, the 268 implementations SHOULD minimize fragmentation of messages, i.e. avoid 269 small packets containing partial CMP PKIMessage data. 271 A CoAP-to-HTTP proxy can also protect the PKI entities from various 272 attacks by enforcing basic checks and validating messages before 273 sending them to PKI entities. Proxy can be deployed at the edge of 274 End Entities" network or in front of an RA and CA to protect them. 276 6. IANA Considerations 278 This document requires a new entry to the CoAP Content-Formats 279 Registry code for the content-type "application/pkixcmp" for 280 transfering CMP transactions over CoAP. 282 Type name: application 283 Subtype name: pkixcmp 285 7. Acknowledgments 287 The authors would like to thank Hendrik Brockhaus, David von Oheimb, 288 and Andreas Kretschmer for their guidance in writing the content of 289 this document and providing valuable feedback. 291 8. References 293 8.1. Normative References 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, 297 DOI 10.17487/RFC2119, March 1997, 298 . 300 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 301 "Internet X.509 Public Key Infrastructure Certificate 302 Management Protocol (CMP)", RFC 4210, 303 DOI 10.17487/RFC4210, September 2005, 304 . 306 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 307 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 308 . 310 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 311 Infrastructure -- HTTP Transfer for the Certificate 312 Management Protocol (CMP)", RFC 6712, 313 DOI 10.17487/RFC6712, September 2012, 314 . 316 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 317 Application Protocol (CoAP)", RFC 7252, 318 DOI 10.17487/RFC7252, June 2014, 319 . 321 [RFC7641] Hartke, K., "Observing Resources in the Constrained 322 Application Protocol (CoAP)", RFC 7641, 323 DOI 10.17487/RFC7641, September 2015, 324 . 326 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 327 the Constrained Application Protocol (CoAP)", RFC 7959, 328 DOI 10.17487/RFC7959, August 2016, 329 . 331 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 332 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 333 May 2017, . 335 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 336 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 337 . 339 8.2. Informative References 341 [I-D.ietf-lamps-cmp-updates] 342 Brockhaus, H. and D. von Oheimb, "Certificate Management 343 Protocol (CMP) Updates", draft-ietf-lamps-cmp-updates-12 344 (work in progress), July 2021. 346 [I-D.ietf-lamps-lightweight-cmp-profile] 347 Brockhaus, H., Fries, S., and D. von Oheimb, "Lightweight 348 Certificate Management Protocol (CMP) Profile", draft- 349 ietf-lamps-lightweight-cmp-profile-06 (work in progress), 350 July 2021. 352 [I-D.ietf-tls-dtls13] 353 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 354 Datagram Transport Layer Security (DTLS) Protocol Version 355 1.3", draft-ietf-tls-dtls13-43 (work in progress), April 356 2021. 358 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 359 Housley, R., and W. Polk, "Internet X.509 Public Key 360 Infrastructure Certificate and Certificate Revocation List 361 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 362 . 364 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 365 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 366 Application Protocol) over TCP, TLS, and WebSockets", 367 RFC 8323, DOI 10.17487/RFC8323, February 2018, 368 . 370 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 371 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 372 . 374 Authors' Addresses 375 Mohit Sahni (editor) 376 Palo Alto Networks 377 3000 Tannery Way 378 Santa Clara, CA 95054 379 US 381 EMail: msahni@paloaltonetworks.com 383 Saurabh Tripathi (editor) 384 Palo Alto Networks 385 3000 Tannery Way 386 Santa Clara, CA 95054 387 US 389 EMail: stripathi@paloaltonetworks.com