Additional Formats of Authentication Credentials for the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)

Status of This Memo

This Internet-Draft is submitted in full conformance with the 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 9 January 2025.¶

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

The Authentication and Authorization for Constrained Environments (ACE) framework [RFC9200] defines an architecture to enforce access control for constrained devices. A Client (C) requests an evidence of granted permissions from an Authorization Server (AS) in the form of an access token, then uploads the access token to the target Resource Server (RS), and finally accesses protected resources at RS according to what is specified in the access token.¶

The framework has as main building blocks the OAuth 2.0 framework [RFC6749], the Constrained Application Protocol (CoAP) [RFC7252] for message transfer, CBOR [RFC8949] for compact encoding, and COSE [RFC9052][RFC9053] for self-contained protection of access tokens.¶

Separate profile documents define in detail how the participants in the ACE architecture communicate, especially as to the security protocols that they use. In particular, the ACE profile defined in [RFC9202] specifies how Datagram Transport Layer Security (DTLS) [RFC6347][RFC9147] is used to protect communications with transport-layer security in the ACE architecture. The profile has also been extended in [RFC9430], in order to allow the alternative use of Transport Layer Security (TLS) [RFC8446] when CoAP is transported over TCP or WebSockets [RFC8323].¶

The DTLS profile [RFC9202] allows C and RS to establish a DTLS session with peer authentication based on symmetric or asymmetric cryptography. For the latter case, the profile defines an RPK mode (see Section 3.2 of [RFC9202]), where authentication relies on the public keys of the two peers as raw public keys [RFC7250].¶

That is, C specifies its public key to the AS when requesting an access token, and the AS provides such public key to the target RS as included in the issued access token. Upon issuing the access token, the AS also provides C with the public key of RS. Then, C and RS use their asymmetric keys when performing the DTLS handshake, as defined in [RFC7250].¶

Per [RFC9202], the DTLS profile admits only a COSE Key object [RFC9052] as the format of authentication credentials to use for transporting the public keys of C and RS, as raw public keys. However, it is desirable to enable additional types of authentication credentials, as enhanced raw public keys or as public certificates.¶

This document enables such additional formats, by defining how the public keys of C and RS can be specified as CBOR Web Token (CWT) Claims Sets (CCSs) [RFC8392], or X.509 certificates [RFC5280], or C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. In particular, this document updates [RFC9202] as follows.¶

