idnits 2.17.00 (12 Aug 2021) /tmp/idnits6023/draft-tschofenig-tls-cwt-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 document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 11, 2019) is 1167 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '1' on line 299 -- Looks like a reference, but probably isn't: '2' on line 301 -- Looks like a reference, but probably isn't: '3' on line 304 == Unused Reference: 'RFC7250' is defined on line 239, but no explicit reference was found in the text == Outdated reference: draft-ietf-ace-cwt-proof-of-possession has been published as RFC 8747 == Outdated reference: draft-ietf-tls-dtls13 has been published as RFC 9147 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS H. Tschofenig 3 Internet-Draft M. Brossard 4 Intended status: Standards Track Arm Limited 5 Expires: September 12, 2019 March 11, 2019 7 Using CBOR Web Tokens (CWTs) in Transport Layer Security (TLS) and 8 Datagram Transport Layer Security (DTLS) 9 draft-tschofenig-tls-cwt-00 11 Abstract 13 The TLS protocol supports different credentials, including pre-shared 14 keys, raw public keys, and X.509 certificates. For use with public 15 key cryptography developers have to decide between raw public keys, 16 which require out-of-band agreement and full-fletched X.509 17 certificates. For devices where the reduction of code size is 18 important it is desirable to minimize the use of X.509-related 19 libraries. With the CBOR Web Token (CWT) a structure has been 20 defined that allows CBOR-encoded claims to be protected with CBOR 21 Object Signing and Encryption (COSE). 23 This document registers a new value to the "TLS Certificate Types" 24 subregistry to allow TLS and DTLS to use CWTs. Conceptually, CWTs 25 can be seen as a certificate format (when with public key 26 cryptography) or a Kerberos ticket (when used with symmetric key 27 cryptography). 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 12, 2019. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 76 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 77 3. The CWT Certificate Type . . . . . . . . . . . . . . . . . . 3 78 4. Representation and Verification the Identity of Application 79 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 5. Security and Privacy Considerations . . . . . . . . . . . . . 5 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 84 7.2. Informative References . . . . . . . . . . . . . . . . . 6 85 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 8 86 Appendix B. Working Group Information . . . . . . . . . . . . . 8 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 89 1. Introduction 91 The CBOR Web Token (CWT) [RFC8392] was defined as the CBOR-based 92 version of the JSON Web Token (JWT) [RFC7519]. JWT is used 93 extensibly on Web application and for use with Internet of Things 94 environments the believe is that a more lightweight encoding, namely 95 CBOR, is needed. CWTs, like JWTs, contain claims and those claims 96 are protected against modifications using COSE [RFC8152]. CWTs are 97 flexible with regard to the use of cryptography and hence CWTs may be 98 protected using a keyed message digest, or a digital signature. One 99 of the claims allows keys to be included, as described in 100 [I-D.ietf-ace-cwt-proof-of-possession]. This specification makes use 101 of these proof-of-possession claims in CWTs. 103 Fundamentially, there are two types of keys that can be used with 104 CWTs: 106 - Asymmetric keys: In this case a CWT contains a COSE_Key [RFC8152] 107 representing an asymmetric public key. To protect the CWT against 108 modifications the CWT also needs to be digitally signed. 110 - Symmetric keys: In this case a CWT contains a Encrypted_COSE_Key 111 [RFC8152] representing a symmetric key encrypted to a key known to 112 the recipient using COSE_Encrypt or COSE_Encrypt0. Again, to 113 protect the CWT against modifications a keyed message digest is 114 used. 116 The CWT also allows mixing symmetric and asymmetric crypto although 117 this is less likely to be used in practice. 119 Exchanging CWTs in the TLS / DTLS handshake offers an alternative to 120 the use of raw public keys and X.509 certificates. Compared to raw 121 public keys, CWTs allow more information to be included via the use 122 of claims. Compared to X.509 certificates CBOR offers an alternative 123 encoding format, which may also be used by the application layer 124 thereby potentially reducing the overall code size requirements. 126 2. Conventions and Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in RFC 131 2119 [RFC2119]. 133 3. The CWT Certificate Type 135 This document defines a new value to the "TLS Certificate Types" 136 subregistry and the value is defined as follows. 138 /* Managed by IANA */ 139 enum { 140 X509(0), 141 RawPublicKey(2), 142 CWT(TBD), 143 (255) 144 } CertificateType; 146 struct { 147 select (certificate_type) { 149 /* CWT "certificate type" defined in this document.*/ 150 case CWT: 151 opaque cwt_data<1..2^24-1>; 153 /* RawPublicKey defined in RFC 7250*/ 154 case RawPublicKey: 155 opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>; 157 /* X.509 certificate defined in RFC 5246*/ 158 case X.509: 159 opaque cert_data<1..2^24-1>; 161 }; 163 Extension extensions<0..2^16-1>; 164 } CertificateEntry; 166 4. Representation and Verification the Identity of Application Services 168 RFC 6125 [RFC6125] provides guidance for matching identifiers used in 169 X.509 certificates against a reference identifier, i.e. an identifier 170 constructed from a source domain and optionally an application 171 service type. Different types of identifiers have been defined over 172 time, such as CN-IDs, DNS-IDs, SRV-IDs, and URI-IDs, and they may be 173 carried in different fields inside the X.509 certificate, such as in 174 the Common Name or in the subjectAltName extension. 176 For CWTs issued to servers the following rule applies: To claim 177 conformance with this specification an implementation MUST populate 178 the Subject claim with the value of the Server Name Indication (SNI) 179 extension. The Subject claim is of type StringOrURI. If it is 180 string an equality match is used between the Subject claim value and 181 the SNI. If the value contains a URI then the URI schema must be 182 matched against the service being requested and the remaining part of 183 the URI is matched against the SNI in an equality match (since the 184 SNI only defines Hostname types). 186 For CWTs issued to clients the application service interacting with 187 the TLS/DTLS stack on the server side is responsible for 188 authenticating the client. No specific rules apply but the Subject 189 and the Audience claims are likely to be good candidates for 190 authorization policy checks. 192 Note: Verification of the Not Before and the Expiration Time claims 193 MUST be performed to determine the validity of the received CWT. 195 5. Security and Privacy Considerations 197 The security and privacy characteristics of this extension are best 198 described in relationship to certificates (when asymmetric keys are 199 used) and to Kerberos tickets (when symmetric keys are used) since 200 the main difference is in the encoding. 202 When creating proof-of-possession keys the recommendations for state- 203 of-the-art key sizes and algorithms have to be followed. For TLS/ 204 DTLS those algorithm recommendations can be found in [RFC7925] and 205 [RFC7525]. 207 CWTs without proof-of-possession keys MUST NOT be used. 209 When CWTs are used with TLS 1.3 [RFC8446] and DTLS 1.3 210 [I-D.ietf-tls-dtls13] additional privacy properties are provided 211 since most handshake messages are encrypted. 213 6. IANA Considerations 215 IANA is requested to add a new value to the "TLS Certificate Types" 216 subregistry for CWTs. 218 7. References 220 7.1. Normative References 222 [I-D.ietf-ace-cwt-proof-of-possession] 223 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 224 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 225 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 226 possession-06 (work in progress), February 2019. 228 [I-D.ietf-tls-dtls13] 229 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 230 Datagram Transport Layer Security (DTLS) Protocol Version 231 1.3", draft-ietf-tls-dtls13-30 (work in progress), 232 November 2018. 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, 236 DOI 10.17487/RFC2119, March 1997, 237 . 239 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 240 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 241 Transport Layer Security (TLS) and Datagram Transport 242 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 243 June 2014, . 245 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 246 RFC 8152, DOI 10.17487/RFC8152, July 2017, 247 . 249 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 250 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 251 May 2018, . 253 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 254 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 255 . 257 7.2. Informative References 259 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 260 Verification of Domain-Based Application Service Identity 261 within Internet Public Key Infrastructure Using X.509 262 (PKIX) Certificates in the Context of Transport Layer 263 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 264 2011, . 266 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 267 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 268 . 270 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 271 "Recommendations for Secure Use of Transport Layer 272 Security (TLS) and Datagram Transport Layer Security 273 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 274 2015, . 276 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 277 Security (TLS) / Datagram Transport Layer Security (DTLS) 278 Profiles for the Internet of Things", RFC 7925, 279 DOI 10.17487/RFC7925, July 2016, 280 . 282 7.3. URIs 284 [1] mailto:tls@ietf.org 286 [2] https://www1.ietf.org/mailman/listinfo/tls 288 [3] https://www.ietf.org/mail-archive/web/tls/current/index.html 290 Appendix A. History 292 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 294 - Initial version 296 Appendix B. Working Group Information 298 The discussion list for the IETF TLS working group is located at the 299 e-mail address tls@ietf.org [1]. Information on the group and 300 information on how to subscribe to the list is at 301 https://www1.ietf.org/mailman/listinfo/tls [2] 303 Archives of the list can be found at: https://www.ietf.org/mail- 304 archive/web/tls/current/index.html [3] 306 Authors' Addresses 308 Hannes Tschofenig 309 Arm Limited 311 EMail: hannes.tschofenig@arm.com 313 Mathias Brossard 314 Arm Limited 316 EMail: Mathias.Brossard@arm.com