idnits 2.17.1 draft-tschofenig-tls-cwt-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 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 (November 04, 2019) is 1634 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 306 -- Looks like a reference, but probably isn't: '2' on line 308 -- Looks like a reference, but probably isn't: '3' on line 311 == Unused Reference: 'RFC7250' is defined on line 243, but no explicit reference was found in the text == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-33 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 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: May 7, 2020 November 04, 2019 7 Using CBOR Web Tokens (CWTs) in Transport Layer Security (TLS) and 8 Datagram Transport Layer Security (DTLS) 9 draft-tschofenig-tls-cwt-01 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 sub-registry 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 May 7, 2020. 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 extensively 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. This document mandates 102 a minimum number of claims to be present in a CWT. There may, 103 however, be a number of additional claims present in a CWT. An 104 example of a token with a larger number of claims is the Entity 105 Attestation Token (EAT), which may also be encoded as a CWT. 107 Fundamentally, there are two types of keys that can be used with 108 CWTs: 110 - Asymmetric keys: In this case a CWT contains a COSE_Key [RFC8152] 111 representing an asymmetric public key. To protect the CWT against 112 modifications the CWT also needs to be digitally signed. 114 - Symmetric keys: In this case a CWT contains the Encrypted_COSE_Key 115 [RFC8152] structure representing a symmetric key encrypted to a 116 key known to the recipient using COSE_Encrypt or COSE_Encrypt0. 117 Again, to protect the CWT against modifications a keyed message 118 digest is used. 120 The CWT also allows mixing symmetric and asymmetric crypto although 121 this is less likely to be used in practice. 123 Exchanging CWTs in the TLS / DTLS handshake offers an alternative to 124 the use of raw public keys and X.509 certificates. Compared to raw 125 public keys, CWTs allow more information to be included via the use 126 of claims. Compared to X.509 certificates CBOR offers an alternative 127 encoding format, which may also be used by the application layer 128 thereby potentially reducing the overall code size requirements. 130 2. Conventions and Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in RFC 135 2119 [RFC2119]. 137 3. The CWT Certificate Type 139 This document defines a new value to the "TLS Certificate Types" sub- 140 registry and the value is defined as follows. 142 /* Managed by IANA */ 143 enum { 144 X509(0), 145 RawPublicKey(2), 146 CWT(TBD), 147 (255) 148 } CertificateType; 150 struct { 151 select (certificate_type) { 153 /* CWT "certificate type" defined in this document.*/ 154 case CWT: 155 opaque cwt_data<1..2^24-1>; 157 /* RawPublicKey defined in RFC 7250*/ 158 case RawPublicKey: 159 opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>; 161 /* X.509 certificate defined in RFC 5246*/ 162 case X.509: 163 opaque cert_data<1..2^24-1>; 165 }; 167 Extension extensions<0..2^16-1>; 168 } CertificateEntry; 170 4. Representation and Verification the Identity of Application Services 172 RFC 6125 [RFC6125] provides guidance for matching identifiers used in 173 X.509 certificates against a reference identifier, i.e. an identifier 174 constructed from a source domain and optionally an application 175 service type. Different types of identifiers have been defined over 176 time, such as CN-IDs, DNS-IDs, SRV-IDs, and URI-IDs, and they may be 177 carried in different fields inside the X.509 certificate, such as in 178 the Common Name or in the subjectAltName extension. 180 For CWTs issued to servers the following rule applies: To claim 181 conformance with this specification an implementation MUST populate 182 the Subject claim with the value of the Server Name Indication (SNI) 183 extension. The Subject claim is of type StringOrURI. If it is 184 string an equality match is used between the Subject claim value and 185 the SNI. If the value contains a URI then the URI schema must be 186 matched against the service being requested and the remaining part of 187 the URI is matched against the SNI in an equality match (since the 188 SNI only defines Hostname types). 190 For CWTs issued to clients the application service interacting with 191 the TLS/DTLS stack on the server side is responsible for 192 authenticating the client. No specific rules apply but the Subject 193 and the Audience claims are likely to be good candidates for 194 authorization policy checks. 196 Note: Verification of the Not Before and the Expiration Time claims 197 MUST be performed to determine the validity of the received CWT. 199 5. Security and Privacy Considerations 201 The security and privacy characteristics of this extension are best 202 described in relationship to certificates (when asymmetric keys are 203 used) and to Kerberos tickets (when symmetric keys are used) since 204 the main difference is in the encoding. 206 When creating proof-of-possession keys the recommendations for state- 207 of-the-art key sizes and algorithms have to be followed. For TLS/ 208 DTLS those algorithm recommendations can be found in [RFC7925] and 209 [RFC7525]. 211 CWTs without proof-of-possession keys MUST NOT be used. 213 When CWTs are used with TLS 1.3 [RFC8446] and DTLS 1.3 214 [I-D.ietf-tls-dtls13] additional privacy properties are provided 215 since most handshake messages are encrypted. 217 6. IANA Considerations 219 IANA is requested to add a new value to the "TLS Certificate Types" 220 sub-registry for CWTs. 222 7. References 224 7.1. Normative References 226 [I-D.ietf-ace-cwt-proof-of-possession] 227 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 228 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 229 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 230 possession-11 (work in progress), October 2019. 232 [I-D.ietf-tls-dtls13] 233 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 234 Datagram Transport Layer Security (DTLS) Protocol Version 235 1.3", draft-ietf-tls-dtls13-33 (work in progress), October 236 2019. 238 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 239 Requirement Levels", BCP 14, RFC 2119, 240 DOI 10.17487/RFC2119, March 1997, 241 . 243 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 244 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 245 Transport Layer Security (TLS) and Datagram Transport 246 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 247 June 2014, . 249 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 250 RFC 8152, DOI 10.17487/RFC8152, July 2017, 251 . 253 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 254 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 255 May 2018, . 257 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 258 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 259 . 261 7.2. Informative References 263 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 264 Verification of Domain-Based Application Service Identity 265 within Internet Public Key Infrastructure Using X.509 266 (PKIX) Certificates in the Context of Transport Layer 267 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 268 2011, . 270 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 271 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 272 . 274 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 275 "Recommendations for Secure Use of Transport Layer 276 Security (TLS) and Datagram Transport Layer Security 277 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 278 2015, . 280 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 281 Security (TLS) / Datagram Transport Layer Security (DTLS) 282 Profiles for the Internet of Things", RFC 7925, 283 DOI 10.17487/RFC7925, July 2016, 284 . 286 7.3. URIs 288 [1] mailto:tls@ietf.org 290 [2] https://www1.ietf.org/mailman/listinfo/tls 292 [3] https://www.ietf.org/mail-archive/web/tls/current/index.html 294 Appendix A. History 296 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 298 - -01: Minor editorial bugfixes and reference updates; refreshing 299 draft 301 - -00: Initial version 303 Appendix B. Working Group Information 305 The discussion list for the IETF TLS working group is located at the 306 e-mail address tls@ietf.org [1]. Information on the group and 307 information on how to subscribe to the list is at 308 https://www1.ietf.org/mailman/listinfo/tls [2] 310 Archives of the list can be found at: https://www.ietf.org/mail- 311 archive/web/tls/current/index.html [3] 313 Authors' Addresses 315 Hannes Tschofenig 316 Arm Limited 318 EMail: hannes.tschofenig@arm.com 320 Mathias Brossard 321 Arm Limited 323 EMail: Mathias.Brossard@arm.com