rfc9430.original   rfc9430.txt 
ACE Working Group O. Bergmann Internet Engineering Task Force (IETF) O. Bergmann
Internet-Draft TZI Request for Comments: 9430 TZI
Updates: 9202 (if approved) J. Preuß Mattsson Updates: 9202 J. Preuß Mattsson
Intended status: Standards Track G. Selander Category: Standards Track G. Selander
Expires: 10 September 2023 Ericsson ISSN: 2070-1721 Ericsson
9 March 2023 July 2023
Extension of the Datagram Transport Layer Security (DTLS) Profile for Extension of the Datagram Transport Layer Security (DTLS) Profile for
Authentication and Authorization for Constrained Environments (ACE) to Authentication and Authorization for Constrained Environments (ACE) to
Transport Layer Security (TLS) Transport Layer Security (TLS)
draft-ietf-ace-extend-dtls-authorize-07
Abstract Abstract
This document updates the Datagram Transport Layer Security (DTLS) This document updates "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for Constrained Profile for Authentication and Authorization for Constrained
Environments (ACE) specified in RFC 9202 by specifying that the Environments (ACE)" (RFC 9202) by specifying that the profile applies
profile applies to Transport Layer Security (TLS) as well as Datagram to TLS as well as DTLS.
TLS (DTLS).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 10 September 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9430.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Specific Changes to RFC 9202 . . . . . . . . . . . . . . . . 3 3. Specific Changes to RFC 9202
4. Connection Establishment . . . . . . . . . . . . . . . . . . 3 4. Connection Establishment
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. References
7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.1. Normative References
7.2. Informative References . . . . . . . . . . . . . . . . . 5 7.2. Informative References
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses
1. Introduction 1. Introduction
The Authentication and Authorization for Constrained Environments The Authentication and Authorization for Constrained Environments
(ACE) framework [RFC9200] defines an architecture for lightweight (ACE) framework [RFC9200] defines an architecture for lightweight
authentication between Client, Resource Server (RS), and authentication between the Client, Resource Server (RS), and
Authorization Server (AS) where the Client and RS may be constrained. Authorization Server (AS), where the Client and RS may be
The Datagram Transport Layer Security (DTLS) Profile for constrained. "Datagram Transport Layer Security (DTLS) Profile for
Authentication and Authorization for Constrained Environments (ACE) Authentication and Authorization for Constrained Environments (ACE)"
[RFC9202] only specifies the use of Datagram Transport Layer Security [RFC9202] only specifies the use of DTLS [RFC9147] for transport
(DTLS) [RFC9147] for transport-layer security between the nodes in layer security between the nodes in the ACE architecture but works
the ACE architecture but works equally well for Transport Layer equally well for Transport Layer Security (TLS) [RFC8446]. For many
Security (TLS) [RFC8446]. For many constrained implementations, constrained implementations, the Constrained Application Protocol
Constrained Application Protocol (CoAP) over UDP [RFC7252] is the (CoAP) over UDP [RFC7252] is the first choice, but when deploying ACE
first choice, but when deploying ACE in networks controlled by other in networks controlled by other entities (such as the Internet), UDP
entities (such as the Internet), UDP might be blocked on the path might be blocked on the path between the Client and the Resource
between the Client and the Resource Server, and the Client might have Server, and the Client might have to fall back to CoAP over TCP
to fall back to CoAP over TCP [RFC8323] for NAT or firewall [RFC8323] for NAT or firewall traversal. This dual support for
traversal. This dual support for security over TCP as well as UDP is security over TCP as well as UDP is already supported by the Object
already supported by the Object Security for Constrained RESTful Security for Constrained RESTful Environments (OSCORE) profile
Environments (OSCORE) profile [RFC9203]. [RFC9203].
This document updates [RFC9202] by specifying that the profile This document updates [RFC9202] by specifying that the profile
applies to TLS as well as DTLS. It only impacts the transport layer applies to TLS as well as DTLS. It only impacts the transport layer
security channel between Client and Resource Server. The same access security channel between the Client and Resource Server. The same
rights are valid in case transport layer security is provided by access rights are valid in case transport layer security is provided
either DTLS or TLS. The same access token can be used by either DTLS by either DTLS or TLS. The same access token can be used by either
or TLS between a given (Client, RS) pair. Therefore, the value DTLS or TLS between a given (Client, RS) pair. Therefore, the value
coap_dtls in the ace_profile parameter of an Authorization Server to coap_dtls in the ace_profile parameter of an Authorization Server to
Client (AS-to-Client) response or in the ace_profile claim of an Client (AS-to-Client) response or in the ace_profile claim of an
access token indicates that either DTLS or TLS can be used for access token indicates that either DTLS or TLS can be used for
transport layer security. transport layer security.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are expected to be familiar with the terms and concepts Readers are expected to be familiar with the terms and concepts
described in [RFC9200] and [RFC9202]. described in [RFC9200] and [RFC9202].
3. Specific Changes to RFC 9202 3. Specific Changes to RFC 9202
The main changes to [RFC9202] specified in this document are limited The main changes to [RFC9202] specified in this document are limited
to replacing "DTLS" with "DTLS/TLS" throughout the document. This to replacing "DTLS" with "DTLS/TLS" throughout the document. This
essentially impacts the use of secure transport as described in the essentially impacts the use of secure transport, as described in
sections 3.2.2, 3.3.2, 4, and 5. Sections 3.2.2, 3.3.2, 4, and 5.
In addition to this, the Client and Resource Server behavior is In addition to this, the Client and Resource Server behavior is
updated to describe the case where either or both DTLS and TLS may be updated to describe the case where either or both DTLS and TLS may be
available, as described in the following section. available, as described in the following section.
4. Connection Establishment 4. Connection Establishment
Following the procedures defined in [RFC9202], a Client can retrieve Following the procedures defined in [RFC9202], a Client can retrieve
an Access Token from an Authorization Server in order to establish a an access token from an Authorization Server in order to establish a
security association with a specific Resource Server. The security association with a specific Resource Server. The
ace_profile parameter in the Client-to-AS request and AS-to-client ace_profile parameter in the Client-to-AS request and AS-to-Client
response is used to determine the ACE profile that the Client uses response is used to determine the ACE profile that the Client uses
towards the Resource Server. towards the Resource Server.
The ace_profile parameter indicates the use of the DTLS profile for The ace_profile parameter indicates the use of the DTLS profile for
ACE as defined in [RFC9202]. Therefore, the Client typically first ACE, as defined in [RFC9202]. Therefore, the Client typically first
tries using DTLS to connect to the Resource Server. If this fails tries using DTLS to connect to the Resource Server. If this fails,
the Client MAY try to connect to the Resource Server via TLS. the Client MAY try to connect to the Resource Server via TLS.
As resource-constrained devices are not expected to support both As resource-constrained devices are not expected to support both
transport layer security mechanisms, Clients and Resource Servers transport layer security mechanisms, Clients and Resource Servers
SHOULD support DTLS and MAY support TLS. A Client that implements SHOULD support DTLS and MAY support TLS. A Client that implements
either TLS or DTLS but not both might fail in establishing a secure either TLS or DTLS but not both might fail in establishing a secure
communication channel with the Resource Server altogether. Non- communication channel with the Resource Server altogether.
constrained Clients and Resource Servers SHOULD support both TLS and Nonconstrained Clients and Resource Servers SHOULD support both TLS
DTLS. and DTLS.
Note that a communication setup with an a priori unknown Resource Note that a communication setup with an a priori unknown Resource
Server typically employs an initial unauthorized resource request as Server typically employs an initial unauthorized resource request, as
illustrated in Section 2 of [RFC9202]. If this message exchange illustrated in Section 2 of [RFC9202]. If this message exchange
succeeds, the Client SHOULD first use the same underlying transport succeeds, the Client SHOULD first use the same underlying transport
protocol also for the establishment of the security association to protocol for the establishment of the security association to the
the Resource Server (i.e., DTLS for UDP, and TLS for TCP). Resource Server (i.e., DTLS for UDP, and TLS for TCP).
As a consequence, the selection of the transport protocol used for As a consequence, the selection of the transport protocol used for
the initial unauthorized resource request also depends on the the initial unauthorized resource request also depends on the
transport layer security mechanism supported by the Client. Clients transport layer security mechanism supported by the Client. Clients
that support either DTLS or TLS but not both SHOULD use the transport that support either DTLS or TLS but not both SHOULD use the transport
protocol underlying the supported transport layer security mechanism protocol underlying the supported transport layer security mechanism
also for an initial unauthorized resource request to the Resource for an initial unauthorized resource request to the Resource Server,
Server as in Section 2 of [RFC9202]. as in Section 2 of [RFC9202].
5. IANA Considerations 5. IANA Considerations
The following updates have been done to the "ACE Profiles" registry In the "ACE Profiles" registry, the Description and Reference fields
for the profile with a "CBOR Value" field value of 1 and "Name" of have been updated as follows for coap_dtls:
"coap_dtls":
Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" Name: coap_dtls
with the RFC number of this specification and delete this paragraph.
Description: Profile for delegating client Authentication and Description: Profile for delegating client Authentication and
Authorization for Constrained Environments by establishing a Datagram Authorization for Constrained Environments by establishing a
Transport Layer Security (DTLS) or Transport Layer Security (TLS) Datagram Transport Layer Security (DTLS) or Transport Layer
channel between resource-constrained nodes. Security (TLS) channel between resource-constrained nodes.
Change Controller: IESG CBOR Value: 1
Reference: [RFC9202] [RFC-XXXX] Reference: [RFC9202], RFC 9430
6. Security Considerations 6. Security Considerations
The security consideration and requirements in [RFC9202], TLS 1.3 The security consideration and requirements in [RFC9202], TLS 1.3
[RFC8446], and BCP 195 [RFC8996] [RFC9325] also apply to this [RFC8446], and BCP 195 [RFC8996] [RFC9325] also apply to this
document. document.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
skipping to change at page 6, line 31 skipping to change at line 250
Acknowledgments Acknowledgments
The authors would like to thank Marco Tiloca for reviewing this The authors would like to thank Marco Tiloca for reviewing this
specification. specification.
Authors' Addresses Authors' Addresses
Olaf Bergmann Olaf Bergmann
Universität Bremen TZI Universität Bremen TZI
Bremen, D-28359 D-28359 Bremen
Germany Germany
Email: bergmann@tzi.org Email: bergmann@tzi.org
John Preuß Mattsson John Preuß Mattsson
Ericsson AB Ericsson AB
SE-164 80 Stockholm SE-164 80 Stockholm
Sweden Sweden
Email: john.mattsson@ericsson.com Email: john.mattsson@ericsson.com
Göran Selander Göran Selander
 End of changes. 26 change blocks. 
87 lines changed or deleted 82 lines changed or added

This html diff was produced by rfcdiff 1.48.