idnits 2.17.1 draft-msahni-ace-cmpv2-coap-transport-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([Lightweight-CMP-Profile]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: CMPv2 PKIMessage request messages sent from EEs to RAs or from EEs to CAs over CoAP transport MUST not use a Multicast destination address. -- The document date (October 5, 2020) is 1293 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) == Missing Reference: 'Lightweight-CMP-Profile' is mentioned on line 310, but not defined -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 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 8, 2021 October 5, 2020 7 CoAP Transport for CMPV2 8 draft-msahni-ace-cmpv2-coap-transport-01 10 Abstract 12 This document specifies the use of Constrained Application Protocol 13 (CoAP) as a transport medium for the Certificate Management Protocol 14 Version 2 (CMPv2) and Lightweight CMP Profile 15 [Lightweight-CMP-Profile] CMPv2 defines the interaction between 16 various PKI entities for the purpose of certificate creation and 17 management. CoAP is an HTTP like client-server protocol used by 18 various constrained devices in IoT space. 20 Status of This Memo 22 This Internet-Draft is submitted 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 https://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 April 8, 2021. 37 Copyright Notice 39 Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. CoAP Transport For CMPv2 . . . . . . . . . . . . . . . . . . 3 57 2.1. Discovery of CMP Entities . . . . . . . . . . . . . . . . 3 58 2.2. CoAP URI Format . . . . . . . . . . . . . . . . . . . . . 3 59 2.3. CoAP Request Format . . . . . . . . . . . . . . . . . . . 4 60 2.4. CoAP Content-Format . . . . . . . . . . . . . . . . . . . 4 61 2.5. Announcement PKIMessage . . . . . . . . . . . . . . . . . 4 62 2.6. CoAP Block Wise Transfer Mode . . . . . . . . . . . . . . 4 63 2.7. Multicast CoAP . . . . . . . . . . . . . . . . . . . . . 4 64 3. Using CoAP over DTLS . . . . . . . . . . . . . . . . . . . . 4 65 4. Proxy support . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. CoAP to HTTP Proxy . . . . . . . . . . . . . . . . . . . 5 67 4.2. CoAPs to HTTPs Proxy . . . . . . . . . . . . . . . . . . 5 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 8.2. Informative References . . . . . . . . . . . . . . . . . 7 74 8.3. URL References . . . . . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 The CMPv2 is used by PKI entities for the generation and management 80 of the certificates. One of the requirements of CMPv2 [RFC4210] is 81 to be independent of the transport protocol in use. CMP has 82 mechanisms to take care of required transactions, error reporting and 83 encryption of messages. The CoAP defined in [RFC7252], [RFC7959] and 84 [RFC8323] is a client-server protocol, like HTTP, that is designed to 85 be used by constrained devices over constrained networks. The 86 recommended transport for CoAP is UDP, however [RFC8323] specifies 87 the support of CoAP over TCP, TLS and Websockets. This document 88 specifies the use of CoAP as a transport medium for the CMPv2 and 89 Lightweight CMP Profile [Lightweight-CMP-Profile]. This document, in 90 general, follows the HTTP transport specifications for CMPv2 defined 91 in [RFC6712] and specifies the additional requirements for CoAP 92 transport. This document also provides guidance on how to use a 93 "CoAP to HTTP" proxy for a better adaptation of CoAP transport 94 without significant changes to the existing PKI entities. Although 95 CoAP transport can be used for communication between Registration 96 Authority (RA) and Certification Authority (CA) or between CAs, the 97 scope of this document is for communication between End Entity (EE) 98 and RA or EE and CA. This document is applicable only when the CoAP 99 transport is being used for the CMPv2 transactions. 101 1.1. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 2. CoAP Transport For CMPv2 111 CMPv2 transaction consists of passing PKIMesssage [RFC4210] between 112 the PKI End Entities (EEs), Registration Authorities (RAs), and 113 Certification Authorities (CAs). If the EEs are constrained devices 114 then they will prefer, as a client, the use of CoAP instead of HTTP 115 as a transport medium, while the RAs and CAs, in general, are not 116 constrained and can support both CoAP and HTTP Client and Server 117 implementation. This section specifes how to use CoAP as transport 118 mechanism for CMPv2 or Lightweight CMP Profile 119 [Lightweight-CMP-Profile]. 121 2.1. Discovery of CMP Entities 123 The information about the URIs of CA and RA that is required by EEs 124 can be either configured out of band on EEs or the EEs can use the 125 service discovery mechanism described in section 7 of [RFC7252] to 126 find them. The EE, RA SHOULD support service discovery as described 127 in section 7 of [RFC7252]. An EE MUST verify the configured Root CA 128 certificate against the Root CA certificate of the discovered entity 129 to make sure it is talking to correct endpoint. 131 2.2. CoAP URI Format 133 The CoAP URI MUST follow the guidelines defined in section 3.6 of 134 [RFC6712] for CMPv2 protocol. Implementations supporting the 135 Lightweight CMP Profile [Lightweight-CMP-Profile] MUST follow the 136 guidelines specified for HTTP transport defined in section 7.1 of 137 Lightweight CMP Profile [Lightweight-CMP-Profile]. The URI's for 138 CoAP resources should start with coap:// instead of http:// and 139 coaps:// instead of https:// 141 2.3. CoAP Request Format 143 The CMPv2 PKIMessage MUST be DER encoded and sent as the body of the 144 CoAP POST request. If the CoAP request is successful then the server 145 should return a "2.05 Content" response code. If the CoAP request is 146 not successful then an appropriate CoAP Client Error 4.xx or a Server 147 Error 5.xx response code MUST be returned. 149 2.4. CoAP Content-Format 151 When transferring CMPv2 PKIMesssage over CoAP the media type 152 application/pkixcmp MUST be used. 154 2.5. Announcement PKIMessage 156 When using the CoAP protocol, a PKI EE SHOULD poll for the possible 157 changes via PKI Information request using General Message defined in 158 the PKIMessage for various type of changes like CA key update or to 159 get current CRL to check revocation or using Support messages defined 160 in section 5.4 of Lightweight CMP Profile [Lightweight-CMP-Profile]. 161 This will help constrained devices acting as EEs save resources as 162 there is no need to open a listening socket for notifications and it 163 will also make the use of a CoAP to HTTP proxy transparent to the EE. 165 2.6. CoAP Block Wise Transfer Mode 167 Since the CMPv2 PKIMesssage consists of a header body and optional 168 fields a CMPv2 message can be much larger than the MTU of the 169 outgoing interface of the device. In order to avoid IP fragmentation 170 of messages that are exchanged between EEs and RAs or CAs, the Block 171 Wise transfer [RFC7959] mode MUST be used for the CMPv2 Transactions 172 over CoAP. If a CoAP to HTTP proxy is in the path between EEs and CA 173 or EEs and RA then, it MUST receive the entire body from the client 174 before sending the HTTP request to the server. This will avoid 175 unnecessary errors in case the entire content of the PKIMesssage is 176 not received and Proxy opens a connection with the server. 178 2.7. Multicast CoAP 180 CMPv2 PKIMessage request messages sent from EEs to RAs or from EEs to 181 CAs over CoAP transport MUST not use a Multicast destination address. 183 3. Using CoAP over DTLS 185 Although CPMv2 protocol does not depend upon the underlying transport 186 for the encryption and authentication of the messages but in cases 187 when end to end secrecy is desired for the CoAP transport, CoAP over 188 DTLS [RFC6347] as a transport medium SHOULD be used. Section 9.1 of 190 [RFC7252] defines how to use DTLS [RFC6347] for securing the CoAP. 191 For CMPv2 and Lightweight CMP Profile [Lightweight-CMP-Profile] the 192 clients should follow specifications defined in section 7.1 and 193 section 7.2 of Lightweight CMP Profile [Lightweight-CMP-Profile] for 194 setting up DTLS [RFC6347] connection either using certificates or 195 shared secret. Once a DTLS [RFC6347] connection is established it 196 SHOULD be used for as long as possible to avoid the frequent overhead 197 of using DTLS [RFC6347] connection for constrained devices. 199 4. Proxy support 201 The use of a CoAP to HTTP proxy is recommended to avoid significant 202 changes in the implementation of the CAs and RAs. However, if a 203 proxy is in place then Announcements Messages cannot be passed to EEs 204 efficiently. In case a CoAP to HTTP proxy is used for CMP 205 transactions, it SHOULD support service discovery mentioned in 206 section 2.1 208 4.1. CoAP to HTTP Proxy 210 If a CoAP to HTTP proxy is used then it MUST be positioned between 211 EEs and RAs or between EEs and CAs when RA is not part of CMP 212 transactions. The use of a CoAP to HTTP proxy between CAs and RAs is 213 not recommended. The implementation of a CoAP to HTTP proxy is 214 specified in Section 10 of [RFC7252]. The CoAP to HTTP proxy will 215 also protect the CAs and RAs from UDP based Denial of Service 216 attacks. 218 4.2. CoAPs to HTTPs Proxy 220 A CoAPs to HTTPS proxy (DTLS [RFC6347] transport to TLS [RFC8446] 221 transport proxy) can be used instead of the CoAP to HTTP proxy if the 222 server support HTTPS protocol, however client SHOULD be configured to 223 trust the CA certificate used by proxy to sign the Man in the Middle 224 (MITM) certificate for certificate chain validation [RFC5280]. 226 5. Security Considerations 228 The CMPv2 protocol itself does not require secure transport and 229 depends upon various mechanisms in the protocol itself to make sure 230 that the transactions are secure. However, the CoAP protocol which 231 uses UDP as layer 4 transport is vulnerable to many issues due to the 232 connectionless characteristics of UDP itself. The Security 233 considerations for CoAP protocol are mentioned in the [RFC7252]. 234 Using a CoAP to HTTP proxy mitigates some of the risks as the 235 requests from the EE's can terminate inside the trusted network and 236 will not require the server to listen on a UDP port making it safe 237 from UDP based address spoofing, Denial of Service, and amplification 238 attacks due to the characteristics of UDP. 240 6. IANA Considerations 242 This document requires a new entry to the CoAP Content-Formats 243 Registry code for the content-type application/pkixcmp 245 7. Acknowledgments 247 The author would like to thank Hendrik Brockhaus, David von Oheimb, 248 and Andreas Kretschmer for their guidance in writing the content of 249 this document and providing valuable feedback. 251 8. References 253 8.1. Normative References 255 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 256 Requirement Levels", BCP 14, RFC 2119, 257 DOI 10.17487/RFC2119, March 1997, 258 . 260 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 261 "Internet X.509 Public Key Infrastructure Certificate 262 Management Protocol (CMP)", RFC 4210, 263 DOI 10.17487/RFC4210, September 2005, 264 . 266 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 267 Housley, R., and W. Polk, "Internet X.509 Public Key 268 Infrastructure Certificate and Certificate Revocation List 269 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 270 . 272 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 273 Infrastructure -- HTTP Transfer for the Certificate 274 Management Protocol (CMP)", RFC 6712, 275 DOI 10.17487/RFC6712, September 2012, 276 . 278 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 279 Application Protocol (CoAP)", RFC 7252, 280 DOI 10.17487/RFC7252, June 2014, 281 . 283 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 284 the Constrained Application Protocol (CoAP)", RFC 7959, 285 DOI 10.17487/RFC7959, August 2016, 286 . 288 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 289 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 290 May 2017, . 292 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 293 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 294 Application Protocol) over TCP, TLS, and WebSockets", 295 RFC 8323, DOI 10.17487/RFC8323, February 2018, 296 . 298 8.2. Informative References 300 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 301 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 302 January 2012, . 304 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 305 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 306 . 308 8.3. URL References 310 [Lightweight-CMP-Profile] 311 Brockhaus, H., Fries, S., and D. von Oheimb, "Lightweight 312 CMP Profile", 2020, . 315 Authors' Addresses 317 Mohit Sahni (editor) 318 Palo Alto Networks 319 3000 Tannery Way 320 Santa Clara, CA 95054 321 US 323 EMail: msahni@paloaltonetworks.com 324 Saurabh Tripathi (editor) 325 Palo Alto Networks 326 3000 Tannery Way 327 Santa Clara, CA 95054 328 US 330 EMail: stripathi@paloaltonetworks.com