doc: Add RFC documents

1 files changed, 270 insertions, 0 deletions

diff --git a/doc/rfc/rfc9430.txt b/doc/rfc/rfc9430.txt
new file mode 100644
index 0000000..692394e
--- /dev/null
+++ b/doc/rfc/rfc9430.txt
@@ -0,0 +1,270 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                       O. Bergmann
+Request for Comments: 9430                                           TZI
+Updates: 9202                                          J. Preuß Mattsson
+Category: Standards Track                                    G. Selander
+ISSN: 2070-1721                                                 Ericsson
+                                                               July 2023
+
+
+ Extension of the Datagram Transport Layer Security (DTLS) Profile for
+ Authentication and Authorization for Constrained Environments (ACE) to
+                     Transport Layer Security (TLS)
+
+Abstract
+
+   This document updates "Datagram Transport Layer Security (DTLS)
+   Profile for Authentication and Authorization for Constrained
+   Environments (ACE)" (RFC 9202) by specifying that the profile applies
+   to TLS as well as DTLS.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   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 (c) 2023 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Terminology
+   3.  Specific Changes to RFC 9202
+   4.  Connection Establishment
+   5.  IANA Considerations
+   6.  Security Considerations
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   The Authentication and Authorization for Constrained Environments
+   (ACE) framework [RFC9200] defines an architecture for lightweight
+   authentication between the Client, Resource Server (RS), and
+   Authorization Server (AS), where the Client and RS may be
+   constrained.  "Datagram Transport Layer Security (DTLS) Profile for
+   Authentication and Authorization for Constrained Environments (ACE)"
+   [RFC9202] only specifies the use of DTLS [RFC9147] for transport
+   layer security between the nodes in the ACE architecture but works
+   equally well for Transport Layer Security (TLS) [RFC8446].  For many
+   constrained implementations, the Constrained Application Protocol
+   (CoAP) over UDP [RFC7252] is the first choice, but when deploying ACE
+   in networks controlled by other entities (such as the Internet), UDP
+   might be blocked on the path between the Client and the Resource
+   Server, and the Client might have to fall back to CoAP over TCP
+   [RFC8323] for NAT or firewall traversal.  This dual support for
+   security over TCP as well as UDP is already supported by the Object
+   Security for Constrained RESTful Environments (OSCORE) profile
+   [RFC9203].
+
+   This document updates [RFC9202] by specifying that the profile
+   applies to TLS as well as DTLS.  It only impacts the transport layer
+   security channel between the Client and Resource Server.  The same
+   access rights are valid in case transport layer security is provided
+   by either DTLS or TLS.  The same access token can be used by either
+   DTLS or TLS between a given (Client, RS) pair.  Therefore, the value
+   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
+   access token indicates that either DTLS or TLS can be used for
+   transport layer security.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   Readers are expected to be familiar with the terms and concepts
+   described in [RFC9200] and [RFC9202].
+
+3.  Specific Changes to RFC 9202
+
+   The main changes to [RFC9202] specified in this document are limited
+   to replacing "DTLS" with "DTLS/TLS" throughout the document.  This
+   essentially impacts the use of secure transport, as described in
+   Sections 3.2.2, 3.3.2, 4, and 5.
+
+   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
+   available, as described in the following section.
+
+4.  Connection Establishment
+
+   Following the procedures defined in [RFC9202], a Client can retrieve
+   an access token from an Authorization Server in order to establish a
+   security association with a specific Resource Server.  The
+   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
+   towards the Resource Server.
+
+   The ace_profile parameter indicates the use of the DTLS profile for
+   ACE, as defined in [RFC9202].  Therefore, the Client typically first
+   tries using DTLS to connect to the Resource Server.  If this fails,
+   the Client MAY try to connect to the Resource Server via TLS.
+
+   As resource-constrained devices are not expected to support both
+   transport layer security mechanisms, Clients and Resource Servers
+   SHOULD support DTLS and MAY support TLS.  A Client that implements
+   either TLS or DTLS but not both might fail in establishing a secure
+   communication channel with the Resource Server altogether.
+   Nonconstrained Clients and Resource Servers SHOULD support both TLS
+   and DTLS.
+
+   Note that a communication setup with an a priori unknown Resource
+   Server typically employs an initial unauthorized resource request, as
+   illustrated in Section 2 of [RFC9202].  If this message exchange
+   succeeds, the Client SHOULD first use the same underlying transport
+   protocol for the establishment of the security association to the
+   Resource Server (i.e., DTLS for UDP, and TLS for TCP).
+
+   As a consequence, the selection of the transport protocol used for
+   the initial unauthorized resource request also depends on the
+   transport layer security mechanism supported by the Client.  Clients
+   that support either DTLS or TLS but not both SHOULD use the transport
+   protocol underlying the supported transport layer security mechanism
+   for an initial unauthorized resource request to the Resource Server,
+   as in Section 2 of [RFC9202].
+
+5.  IANA Considerations
+
+   In the "ACE Profiles" registry, the Description and Reference fields
+   have been updated as follows for coap_dtls:
+
+   Name:  coap_dtls
+
+   Description:  Profile for delegating client Authentication and
+      Authorization for Constrained Environments by establishing a
+      Datagram Transport Layer Security (DTLS) or Transport Layer
+      Security (TLS) channel between resource-constrained nodes.
+
+   CBOR Value:  1
+
+   Reference:  [RFC9202], RFC 9430
+
+6.  Security Considerations
+
+   The security consideration and requirements in [RFC9202], TLS 1.3
+   [RFC8446], and BCP 195 [RFC8996] [RFC9325] also apply to this
+   document.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
+              Application Protocol (CoAP)", RFC 7252,
+              DOI 10.17487/RFC7252, June 2014,
+              <https://www.rfc-editor.org/info/rfc7252>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8323]  Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
+              Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
+              Application Protocol) over TCP, TLS, and WebSockets",
+              RFC 8323, DOI 10.17487/RFC8323, February 2018,
+              <https://www.rfc-editor.org/info/rfc8323>.
+
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+   [RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
+              Datagram Transport Layer Security (DTLS) Protocol Version
+              1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
+              <https://www.rfc-editor.org/info/rfc9147>.
+
+   [RFC9200]  Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
+              H. Tschofenig, "Authentication and Authorization for
+              Constrained Environments Using the OAuth 2.0 Framework
+              (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
+              <https://www.rfc-editor.org/info/rfc9200>.
+
+   [RFC9202]  Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
+              L. Seitz, "Datagram Transport Layer Security (DTLS)
+              Profile for Authentication and Authorization for
+              Constrained Environments (ACE)", RFC 9202,
+              DOI 10.17487/RFC9202, August 2022,
+              <https://www.rfc-editor.org/info/rfc9202>.
+
+7.2.  Informative References
+
+   [RFC8996]  Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
+              1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
+              <https://www.rfc-editor.org/info/rfc8996>.
+
+   [RFC9203]  Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
+              "The Object Security for Constrained RESTful Environments
+              (OSCORE) Profile of the Authentication and Authorization
+              for Constrained Environments (ACE) Framework", RFC 9203,
+              DOI 10.17487/RFC9203, August 2022,
+              <https://www.rfc-editor.org/info/rfc9203>.
+
+   [RFC9325]  Sheffer, Y., Saint-Andre, P., and T. Fossati,
+              "Recommendations for Secure Use of Transport Layer
+              Security (TLS) and Datagram Transport Layer Security
+              (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
+              2022, <https://www.rfc-editor.org/info/rfc9325>.
+
+Acknowledgments
+
+   The authors would like to thank Marco Tiloca for reviewing this
+   specification.
+
+Authors' Addresses
+
+   Olaf Bergmann
+   Universität Bremen TZI
+   D-28359 Bremen
+   Germany
+   Email: bergmann@tzi.org
+
+
+   John Preuß Mattsson
+   Ericsson AB
+   SE-164 80 Stockholm
+   Sweden
+   Email: john.mattsson@ericsson.com
+
+
+   Göran Selander
+   Ericsson AB
+   SE-164 80 Stockholm
+   Sweden
+   Email: goran.selander@ericsson.com