idnits 2.17.00 (12 Aug 2021) /tmp/idnits6628/draft-msahni-tbd-cmpv2-coap-transport-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 : ---------------------------------------------------------------------------- ** 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. == 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 'SHOULD not' in this paragraph: A CoAPS to HTTPS proxy (DTLS [RFC6347] transport to TLS [RFC8446] transport proxy) SHOULD not be used as it can be insecure for the client to trust the Man in the Middle (MiTM) certificate issued by the proxy to share client and server shared secret with the proxy. If a server requires Mutual TLS [MTLS] then a proxy will not work. -- The document date (June 4, 2020) is 716 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 278, but not defined == Missing Reference: 'MTLS' is mentioned on line 283, but not defined -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TBD M. Sahni, Ed. 3 Internet-Draft Palo Alto Networks 4 Intended status: Standards Track June 4, 2020 5 Expires: December 6, 2020 7 CoAP Transport for CMPV2 8 draft-msahni-tbd-cmpv2-coap-transport-00 10 Abstract 12 This document specifies how to use 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] which is a subset of CMPv2 defined for 16 Constrained devices. The CMPv2 defines the interaction between 17 various PKI entities for the purpose of certificate creation and 18 management. The CoAP is an HTTP like client-server protocol used by 19 various constrained devices in the IoT and industrial scenarios. 20 Constrained devices are devices that have low memory or CPU or power 21 constraints and avoid the use of complex protocols like TCP to save 22 resources. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 6, 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. CoAP Transport For CMPv2 . . . . . . . . . . . . . . . . . . 3 61 2.1. CoAP URI Format . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. CoAP Request Format . . . . . . . . . . . . . . . . . . . 3 63 2.3. CoAP Content-Format . . . . . . . . . . . . . . . . . . . 3 64 2.4. Announcement PKIMessage . . . . . . . . . . . . . . . . . 4 65 2.5. CoAP Block Wise Transfer Mode . . . . . . . . . . . . . . 4 66 2.6. Multicast CoAP . . . . . . . . . . . . . . . . . . . . . 4 67 3. Using CoAP over DTLS . . . . . . . . . . . . . . . . . . . . 4 68 4. Proxy support . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4.1. CoAP to HTTP Proxy . . . . . . . . . . . . . . . . . . . 5 70 4.2. CoAPs to HTTPs Proxy . . . . . . . . . . . . . . . . . . 5 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 73 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 8.2. Informative References . . . . . . . . . . . . . . . . . 6 77 8.3. URL References . . . . . . . . . . . . . . . . . . . . . 6 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 The CMPv2 is used by the entities in PKI for the generation and 83 management of the certificate. One of the requirements of CMPv2 84 [RFC4210] is to be usable over a variety of protocols. The CoAP 85 [RFC7252] and [RFC7959] is a client-server protocol like HTTP that is 86 designed to be used by constrained devices over constrained networks 87 (low power lossy networks). This document specifies the use of CoAP 88 as a transport medium for the CMPv2 and Lightweight CMP Profile 89 [Lightweight-CMP-Profile]. This document, in general, follows the 90 HTTP transport specifications for CMPv2 defined in [RFC6712] and 91 specifies the additional requirements for CoAP transport. This 92 document also provides guidance on how to use a "CoAP to HTTP" proxy 93 for a better adaptation of CoAP transport without significant changes 94 to the existing PKI entities. Although CoAP transport can be used 95 for communication between RAs and CAs or between CAs, the scope of 96 this document is for communication between EEs and RAs or EEs and 97 CAs.This document is applicable only when the CoAP transport is being 98 used for the CMPv2 transactions. 100 1.1. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 105 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 2. CoAP Transport For CMPv2 110 CMPv2 transaction consists of passing PKIMesssage [RFC4210] between 111 the PKI End Entities (EEs), Registration Authorities (RAs), and 112 Certification Authorities (CAs). if the EEs are constrained devices 113 then they will prefer, as a client, the use of CoAP over the HTTP as 114 a transport medium, while the RAs and CAs, in general, are not 115 constrained and can support both CoAP and HTTP Client and Server 116 implementation. This section describes how to use CoAP as transport 117 for CMPv2 or Lightweight CMP Profile [Lightweight-CMP-Profile]. 119 2.1. CoAP URI Format 121 The CoAP URI MUST follow the guidelines defined in section 3.6 of 122 [RFC6712] for CMPv2 protocol. Implementations supporting the 123 Lightweight CMP Profile [Lightweight-CMP-Profile] MUST follow the 124 guidelines specified for HTTP transport defined in section 7.1 of 125 Lightweight CMP Profile [Lightweight-CMP-Profile]. The URI's for 126 CoAP resources should start of coap:// instead of http:// and 127 coaps:// instead of https:// 129 2.2. CoAP Request Format 131 The CMPv2 PKIMessage MUST be DER encoded and sent as the body of the 132 CoAP POST request. If the CoAP request is successful then the server 133 should return a "2.05 Content" response code. If the CoAP request is 134 not successful then an appropriate CoAP Client Error 4.xx or a Server 135 Error 5.xx response code MUST be returned. 137 2.3. CoAP Content-Format 139 When transferring CMPv2 PKIMesssage over CoAP the media type 140 application/pkixcmp MUST be used. 142 2.4. Announcement PKIMessage 144 When using the CoAP protocol, a PKI entity SHOULD poll for the 145 possible changes via PKI Information request using General Message 146 defined in a PKIMessage for various type of changes like CA key 147 update or to get current CRL to check revocation or using Support 148 messages defined in section 5.4 of Lightweight CMP Profile 149 [Lightweight-CMP-Profile]. This will make use of a CoAP to HTTP 150 proxy transparent to the client. 152 2.5. CoAP Block Wise Transfer Mode 154 Since the CMPv2 PKIMesssage consists of a header body and optional 155 fields, when using CoAP as transport for the CMPv2 protocol the Block 156 Wise transfer [RFC7959] mode MUST be used for the CMPv2 Transaction. 157 If a CoAP to HTTP proxy is in the path between EEs and CA or EEs and 158 RA then, it MUST receive the entire body from the client before 159 sending the HTTP request to the server. This will avoid unnecessary 160 errors in case the entire content of the PKIMesssage is not received 161 and Proxy opens a connection with the server. 163 2.6. Multicast CoAP 165 CMPv2 PKIMessage request messages sent from EEs to RAs or from EEs to 166 CAs over CoAP transport MUST not use a Multicast destination address. 168 3. Using CoAP over DTLS 170 When the end to end secrecy is desired for CoAP transport, CoAP over 171 DTLS [RFC6347] as a transport medium should be used. Section 9.1 of 172 [RFC7252] defines how to use DTLS [RFC6347] for securing the CoAP. 173 For CMPv2 and Lightweight CMP Profile [Lightweight-CMP-Profile] the 174 clients should follow specifications defined in section 7.1 and 175 section 7.2 of Lightweight CMP Profile [Lightweight-CMP-Profile] for 176 setting up DTLS [RFC6347] connection either using certificates or 177 shared secret for setting up DLTS connection. Once a DTLS [RFC6347] 178 connection is established it SHOULD be used for as long as possible 179 to avoid the frequent overhead of using DTLS [RFC6347] connection for 180 constrained devices 182 4. Proxy support 184 The use of a CoAP to HTTP proxy is recommended to avoid significant 185 changes in the implementation of the CAs and RAs. However, if a 186 proxy is in place then Announcements Messages cannot be passed to EEs 187 efficiently. 189 4.1. CoAP to HTTP Proxy 191 If a CoAP to HTTP proxy is used then it MUST be positioned between 192 EEs and RAs or between EEs and CAs when RA is not part of CMPv2 193 transactions. The use of a CoAP to HTTP proxy between CAs and RAs is 194 not recommended. The implementation of a CoAP to HTTP proxy is 195 specified in Section 10 of [RFC7252]. The CoAP to HTTP proxy will 196 also protect the CAs and RAs from UDP based Denial of Service 197 attacks. 199 4.2. CoAPs to HTTPs Proxy 201 A CoAPS to HTTPS proxy (DTLS [RFC6347] transport to TLS [RFC8446] 202 transport proxy) SHOULD not be used as it can be insecure for the 203 client to trust the Man in the Middle (MiTM) certificate issued by 204 the proxy to share client and server shared secret with the proxy. 205 If a server requires Mutual TLS [MTLS] then a proxy will not work. 207 5. Security Considerations 209 The CMPv2 protocol itself does not require secure transport and 210 depends upon various mechanisms in the protocol itself to make sure 211 that the transactions are secure. However, the CoAP protocol which 212 uses UDP as layer 4 transport is vulnerable to many issues due to the 213 connectionless characteristics of UDP itself. The Security 214 considerations for CoAP protocol are mentioned in the [RFC7252]. 215 Using a CoAP to HTTP proxy mitigates some of the risks as the 216 requests from the EE's can terminate inside the trusted network and 217 will not require the server to listen on a UDP port making it safe 218 from UDP based address spoofing, Denial of Service, and amplification 219 attacks due to the characteristics of TCP. 221 6. IANA Considerations 223 This document requires a new entry to the CoAP Content-Formats 224 Registry code for the content-type application/pkixcmp 226 7. Acknowledgments 228 The author would like to thank Hendrik Brockhaus, David von Oheimb, 229 and Andreas Kretschmer for their guidance in writing the content of 230 this document and providing valuable feedback. 232 8. References 233 8.1. Normative References 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, 237 DOI 10.17487/RFC2119, March 1997, 238 . 240 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 241 "Internet X.509 Public Key Infrastructure Certificate 242 Management Protocol (CMP)", RFC 4210, 243 DOI 10.17487/RFC4210, September 2005, 244 . 246 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 247 Infrastructure -- HTTP Transfer for the Certificate 248 Management Protocol (CMP)", RFC 6712, 249 DOI 10.17487/RFC6712, September 2012, 250 . 252 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 253 Application Protocol (CoAP)", RFC 7252, 254 DOI 10.17487/RFC7252, June 2014, 255 . 257 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 258 the Constrained Application Protocol (CoAP)", RFC 7959, 259 DOI 10.17487/RFC7959, August 2016, 260 . 262 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 263 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 264 May 2017, . 266 8.2. Informative References 268 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 269 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 270 January 2012, . 272 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 273 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 274 . 276 8.3. URL References 278 [Lightweight-CMP-Profile] 279 Brockhaus, H., Fries, S., and D. von Oheimb, "Lightweight 280 CMP Profile", 2020, . 283 [MTLS] Rescorla, E., "Mutual TLS", August 2018, 284 . 286 Author's Address 288 Mohit Sahni (editor) 289 Palo Alto Networks 290 3000 Tannery Way 291 Santa Clara, CA 95054 292 US 294 EMail: msahni@paloaltonetworks.com