• It extends the RPK mode defined in Section 3.2 of [RFC9202], by enabling the use of CCSs to transport the raw public keys of C and RS (see Section 2).¶

  [ TODO: Further extend the RPK mode, by admitting the transport of COSE Keys by reference, using the CWT Confirmation Method 'ckt' defined in https://datatracker.ietf.org/doc/html/draft-ietf-cose-key-thumbprint ]¶

• It defines a new certificate mode, which enables the transport of the public keys of C and RS as X.509 or C509 certificates (see Section 3).¶

  [ TODO: Further extend the Certificate mode, by admitting the transport of certificates by reference, using the CWT Confirmation Methods "x5t", "x5u", "c5t", and "c5u" defined in https://datatracker.ietf.org/doc/html/draft-ietf-ace-edhoc-oscore-profile ]¶

When using the updated RPK mode, the raw public keys of C and RS do not have to be of the same type. That is, it is possible to have both public keys as a COSE Key object or as a CCS, or instead one as a COSE Key object while the other one as a CCS.¶

When using the certificate mode, the certificates of C and RS do not have to be of the same type. That is, it is possible to have both as X.509 certificates, or both as C509 certificates, or one as an X.509 certificate while the other one as a C509 certificate.¶

Also, the RPK mode and the certificate mode can be combined. That is, it is possible that one of the two authentication credentials is a certificate, while the other one is a raw public key.¶

When using the formats introduced in this document, authentication credentials are transported by means of the CWT Confirmation Methods "kccs", "x5bag", "x5chain", "c5b", and "c5c", which are defined in [I-D.ietf-ace-edhoc-oscore-profile].¶

What is defined in this document is seamlessly applicable if TLS is used instead, as defined in [RFC9430].¶

2. Updates to the RPK Mode

This section updates the RPK mode defined in Section 3.2 of [RFC9202], by defining how the raw public key of C and RS can be transported as a CCS [RFC8392], instead of as a COSE Key object [RFC9052]. Note that only the differences from [RFC9202] are compiled below.¶

If the raw public key of C is transported as a CCS, then the following applies.¶

• The payload of the Access Token Request (see Section 5.8.1 of [RFC9200]) is as defined in Section 3.2.1 of [RFC9202], with the difference that the "req_cnf" parameter [RFC9201] MUST specify a "kccs" structure, with value a CCS specifying the public key of C that has to be bound to the access token.¶

  In particular, the CCS MUST include the "cnf" claim specifying the public key of C as a COSE Key object, SHOULD include the "sub" claim specifying the subject name of C associated with the public key of C, and MAY include additional claims.¶

• The content of the access token that the AS provides to C in the Access Token Response (see Section 5.8.2 of [RFC9200]) is as defined in Section 3.2.1 of [RFC9202], with the difference that the "cnf" claim of the access token MUST specify a "kccs" structure, with value a CCS specifying the public key of C that is bound to the access token.¶

  In particular, the CCS MUST include the "cnf" claim specifying the public key of C as a COSE Key object, SHOULD include the "sub" claim specifying the subject name of C associated with the public key of C, and MAY include additional claims.¶

If the raw public key of RS is transported as a CCS, then the following applies.¶

• The payload of the Access Token Response is as defined in Section 3.2.1 of [RFC9202], with the difference that the "rs_cnf" parameter [RFC9201] MUST specify a "kccs" structure, with value a CCS specifying the public key of RS.¶

  In particular, the CCS MUST include the "cnf" claim specifying the public key of RS as a COSE Key object, SHOULD include the "sub" claim specifying the subject name of RS associated with the public key of RS, and MAY include additional claims.¶

For the "req_cnf" parameter of the Access Token Request, the "rs_cnf" parameter of the Access Token Response, and the "cnf" claim of the access token, the Confirmation Method "kccs" structure and its identifier are defined in [I-D.ietf-ace-edhoc-oscore-profile].¶

It is not required that both public keys are transported as a CCS. That is, one of the two authentication credentials can be a CCS, while the other one can be a COSE Key object as per Section 3.2 of [RFC9202].¶

Figure 1 shows an example of Access Token Request from C to the AS.¶

   POST coaps://as.example.com/token
   Content-Format: application/ace+cbor
   Payload:
   {
     / grant_type / 33 : 2 / client_credentials /,
     / audience /    5 : "tempSensor4711",
     / req_cnf /     4 : {
       e'kccs' : {
         / sub / 2 : "42-50-31-FF-EF-37-32-39",
         / cnf / 8 : {
           / COSE_Key / 1 : {
             / kty /    1 : 2 / EC2 /,
             / crv /   -1 : 1 / P-256 /,
             / x /     -2 : h'd7cc072de2205bdc1537a543d53c60a6
                              acb62eccd890c7fa27c9e354089bbe13',
             / y /     -3 : h'f95e1d4b851a2cc80fff87d8e23f22af
                              b725d535e515d020731e79a3b4e47120'
           }
         }
       }
     }
   }

Figure 2 shows an example of Access Token Response from the AS to C.¶

   2.01 Created
   Content-Format: application/ace+cbor
   Max-Age: 3560
   Payload:
   {
     / access_token / 1 : b64'SlAV32hk'/...
      (remainder of CWT omitted for brevity;
      CWT contains the client's RPK in the cnf claim)/,
     / expires_in /   2 : 3600,
     / rs_cnf /      41 : {
       e'kccs' : {
         / sub / 2 : "AA-BB-CC-00-01-02-03-04",
         / cnf / 8 : {
           / COSE_Key / 1 : {
             / kty /  1 : 2 / EC2 /,
             / crv / -1 : 1 / P-256 /,
             / x /   -2 : h'bbc34960526ea4d32e940cad2a234148
                            ddc21791a12afbcbac93622046dd44f0',
             / y /   -3 : h'4519e257236b2a0ce2023f0931f1f386
                            ca7afda64fcde0108c224c51eabf6072'
           }
         }
       }
     }
   }

3. Certificate Mode

This section defines a new certificate mode of the DTLS profile, which enables the transport of the public keys of C and RS as public certificates.¶

Compared to the RPK mode defined in Section 3.2 of [RFC9202] and extended in Section 2 of this document, the certificate mode displays the following differences.¶

• The authentication credential of C and/or RS is a public certificate, i.e., an X.509 certificate [RFC5280] or a C509 certificate [I-D.ietf-cose-cbor-encoded-cert]. The CWT Confirmation Methods "x5chain", "x5bag", "c5c", and "c5b" defined in [I-D.ietf-ace-edhoc-oscore-profile] are used to transport such authentication credentials.¶

• If the authentication credential AUTH_CRED_C of C is a public certificate, then the following applies.¶

  • The "req_cnf" parameter [RFC9201] of the Access Token Request (see Section 5.8.1 of [RFC9200]) specifies AUTH_CRED_C as follows.¶

    • If AUTH_CRED_C is an X.509 certificate, the "req_cnf" parameter MUST specify an "x5chain" or "x5bag" structure, in case AUTH_CRED_C is conveyed in a certificate chain or in a certificate bag, respectively.¶

    • If AUTH_CRED_C is a C509 certificate, the "req_cnf" parameter MUST specify a "c5c" or "c5b" structure, in case AUTH_CRED_C is conveyed in a certificate chain or in a certificate bag, respectively.¶

  • The "cnf" claim of the access token that the AS provides to C in the Access Token Response (see Section 5.8.2 of [RFC9200]) specifies AUTH_CRED_C as follows.¶

    • If AUTH_CRED_C is an X.509 certificate, the "cnf" claim MUST specify an "x5chain" or "x5bag" structure, in case AUTH_CRED_C is conveyed in a certificate chain or in a certificate bag, respectively.¶

    • If AUTH_CRED_C is a C509 certificate, the "cnf" claim MUST specify a "c5c" or "c5b" structure, in case AUTH_CRED_C is conveyed in a certificate chain or in a certificate bag, respectively.¶

• If the authentication credential AUTH_CRED_RS of RS is a public certificate, then the following applies.¶

  • The "rs_cnf" parameter [RFC9201] of the Access Token Response specifies AUTH_CRED_RS as follows.¶

    • If AUTH_CRED_RS is an X.509 certificate, the "rs_cnf" parameter MUST specify an "x5chain" or "x5bag" structure, in case AUTH_CRED_RS is conveyed in a certificate chain or in a certificate bag, respectively.¶

    • If AUTH_CRED_RS is a C509 certificate, the "rs_cnf" parameter MUST specify a "c5c" or "c5b" structure, in case AUTH_CRED_RS is conveyed in a certificate chain or in a certificate bag, respectively.¶

For the "req_cnf" parameter of the Access Token Request, the "rs_cnf" parameter of the Access Token Response, and the "cnf" claim of the access token, the Confirmation Method "c5c" and "c5b" structures and their identifiers are defined in [I-D.ietf-ace-edhoc-oscore-profile].¶

When using either of the structures "x5chain", "x5bag", "c5c", and "c5b", i.e., either a chain or a bag of certificates, the specified authentication credential is just the end entity X.509 or C509 certificate.¶

As per [RFC6347] and [RFC9147], a public certificate is specified in the Certificate message of the DTLS handshake. For X.509 certificates, the TLS Certificate Type is "X509", as defined in [RFC6091]. For C509 certificates, the TLS certificate type is "C509 Certificate", as defined in [I-D.ietf-cose-cbor-encoded-cert].¶

It is not required that AUTH_CRED_C and AUTH_CRED_RS are both X.509 certificates or both C509 certificates.¶

Also, one of the two authentication credentials can be a public certificate, while the other one can be a raw public key. This is consistent with the admitted, combined use of raw public keys and certificates, as discussed in Section 5.3 of [RFC7250].¶

Figure 3 shows an example of Access Token Request from C to the AS. In the example, C specifies its authentication credential by means of an "x5chain" structure, including only its own X.509 certificate.¶

   POST coaps://as.example.com/token
   Content-Format: application/ace+cbor
   Payload:
   {
     / grant_type / 33 : 2 / client_credentials /,
     / audience /    5 : "tempSensor4711",
     / req_cnf /     4 : {
            e'x5chain' : h'3081ee3081a1a003020102020462319ec430
                           0506032b6570301d311b301906035504030c
                           124544484f4320526f6f7420456432353531
                           39301e170d3232303331363038323433365a
                           170d3239313233313233303030305a302231
                           20301e06035504030c174544484f43205265
                           73706f6e6465722045643235353139302a30
                           0506032b6570032100a1db47b95184854ad1
                           2a0c1a354e418aace33aa0f2c662c00b3ac5
                           5de92f9359300506032b6570034100b723bc
                           01eab0928e8b2b6c98de19cc3823d46e7d69
                           87b032478fecfaf14537a1af14cc8be829c6
                           b73044101837eb4abc949565d86dce51cfae
                           52ab82c152cb02'
     }
   }

Figure 4 shows an example of Access Token Response from the AS to C. In the example, the AS specifies the authentication credential of RS by means of an "x5chain" structure, including only the X.509 certificate of RS.¶

   2.01 Created
   Content-Format: application/ace+cbor
   Max-Age: 3560
   Payload:
   {
     / access_token / 1 : b64'SlAV32hk'/...
      (remainder of CWT omitted for brevity;
      CWT contains the client's X.509 certificate in the cnf claim)/,
     / expires_in /   2 : 3600,
     / rs_cnf /      41 : {
       e'x5chain' : h'3081ee3081a1a003020102020462319ea030
                      0506032b6570301d311b301906035504030c
                      124544484f4320526f6f7420456432353531
                      39301e170d3232303331363038323430305a
                      170d3239313233313233303030305a302231
                      20301e06035504030c174544484f4320496e
                      69746961746f722045643235353139302a30
                      0506032b6570032100ed06a8ae61a829ba5f
                      a54525c9d07f48dd44a302f43e0f23d8cc20
                      b73085141e300506032b6570034100521241
                      d8b3a770996bcfc9b9ead4e7e0a1c0db353a
                      3bdf2910b39275ae48b756015981850d27db
                      6734e37f67212267dd05eeff27b9e7a813fa
                      574b72a00b430b'
     }
   }

4. Security Considerations

The security considerations from [RFC9200] and [RFC9202] apply to this document as well.¶

When using public certificates as authentication credentials, the security considerations from Appendix C.2 of [RFC8446] apply.¶

When using X.509 certificates as authentication credentials, the security considerations from [RFC5280], [RFC6818], [RFC8398], and [RFC8399] apply.¶

When using C509 certificates as authentication credentials, the security considerations from [I-D.ietf-cose-cbor-encoded-cert] apply.¶

5. IANA Considerations

This document has no actions for IANA.¶

Appendix A. Examples with Hybrid Settings

This section provides additional examples where, within the same ACE execution workflow, C and RS use different formats of raw public keys (see Appendix A.1), or different formats of certificates (see Appendix A.2), or a combination of the RPK mode and certificate mode (see Appendix A.3).¶

Appendix B. CDDL Model

This section is to be removed before publishing as an RFC.¶

; CWT Confirmation Methods
x5chain = 5
kccs = 14

Acknowledgments

The authors sincerely thank Rikard Höglund and Göran Selander for their comments and feedback.¶

This work was supported by the Sweden's Innovation Agency VINNOVA within the EUREKA CELTIC-NEXT project CYPRESS; and by the H2020 project SIFIS-Home (Grant agreement 952652).¶

Authors' Addresses