doc: Add RFC documents

1 files changed, 467 insertions, 0 deletions

diff --git a/doc/rfc/rfc9509.txt b/doc/rfc/rfc9509.txt
new file mode 100644
index 0000000..56771f0
--- /dev/null
+++ b/doc/rfc/rfc9509.txt
@@ -0,0 +1,467 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                        T. Reddy.K
+Request for Comments: 9509                                      J. Ekman
+Category: Standards Track                                          Nokia
+ISSN: 2070-1721                                               D. Migault
+                                                                Ericsson
+                                                              March 2024
+
+
+  X.509 Certificate Extended Key Usage (EKU) for 5G Network Functions
+
+Abstract
+
+   RFC 5280 specifies several extended key purpose identifiers
+   (KeyPurposeIds) for X.509 certificates.  This document defines
+   encrypting JSON objects in HTTP messages, using JSON Web Tokens
+   (JWTs), and signing the OAuth 2.0 access tokens KeyPurposeIds for
+   inclusion in the Extended Key Usage (EKU) extension of X.509 v3
+   public key certificates used by Network Functions (NFs) for the 5G
+   System.
+
+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/rfc9509.
+
+Copyright Notice
+
+   Copyright (c) 2024 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.  Extended Key Purpose for Network Functions
+   4.  Including the Extended Key Purpose in Certificates
+   5.  Implications for a Certification Authority
+   6.  Security Considerations
+   7.  Privacy Considerations
+   8.  IANA Considerations
+   9.  References
+     9.1.  Normative References
+     9.2.  Informative References
+   Appendix A.  ASN.1 Module
+   Acknowledgments
+   Contributor
+   Authors' Addresses
+
+1.  Introduction
+
+   The operators of 5G ("fifth generation") systems as defined by 3GPP
+   make use of an internal PKI to generate X.509 PKI certificates for
+   the Network Functions (NFs) (Section 6 of [TS23.501]) in a 5G System.
+   The certificates are used for the following purposes:
+
+   *  Client and Server certificates for NFs in 5G Core (5GC) Service
+      Based Architecture (SBA) (see Section 6.1.3c of [TS33.310] and
+      Section 6.7.2 of [TS29.500])
+
+   *  Client Credentials Assertion (CCA) uses JSON Web Tokens (JWTs)
+      [RFC7519] and is secured with digital signatures based on the JSON
+      Web Signature (JWS) [RFC7515] (see Section 13.3.8.2 of [TS33.501],
+      and Section 6.7.5 of [TS29.500]).
+
+   *  Certificates for encrypting JSON objects in HTTP messages between
+      Security Edge Protection Proxies (SEPPs) using JSON Web Encryption
+      (JWE) [RFC7516] (see Section 13.2.4.4 of [TS33.501], Section 6.3.2
+      of [TS33.210], Section 6.7.4 of [TS29.500], and Section 5.3.2.1 of
+      [TS29.573]).
+
+   *  Certificates for signing the OAuth 2.0 access tokens for service
+      authorization to grant temporary access to resources provided by
+      NF producers using JWS (see Section 13.4.1 of [TS33.501] and
+      Section 6.7.3 of [TS29.500]).
+
+   [RFC5280] specifies several key usage extensions, defined via
+   KeyPurposeIds, for X.509 certificates.  Key usage extensions added to
+   a certificate are meant to express intent as to the purpose of the
+   named usage, for humans and for complying libraries.  In addition,
+   the IANA registry "SMI Security for PKIX Extended Key Purpose"
+   [RFC7299] contains additional KeyPurposeIds.  The use of the
+   anyExtendedKeyUsage KeyPurposeId, as defined in Section 4.2.1.12 of
+   [RFC5280], is generally considered a poor practice.  This is
+   especially true for publicly trusted certificates, whether they are
+   multi-purpose or single-purpose, within the context of 5G Systems and
+   the 5GC Service Based Architecture.
+
+   If the purpose of the issued certificates is not restricted, i.e.,
+   the type of operations for which a public key contained in the
+   certificate can be used are not specified, those certificates could
+   be used for another purpose than intended, increasing the risk of
+   cross-protocol attacks.  Failure to ensure proper segregation of
+   duties means that a NF that generates the public/private keys and
+   applies for a certificate to the operator certification authority
+   could obtain a certificate that can be misused for tasks that this NF
+   is not entitled to perform.  For example, a NF service consumer could
+   potentially impersonate NF service producers using its certificate.
+   Additionally, in cases where the certificate's purpose is intended
+   for use by the NF service consumer as a client certificate, it's
+   essential to ensure that the NF with this client certificate and the
+   corresponding private key are not allowed to sign the Client
+   Credentials Assertion (CCA).  When a NF service producer receives the
+   signed CCA from the NF service consumer, the NF should only accept
+   the token if the CCA is signed with a certificate that has been
+   explicitly issued for this purpose.
+
+   The KeyPurposeId id-kp-serverAuth (Section 4.2.1.12 of [RFC5280]) can
+   be used to identify that the certificate is for a server (e.g., NF
+   service producer), and the KeyPurposeId id-kp-clientAuth
+   (Section 4.2.1.12 of [RFC5280]) can be used to identify that the
+   certificate is for a client (e.g., NF service consumer).  However,
+   there are currently no KeyPurposeIds for the other usages of
+   certificates in a 5G System.  This document addresses the above
+   problem by defining the EKU extension of X.509 public key
+   certificates for signing the JWT Claims Set using JWS, encrypting
+   JSON objects in HTTP messages using JWE, and signing the OAuth 2.0
+   access tokens using JWS.
+
+   Vendor-defined KeyPurposeIds used within a PKI governed by the vendor
+   or a group of vendors typically do not pose interoperability
+   concerns, as non-critical extensions can be safely ignored if
+   unrecognized.  However, using or misusing KeyPurposeIds outside of
+   their intended vendor-controlled environment can lead to
+   interoperability issues.  Therefore, it is advisable not to rely on
+   vendor-defined KeyPurposeIds.  Instead, the specification defines
+   standard KeyPurposeIds to ensure interoperability across various
+   implementations.
+
+   Although the specification focuses on a 5G use case, the standard
+   KeyPurposeIds defined in this document can be used in other
+   deployments.
+
+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.
+
+3.  Extended Key Purpose for Network Functions
+
+   This specification defines the KeyPurposeIds id-kp-jwt, id-kp-
+   httpContentEncrypt, and id-kp-oauthAccessTokenSigning and uses these,
+   respectively, for: signing the JWT Claims Set of CCA using JWS,
+   encrypting JSON objects in HTTP messages between Security Edge
+   Protection Proxies (SEPPs) using JWE, and signing the OAuth 2.0
+   access tokens for service authorization to grant temporary access to
+   resources provided by NF producers using JWS.  As described in
+   [RFC5280], "[i]f the [Extended Key Usage] extension is present, then
+   the certificate MUST only be used for one of the purposes indicated."
+   [RFC5280] also notes that "[i]f multiple [key] purposes are indicated
+   the application need not recognize all purposes indicated, as long as
+   the intended purpose is present."
+
+   Network Functions that verify the signature of a CCA represented as a
+   JWT, decrypt JSON objects in HTTP messages between Security Edge
+   Protection Proxies (SEPPs) using JWE, or verify the signature of an
+   OAuth 2.0 access tokens for service authorization to grant temporary
+   access to resources provided by NF producers using JWS SHOULD require
+   that corresponding KeyPurposeIds be specified by the EKU extension.
+   If the certificate requester knows the certificate users are mandated
+   to use these KeyPurposeIds, it MUST enforce their inclusion.
+   Additionally, such a certificate requester MUST ensure that the
+   KeyUsage extension be set to digitalSignature or nonRepudiation (also
+   designated as contentCommitment) for signature calculation and/or to
+   keyEncipherment for secret key encryption.
+
+4.  Including the Extended Key Purpose in Certificates
+
+   [RFC5280] specifies the EKU X.509 certificate extension for use on
+   end entity certificates.  The extension indicates one or more
+   purposes for which the certified public key is valid.  The EKU
+   extension can be used in conjunction with the key usage extension,
+   which indicates the set of basic cryptographic operations for which
+   the certified key may be used.  The EKU extension syntax is repeated
+   here for convenience:
+
+   ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
+
+   KeyPurposeId ::= OBJECT IDENTIFIER
+
+   As described in [RFC5280], the EKU extension may, at the option of
+   the certificate issuer, be either critical or non-critical.  The
+   inclusion of KeyPurposeIds id-kp-jwt, id-kp-httpContentEncrypt, and
+   id-kp-oauthAccessTokenSigning in a certificate indicates that the
+   public key encoded in the certificate has been certified for use in
+   the following:
+
+   1.  Validating the JWS Signature in JWT.  The distinction between JWS
+       and JWE is determined by the Key Usage (KU) that is set to
+       digitalSignature or nonRepudiation for JWS and keyEncipherment
+       for JWE.
+
+   2.  Encrypting JSON objects in HTTP messages (for example, encrypting
+       the content-encryption key (CEK) with the recipient's public key
+       using the RSAES-OAEP algorithm to produce the JWE Encrypted Key).
+       KU is set to keyEncipherment.
+
+   3.  Signing OAuth 2.0 access tokens.  In this case, KU is set to
+       digitalSignature or nonRepudiation.
+
+        id-kp  OBJECT IDENTIFIER  ::= {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) mechanisms(5) pkix(7) kp(3) }
+
+   id-kp-jwt OBJECT IDENTIFIER ::= { id-kp 37 }
+   id-kp-httpContentEncrypt OBJECT IDENTIFIER ::= { id-kp 38 }
+   id-kp-oauthAccessTokenSigning OBJECT IDENTIFIER ::= { id-kp 39 }
+
+5.  Implications for a Certification Authority
+
+   The procedures and practices employed by a certification authority
+   MUST ensure that the correct values for the EKU extension as well as
+   the KU extension are inserted in each certificate that is issued.
+   The inclusion of the id-kp-jwt, id-kp-httpContentEncrypt, and id-kp-
+   oauthAccessTokenSigning KeyPurposeIds does not preclude the inclusion
+   of other KeyPurposeIds.
+
+6.  Security Considerations
+
+   The Security Considerations of [RFC5280] are applicable to this
+   document.  This extended key purpose does not introduce new security
+   risks but instead reduces existing security risks by providing the
+   means to identify if the certificate is generated to sign the JWT
+   Claims Set, signing the OAuth 2.0 access tokens using JWS, or
+   encrypting the CEK in JWE for encrypting JSON objects in HTTP
+   messages.
+
+   To reduce the risk of specific cross-protocol attacks, the relying
+   party or the relying party software may additionally prohibit use of
+   specific combinations of KeyPurposeIds.  The procedure for allowing
+   or disallowing combinations of KeyPurposeIds using Excluded
+   KeyPurposeId and Permitted KeyPurposeId, as carried out by a relying
+   party, is defined in Section 4 of [RFC9336].  Examples of Excluded
+   KeyPurposeIds include the presence of the anyExtendedKeyUsage
+   KeyPurposeId or the complete absence of the EKU extension in a
+   certificate.  Examples of Permitted KeyPurposeIds include the
+   presence of id-kp-jwt, id-kp-httpContentEncrypt, or id-kp-
+   oauthAccessTokenSigning KeyPurposeIds.
+
+7.  Privacy Considerations
+
+   In some security protocols, such as TLS 1.2 [RFC5246], certificates
+   are exchanged in the clear.  In other security protocols, such as TLS
+   1.3 [RFC8446], the certificates are encrypted.  The inclusion of the
+   EKU extension can help an observer determine the purpose of the
+   certificate.  In addition, if the certificate is issued by a public
+   certification authority, the inclusion of an EKU extension can help
+   an attacker to monitor the Certificate Transparency logs [RFC9162] to
+   identify the purpose of the certificate.
+
+8.  IANA Considerations
+
+   IANA has registered the following OIDs in the "SMI Security for PKIX
+   Extended Key Purpose" registry (1.3.6.1.5.5.7.3).  These OIDs are
+   defined in Section 4.
+
+   +=========+===============================+============+
+   | Decimal | Description                   | References |
+   +=========+===============================+============+
+   | 37      | id-kp-jwt                     | RFC 9509   |
+   +---------+-------------------------------+------------+
+   | 38      | id-kp-httpContentEncrypt      | RFC 9509   |
+   +---------+-------------------------------+------------+
+   | 39      | id-kp-oauthAccessTokenSigning | RFC 9509   |
+   +---------+-------------------------------+------------+
+
+                           Table 1
+
+   IANA has registered the following ASN.1[X.680] module OID in the "SMI
+   Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).
+   This OID is defined in Appendix A.
+
+   +=========+===============+============+
+   | Decimal | Description   | References |
+   +=========+===============+============+
+   | 108     | id-mod-nf-eku | RFC 9509   |
+   +---------+---------------+------------+
+
+                   Table 2
+
+9.  References
+
+9.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>.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+              <https://www.rfc-editor.org/info/rfc5280>.
+
+   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
+              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
+              2015, <https://www.rfc-editor.org/info/rfc7515>.
+
+   [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
+              RFC 7516, DOI 10.17487/RFC7516, May 2015,
+              <https://www.rfc-editor.org/info/rfc7516>.
+
+   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
+              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
+              <https://www.rfc-editor.org/info/rfc7519>.
+
+   [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>.
+
+   [X.680]    ITU-T, "Information technology - Abstract Syntax Notation
+              One (ASN.1): Specification of basic notation", ITU-T
+              Recommendation X.680, February 2021,
+              <https://www.itu.int/rec/T-REC-X.680>.
+
+   [X.690]    ITU-T, "Information technology - ASN.1 encoding rules:
+              Specification of Basic Encoding Rules (BER), Canonical
+              Encoding Rules (CER) and Distinguished Encoding Rules
+              (DER)", ITU-T Recommendation X.690, February 2021,
+              <https://www.itu.int/rec/T-REC-X.690>.
+
+9.2.  Informative References
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <https://www.rfc-editor.org/info/rfc5246>.
+
+   [RFC7299]  Housley, R., "Object Identifier Registry for the PKIX
+              Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014,
+              <https://www.rfc-editor.org/info/rfc7299>.
+
+   [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>.
+
+   [RFC9162]  Laurie, B., Messeri, E., and R. Stradling, "Certificate
+              Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
+              December 2021, <https://www.rfc-editor.org/info/rfc9162>.
+
+   [RFC9336]  Ito, T., Okubo, T., and S. Turner, "X.509 Certificate
+              General-Purpose Extended Key Usage (EKU) for Document
+              Signing", RFC 9336, DOI 10.17487/RFC9336, December 2022,
+              <https://www.rfc-editor.org/info/rfc9336>.
+
+   [TS23.501] 3GPP, "System architecture for the 5G System (5GS)",
+              Release 18.4.0, 3GPP TS 23.501, December 2023,
+              <https://www.3gpp.org/ftp/Specs/
+              archive/23_series/23.501/23501-i40.zip>.
+
+   [TS29.500] 3GPP, "5G System; Technical Realization of Service Based
+              Architecture; Stage 3", Release 18.4.0, 3GPP TS 29.500,
+              December 2023, <https://www.3gpp.org/ftp/Specs/
+              archive/29_series/29.500/29500-i40.zip>.
+
+   [TS29.573] 3GPP, "5G System; Public Land Mobile Network (PLMN)
+              Interconnection; Stage 3", Release 18.5.0, 3GPP TS 29.573,
+              December 2023, <https://www.3gpp.org/ftp/Specs/
+              archive/29_series/29.573/29573-i50.zip>.
+
+   [TS33.210] 3GPP, "Network Domain Security (NDS); IP network layer
+              security", Release 17.1.0, 3GPP TS 33.210, September 2022,
+              <https://www.3gpp.org/ftp/Specs/
+              archive/33_series/33.210/33210-h10.zip>.
+
+   [TS33.310] 3GPP, "Network Domain Security (NDS); Authentication
+              Framework (AF)", Release 18.2.0, 3GPP TS 33.310, December
+              2023, <https://www.3gpp.org/ftp/Specs/
+              archive/33_series/33.310/33310-i20.zip>.
+
+   [TS33.501] 3GPP, "Security architecture and procedures for 5G
+              system", Release 18.4.0, 3GPP TS 33.501, December 2023,
+              <https://www.3gpp.org/ftp/Specs/
+              archive/33_series/33.501/33501-i40.zip>.
+
+Appendix A.  ASN.1 Module
+
+   The following module adheres to ASN.1 specifications [X.680] and
+   [X.690].
+
+   <CODE BEGINS>
+   NF-EKU
+     { iso(1) identified-organization(3) dod(6) internet(1)
+     security(5) mechanisms(5) pkix(7) id-mod(0)
+     id-mod-nf-eku (108) }
+
+   DEFINITIONS IMPLICIT TAGS ::=
+   BEGIN
+
+   -- OID Arc
+
+   id-kp OBJECT IDENTIFIER ::=
+     { iso(1) identified-organization(3) dod(6) internet(1)
+       security(5) mechanisms(5) pkix(7) kp(3) }
+
+   -- Extended Key Usage Values
+
+   id-kp-jwt OBJECT IDENTIFIER ::= { id-kp 37 }
+   id-kp-httpContentEncrypt OBJECT IDENTIFIER ::= { id-kp 38 }
+   id-kp-oauthAccessTokenSigning OBJECT IDENTIFIER ::= { id-kp 39 }
+
+   END
+   <CODE ENDS>
+
+Acknowledgments
+
+   We would like to thank Corey Bonnell, Ilari Liusvaara, Carl Wallace,
+   and Russ Housley for their useful feedback.  Thanks to Yoav Nir for
+   the secdir review, Elwyn Davies for the genart review, and Benson
+   Muite for the intdir review.
+
+   Thanks to Paul Wouters, Lars Eggert, and Éric Vyncke for the IESG
+   review.
+
+Contributor
+
+   The following individual has contributed to this document:
+
+   German Peinado
+   Nokia
+   Email: german.peinado@nokia.com
+
+
+Authors' Addresses
+
+   Tirumaleswar Reddy.K
+   Nokia
+   India
+   Email: kondtir@gmail.com
+
+
+   Jani Ekman
+   Nokia
+   Finland
+   Email: jani.ekman@nokia.com
+
+
+   Daniel Migault
+   Ericsson
+   Canada
+   Email: daniel.migault@ericsson.com