Additional Formats of Authentication Credentials for the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)
draft-tiloca-ace-authcred-dtls-profile-01
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Marco Tiloca , John Preuß Mattsson | ||
| Last updated | 2024-01-10 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tiloca-ace-authcred-dtls-profile-01
ACE Working Group M. Tiloca
Internet-Draft RISE AB
Updates: 9202 (if approved) J. P. Mattsson
Intended status: Standards Track Ericsson AB
Expires: 13 July 2024 10 January 2024
Additional Formats of Authentication Credentials for the Datagram
Transport Layer Security (DTLS) Profile for Authentication and
Authorization for Constrained Environments (ACE)
draft-tiloca-ace-authcred-dtls-profile-01
Abstract
This document updates the Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for Constrained
Environments (ACE). In particular, it specifies the use of
additional formats of authentication credentials for establishing a
DTLS session, when peer authentication is based on asymmetric
cryptography. Therefore, this document updates RFC 9202. What is
defined in this document is seamlessly applicable also if the profile
uses Transport Layer Security (TLS) instead, as defined in RFC 9430.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Authentication and
Authorization for Constrained Environments Working Group mailing list
(ace@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/ace/.
Source for this draft and an issue tracker can be found at
https://gitlab.com/crimson84/draft-tiloca-ace-authcred-dtls-profile.
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/.
Tiloca & Mattsson Expires 13 July 2024 [Page 1]
Internet-Draft Authentication Credentials DTLS profile January 2024
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 13 July 2024.
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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Updates to the RPK Mode . . . . . . . . . . . . . . . . . . . 5
3. Certificate Mode . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Examples with Hybrid Settings . . . . . . . . . . . 14
A.1. RPK Mode (Raw Public Keys of Different Formats) . . . . . 14
A.2. Certificate Mode (Certificates of Different Formats) . . 14
A.3. Combination of RPK Mode and Certificate Mode . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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.
Tiloca & Mattsson Expires 13 July 2024 [Page 2]
Internet-Draft Authentication Credentials DTLS profile January 2024
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).
* 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).
Tiloca & Mattsson Expires 13 July 2024 [Page 3]
Internet-Draft Authentication Credentials DTLS profile January 2024
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].
1.1. 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 the ACE framework for Authentication and Authorization
[RFC9200][RFC9201] and its DTLS profile [RFC9202], as well as with
terms and concepts related to CBOR Web Tokens (CWTs) [RFC8392] and
CWT Confirmation Methods [RFC8747].
The terminology for entities in the considered architecture is
defined in OAuth 2.0 [RFC6749]. In particular, this includes Client
(C), Resource Server (RS), and Authorization Server (AS).
Readers are also expected to be familiar with the terms and concepts
related to the CoAP protocol [RFC7252], CBOR [RFC8949], COSE
[RFC9052][RFC9053], the DTLS protocol suite [RFC6347][RFC9147], and
the use of raw public keys in DTLS [RFC7250].
Tiloca & Mattsson Expires 13 July 2024 [Page 4]
Internet-Draft Authentication Credentials DTLS profile January 2024
Note that, unless otherwise indicated, the term "endpoint" is used
here following its OAuth definition, aimed at denoting resources such
as /token and /introspect at the AS, and /authz-info at RS. This
document does not use the CoAP definition of "endpoint", which is "An
entity participating in the CoAP protocol."
This document also refers to the term "authentication credential",
which denotes the information associated with an entity, including
that entity's public key and parameters associated with the public
key. Examples of authentication credentials are CWT Claims Sets
(CCSs) [RFC8392], X.509 certificates [RFC5280], and C509 certificates
[I-D.ietf-cose-cbor-encoded-cert].
Examples throughout this document are expressed in CBOR diagnostic
notation without the tag and value abbreviations.
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, 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.
* 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.
If the raw public key of RS is transported as a CCS, 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 [RFC8392] specifying the public key of RS.
Tiloca & Mattsson Expires 13 July 2024 [Page 5]
Internet-Draft Authentication Credentials DTLS profile January 2024
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" : 2,
"audience" : "tempSensor4711",
"req_cnf" : {
"kccs" : {
"sub" : "42-50-31-FF-EF-37-32-39",
"cnf" : {
"COSE_Key" : {
"kty" : 2,
"crv" : 1,
"x" : h'd7cc072de2205bdc1537a543d53c60a6
acb62eccd890c7fa27c9e354089bbe13',
"y" : h'f95e1d4b851a2cc80fff87d8e23f22af
b725d535e515d020731e79a3b4e47120'
}
}
}
}
}
Figure 1: Access Token Request Example for RPK Mode, with the
Public Key of C Transported as a CCS within "req_cnf"
Figure 2 shows an example of Access Token Response from the AS to C.
Tiloca & Mattsson Expires 13 July 2024 [Page 6]
Internet-Draft Authentication Credentials DTLS profile January 2024
2.01 Created
Content-Format: application/ace+cbor
Max-Age: 3560
Payload:
{
"access_token" : b64'SlAV32hk'/...
(remainder of CWT omitted for brevity;
CWT contains the client's RPK in the cnf claim)/,
"expires_in" : 3600,
"rs_cnf" : {
"kccs" : {
"sub" : "AA-BB-CC-00-01-02-03-04",
"cnf" : {
"COSE_Key" : {
"kty" : 2,
"crv" : 1,
"x" : h'bbc34960526ea4d32e940cad2a234148
ddc21791a12afbcbac93622046dd44f0',
"y" : h'4519e257236b2a0ce2023f0931f1f386
ca7afda64fcde0108c224c51eabf6072'
}
}
}
}
}
Figure 2: Access Token Response Example for RPK Mode, with the
Public Key of RS Transported as a CCS within "rs_cnf"
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, the following applies.
Tiloca & Mattsson Expires 13 July 2024 [Page 7]
Internet-Draft Authentication Credentials DTLS profile January 2024
- The "req_cnf" parameter [RFC9201] of the Access Token Request
(see Section 5.8.1 of [RFC9200]) specifies AUTH_CRED_C as
follows.
o 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.
o 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.
o 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.
o 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, the following applies.
- The "rs_cnf" parameter [RFC9201] of the Access Token Response
specifies AUTH_CRED_RS as follows.
o 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.
o 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].
Tiloca & Mattsson Expires 13 July 2024 [Page 8]
Internet-Draft Authentication Credentials DTLS profile January 2024
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][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" : 2,
"audience" : "tempSensor4711",
"req_cnf" : {
"x5chain" : h'3081ee3081a1a003020102020462319ec430
0506032b6570301d311b301906035504030c
124544484f4320526f6f7420456432353531
39301e170d3232303331363038323433365a
170d3239313233313233303030305a302231
20301e06035504030c174544484f43205265
73706f6e6465722045643235353139302a30
0506032b6570032100a1db47b95184854ad1
2a0c1a354e418aace33aa0f2c662c00b3ac5
5de92f9359300506032b6570034100b723bc
01eab0928e8b2b6c98de19cc3823d46e7d69
87b032478fecfaf14537a1af14cc8be829c6
b73044101837eb4abc949565d86dce51cfae
52ab82c152cb02'
}
}
Tiloca & Mattsson Expires 13 July 2024 [Page 9]
Internet-Draft Authentication Credentials DTLS profile January 2024
Figure 3: Access Token Request Example for Certificate Mode with
an X.509 Certificate as Authentication Credential of C and
Transported within "req_cnf"
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" : b64'SlAV32hk'/...
(remainder of CWT omitted for brevity;
CWT contains the client's X.509 certificate in the cnf claim)/,
"expires_in" : 3600,
"rs_cnf" : {
"x5chain" : h'3081ee3081a1a003020102020462319ea030
0506032b6570301d311b301906035504030c
124544484f4320526f6f7420456432353531
39301e170d3232303331363038323430305a
170d3239313233313233303030305a302231
20301e06035504030c174544484f4320496e
69746961746f722045643235353139302a30
0506032b6570032100ed06a8ae61a829ba5f
a54525c9d07f48dd44a302f43e0f23d8cc20
b73085141e300506032b6570034100521241
d8b3a770996bcfc9b9ead4e7e0a1c0db353a
3bdf2910b39275ae48b756015981850d27db
6734e37f67212267dd05eeff27b9e7a813fa
574b72a00b430b'
}
}
Figure 4: Access Token Response Example for Certificate Mode with
an X.509 Certificate as Authentication Credential of RS and
Transported within "rs_cnf"
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.
Tiloca & Mattsson Expires 13 July 2024 [Page 10]
Internet-Draft Authentication Credentials DTLS profile January 2024
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.
6. References
6.1. Normative References
[I-D.ietf-ace-edhoc-oscore-profile]
Selander, G., Mattsson, J. P., Tiloca, M., and R. Höglund,
"Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object
Security for Constrained Environments (OSCORE) Profile for
Authentication and Authorization for Constrained
Environments (ACE)", Work in Progress, Internet-Draft,
draft-ietf-ace-edhoc-oscore-profile-03, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ace-
edhoc-oscore-profile-03>.
[I-D.ietf-cose-cbor-encoded-cert]
Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and
M. Furuhed, "CBOR Encoded X.509 Certificates (C509
Certificates)", Work in Progress, Internet-Draft, draft-
ietf-cose-cbor-encoded-cert-07, 20 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
cbor-encoded-cert-07>.
[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/rfc/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/rfc/rfc5280>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/rfc/rfc6347>.
Tiloca & Mattsson Expires 13 July 2024 [Page 11]
Internet-Draft Authentication Credentials DTLS profile January 2024
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[RFC6818] Yee, P., "Updates to the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January
2013, <https://www.rfc-editor.org/rfc/rfc6818>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/rfc/rfc7250>.
[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/rfc/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/rfc/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/rfc/rfc8323>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.
[RFC8398] Melnikov, A., Ed. and W. Chuang, Ed., "Internationalized
Email Addresses in X.509 Certificates", RFC 8398,
DOI 10.17487/RFC8398, May 2018,
<https://www.rfc-editor.org/rfc/rfc8398>.
[RFC8399] Housley, R., "Internationalization Updates to RFC 5280",
RFC 8399, DOI 10.17487/RFC8399, May 2018,
<https://www.rfc-editor.org/rfc/rfc8399>.
[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/rfc/rfc8446>.
Tiloca & Mattsson Expires 13 July 2024 [Page 12]
Internet-Draft Authentication Credentials DTLS profile January 2024
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/rfc/rfc8747>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.
[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/rfc/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/rfc/rfc9200>.
[RFC9201] Seitz, L., "Additional OAuth Parameters for Authentication
and Authorization for Constrained Environments (ACE)",
RFC 9201, DOI 10.17487/RFC9201, August 2022,
<https://www.rfc-editor.org/rfc/rfc9201>.
[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/rfc/rfc9202>.
[RFC9430] Bergmann, O., Preuß Mattsson, J., and G. Selander,
"Extension of the Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for
Constrained Environments (ACE) to Transport Layer Security
(TLS)", RFC 9430, DOI 10.17487/RFC9430, July 2023,
<https://www.rfc-editor.org/rfc/rfc9430>.
Tiloca & Mattsson Expires 13 July 2024 [Page 13]
Internet-Draft Authentication Credentials DTLS profile January 2024
6.2. Informative References
[RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys
for Transport Layer Security (TLS) Authentication",
RFC 6091, DOI 10.17487/RFC6091, February 2011,
<https://www.rfc-editor.org/rfc/rfc6091>.
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).
A.1. RPK Mode (Raw Public Keys of Different Formats)
TBD
A.2. Certificate Mode (Certificates of Different Formats)
TBD
A.3. Combination of RPK Mode and Certificate Mode
TBD
Acknowledgments
The authors sincerely thank Rikard Höglund and Göran Selander for
their comments and feedback. The work on this document has been
partly supported by the H2020 project SIFIS-Home (Grant agreement
952652).
Authors' Addresses
Marco Tiloca
RISE AB
Isafjordsgatan 22
SE-16440 Kista
Sweden
Email: marco.tiloca@ri.se
Tiloca & Mattsson Expires 13 July 2024 [Page 14]
Internet-Draft Authentication Credentials DTLS profile January 2024
John Preuß Mattsson
Ericsson AB
Torshamnsgatan 23
SE-16440 Stockholm Kista
Sweden
Email: john.mattsson@ericsson.com
Tiloca & Mattsson Expires 13 July 2024 [Page 15]