idnits 2.17.1 draft-ietf-ace-extend-dtls-authorize-02.txt: -(4): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-ace-dtls-authorize]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates draft-ietf-ace-dtls-authorize, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 781 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: 'RFC-XXXX' is mentioned on line 160, but not defined ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group O. Bergmann 3 Internet-Draft TZI 4 Updates: draft-ietf-ace-dtls-authorize (if J. Preuß Mattsson 5 approved) G. Selander 6 Intended status: Standards Track Ericsson 7 Expires: 8 September 2022 7 March 2022 9 Extension of the CoAP-DTLS Profile for ACE to TLS 10 draft-ietf-ace-extend-dtls-authorize-02 12 Abstract 14 This document updates the CoAP-DTLS profile for ACE 15 [I-D.ietf-ace-dtls-authorize] by specifying that the profile applies 16 to TLS as well as DTLS. 18 Discussion Venues 20 This note is to be removed before publishing as an RFC. 22 Discussion of this document takes place on the Authentication and 23 Authorization for Constrained Environments Working Group mailing list 24 (ace@ietf.org), which is archived at 25 https://mailarchive.ietf.org/arch/browse/ace/. 27 Source for this draft and an issue tracker can be found at 28 https://github.com/ace-wg/ace-extend-dtls-authorize. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 8 September 2022. 47 Copyright Notice 49 Copyright (c) 2022 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Connection Establishment . . . . . . . . . . . . . . . . . . 3 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 70 6.2. Informative References . . . . . . . . . . . . . . . . . 5 71 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 [I-D.ietf-ace-dtls-authorize] only specifies the use of DTLS 77 [RFC6347] but works equally well for TLS [RFC8446]. For many 78 constrained implementations, CoAP over UDP [RFC7252] is the first 79 choice, but when deploying ACE in networks controlled by other 80 entities (such as the Internet), UDP might be blocked on the path 81 between the client and the RS, and the client might have to fall back 82 to CoAP over TCP [RFC8323] for NAT or firewall traversal. This 83 feature is supported by the OSCORE profile 84 [I-D.ietf-ace-oscore-profile] but is lacking in the DTLS profile. 86 This document updates [I-D.ietf-ace-dtls-authorize] by specifying 87 that the profile applies to TLS as well as DTLS. The same access 88 rights are valid in case transport layer security is provided by 89 either DTLS or TLS, and the same access token can be used. 90 Therefore, the value coap_dtls in the ace_profile parameter of an AS- 91 to-Client response or in the ace_profile claim of an access token 92 indicates that either DTLS or TLS can be used for transport layer 93 security. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in 100 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 Readers are expected to be familiar with the terms and concepts 104 described in [I-D.ietf-ace-oauth-authz] and 105 [I-D.ietf-ace-dtls-authorize]. 107 3. Connection Establishment 109 Following the procedures defined in [I-D.ietf-ace-dtls-authorize], a 110 Client can retrieve an Access Token from an Authorization Server (AS) 111 in order to establish a security association with a specific Resource 112 Server. The ace_profile parameter in the Client-to-AS request and 113 AS-to-client response is used to determine the ACE profile that the 114 Client uses towards the Resource Server (RS). 116 In case the ace_profile parameter indicates the use of the DTLS 117 profile for ACE as defined in [I-D.ietf-ace-dtls-authorize], the 118 Client MAY try to connect to the Resource Server via TLS, or try TLS 119 and DTLS in parallel to accelerate the session setup. 121 As resource-constrained devices are not expected to support both 122 transport layer security mechanisms, a Client that implements either 123 TLS or DTLS but not both might fail in establishing a secure 124 communication channel with the Resource Server altogether. This 125 error SHOULD be handled by the Client in the same way as unsupported 126 ACE profiles. If the Client is modified accordingly or it learns 127 that the Resource Server has been, the Client may try to connect to 128 the Resource Server using the transport layer security mechanism that 129 was previously not mutually supported. 131 Note that a communication setup with an a priori unknown Resource 132 Server typically employs an initial unauthorized resource request as 133 illustrated in Section 2 of [I-D.ietf-ace-dtls-authorize]. If this 134 message exchange succeeds, the Client SHOULD first use the same 135 underlying transport protocol for the establishment of the security 136 association as well (i.e., DTLS for UDP, and TLS for TCP). 138 As a consequence, the selection of the transport protocol used for 139 the initial unauthorized resource request also depends on the 140 transport layer security mechanism supported by the Client. Clients 141 that support either DTLS or TLS but not both SHOULD use the transport 142 protocol underlying the supported transport layer security mechanism 143 also for an initial unauthorized resource request. 145 4. IANA Considerations 147 The following updates have been done for the "ACE Profiles" registry 148 for the profile with Profile ID 1 and Profile name coap_dtls: 150 Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" 151 with the RFC number of this specification and delete this paragraph. 153 Description: Profile for delegating client Authentication and 154 Authorization for Constrained Environments by establishing a Datagram 155 Transport Layer Security (DTLS) or Transport Layer Security (TLS) 156 channel between resource-constrained nodes. 158 Change Controller: IESG 160 Reference: [RFC-XXXX] 162 5. Security Considerations 164 The security consideration and requirements in TLS 1.3 [RFC8446] and 165 BCP 195 [RFC7525] [RFC8996] also apply to this document. 167 6. References 169 6.1. Normative References 171 [I-D.ietf-ace-dtls-authorize] 172 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 173 L. Seitz, "Datagram Transport Layer Security (DTLS) 174 Profile for Authentication and Authorization for 175 Constrained Environments (ACE)", Work in Progress, 176 Internet-Draft, draft-ietf-ace-dtls-authorize-18, 4 June 177 2021, . 180 [I-D.ietf-ace-oauth-authz] 181 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 182 H. Tschofenig, "Authentication and Authorization for 183 Constrained Environments (ACE) using the OAuth 2.0 184 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 185 draft-ietf-ace-oauth-authz-46, 8 November 2021, 186 . 189 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 190 Requirement Levels", BCP 14, RFC 2119, 191 DOI 10.17487/RFC2119, March 1997, 192 . 194 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 195 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 196 January 2012, . 198 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 199 Application Protocol (CoAP)", RFC 7252, 200 DOI 10.17487/RFC7252, June 2014, 201 . 203 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 204 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 205 May 2017, . 207 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 208 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 209 Application Protocol) over TCP, TLS, and WebSockets", 210 RFC 8323, DOI 10.17487/RFC8323, February 2018, 211 . 213 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 214 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 215 . 217 6.2. Informative References 219 [I-D.ietf-ace-oscore-profile] 220 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 221 "OSCORE Profile of the Authentication and Authorization 222 for Constrained Environments Framework", Work in Progress, 223 Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May 224 2021, . 227 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 228 "Recommendations for Secure Use of Transport Layer 229 Security (TLS) and Datagram Transport Layer Security 230 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 231 2015, . 233 [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 234 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, 235 . 237 Acknowledgments 239 The authors would like to thank Marco Tiloca for reviewing this 240 specification. 242 Authors' Addresses 244 Olaf Bergmann 245 Universität Bremen TZI 246 Bremen, D-28359 247 Germany 248 Email: bergmann@tzi.org 250 John Preuß Mattsson 251 Ericsson AB 252 SE-164 80 Stockholm 253 Sweden 254 Email: john.mattsson@ericsson.com 256 Göran Selander 257 Ericsson AB 258 SE-164 80 Stockholm 259 Sweden 260 Email: goran.selander@ericsson.com