draft-ietf-ace-oscore-profile-08.txt   draft-ietf-ace-oscore-profile-09.txt 
ACE Working Group F. Palombini ACE Working Group F. Palombini
Internet-Draft Ericsson AB Internet-Draft Ericsson AB
Intended status: Standards Track L. Seitz Intended status: Standards Track L. Seitz
Expires: January 9, 2020 RISE Expires: September 3, 2020 Combitech
G. Selander G. Selander
Ericsson AB Ericsson AB
M. Gunnarsson M. Gunnarsson
RISE SICS AB RISE
July 8, 2019 March 2, 2020
OSCORE profile of the Authentication and Authorization for Constrained OSCORE profile of the Authentication and Authorization for Constrained
Environments Framework Environments Framework
draft-ietf-ace-oscore-profile-08 draft-ietf-ace-oscore-profile-09
Abstract Abstract
This memo specifies a profile for the Authentication and This memo specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework. It Authorization for Constrained Environments (ACE) framework. It
utilizes Object Security for Constrained RESTful Environments utilizes Object Security for Constrained RESTful Environments
(OSCORE) to provide communication security, server authentication, (OSCORE) to provide communication security, server authentication,
and proof-of-possession for a key owned by the client and bound to an and proof-of-possession for a key owned by the client and bound to an
OAuth 2.0 access token. OAuth 2.0 access token.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2020. This Internet-Draft will expire on September 3, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
3. Client-AS Communication . . . . . . . . . . . . . . . . . . . 5 3. Client-AS Communication . . . . . . . . . . . . . . . . . . . 6
3.1. C-to-AS: POST to token endpoint . . . . . . . . . . . . . 6 3.1. C-to-AS: POST to token endpoint . . . . . . . . . . . . . 6
3.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . . . 7 3.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . . . 8
3.2.1. OSCORE_Security_Context Object . . . . . . . . . . . 12 3.2.1. OSCORE_Security_Context Object . . . . . . . . . . . 13
4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 15 4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 16
4.1. C-to-RS: POST to authz-info endpoint . . . . . . . . . . 16 4.1. C-to-RS: POST to authz-info endpoint . . . . . . . . . . 17
4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 17 4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 18
4.3. OSCORE Setup . . . . . . . . . . . . . . . . . . . . . . 18 4.3. OSCORE Setup . . . . . . . . . . . . . . . . . . . . . . 19
4.4. Access rights verification . . . . . . . . . . . . . . . 20 4.4. Access rights verification . . . . . . . . . . . . . . . 21
5. Secure Communication with AS . . . . . . . . . . . . . . . . 20 5. Secure Communication with AS . . . . . . . . . . . . . . . . 21
6. Discarding the Security Context . . . . . . . . . . . . . . . 20 6. Discarding the Security Context . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9.1. ACE OAuth Profile Registry . . . . . . . . . . . . . . . 22 9.1. ACE OAuth Profile Registry . . . . . . . . . . . . . . . 24
9.2. OSCORE Security Context Parameters Registry . . . . . . . 23 9.2. OSCORE Security Context Parameters Registry . . . . . . . 24
9.3. CWT Confirmation Methods Registry . . . . . . . . . . . . 23 9.3. CWT Confirmation Methods Registry . . . . . . . . . . . . 25
9.4. JWT Confirmation Methods Registry . . . . . . . . . . . . 24 9.4. JWT Confirmation Methods Registry . . . . . . . . . . . . 25
9.5. Expert Review Instructions . . . . . . . . . . . . . . . 24 9.5. Expert Review Instructions . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . 26 10.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 26 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 28
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
This memo specifies a profile of the ACE framework This memo specifies a profile of the ACE framework
[I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource [I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource
server use CoAP [RFC7252] to communicate. The client uses an access server use CoAP [RFC7252] to communicate. The client uses an access
token, bound to a key (the proof-of-possession key) to authorize its token, bound to a key (the proof-of-possession key) to authorize its
access to the resource server. In order to provide communication access to the resource server. Note that this profile uses a
security, proof of possession, and server authentication they use symmetric-crypto-based scheme, where the symmetric secret is used as
Object Security for Constrained RESTful Environments (OSCORE) input material for keying material derivation. In order to provide
[I-D.ietf-core-object-security]. communication security, proof of possession, and server
authentication the client and resource server use Object Security for
Constrained RESTful Environments (OSCORE) [RFC8613]. Note that the
proof of possession is not done by a dedicated protocol element, but
rather occurs implicitly, based on knowledge of the security keying
material.
OSCORE specifies how to use CBOR Object Signing and Encryption (COSE) OSCORE specifies how to use CBOR Object Signing and Encryption (COSE)
[RFC8152] to secure CoAP messages. Note that OSCORE can be used to [RFC8152] to secure CoAP messages. Note that OSCORE can be used to
secure CoAP messages, as well as HTTP and combinations of HTTP and secure CoAP messages, as well as HTTP and combinations of HTTP and
CoAP; a profile of ACE similar to the one described in this document, CoAP; a profile of ACE similar to the one described in this document,
with the difference of using HTTP instead of CoAP as communication with the difference of using HTTP instead of CoAP as communication
protocol, could be specified analogously to this one. protocol, could be specified analogously to this one.
1.1. Terminology 1.1. Terminology
skipping to change at page 3, line 46 skipping to change at page 3, line 50
Note that the term "endpoint" is used here, as in Note that the term "endpoint" is used here, as in
[I-D.ietf-ace-oauth-authz], following its OAuth definition, which is [I-D.ietf-ace-oauth-authz], following its OAuth definition, which is
to denote resources such as token and introspect at the AS and authz- to denote resources such as token and introspect at the AS and authz-
info at the RS. The CoAP [RFC7252] definition, which is "An entity info at the RS. The CoAP [RFC7252] definition, which is "An entity
participating in the CoAP protocol" is not used in this memo. participating in the CoAP protocol" is not used in this memo.
2. Protocol Overview 2. Protocol Overview
This section gives an overview on how to use the ACE Framework This section gives an overview on how to use the ACE Framework
[I-D.ietf-ace-oauth-authz] to secure the communication between a [I-D.ietf-ace-oauth-authz] to secure the communication between a
client and a resource server using OSCORE client and a resource server using OSCORE [RFC8613]. The parameters
[I-D.ietf-core-object-security]. The parameters needed by the client needed by the client to negotiate the use of this profile with the
to negotiate the use of this profile with the authorization server, authorization server, as well as OSCORE setup process, are described
as well as OSCORE setup process, are described in detail in the in detail in the following sections.
following sections.
The RS maintains a collection of OSCORE Security Contexts with
associated authorization information for all the clients that it is
communicating with. The authorization information is maintained as
policy that's used as input to processing requests from those
clients.
This profile requires a client to retrieve an access token from the This profile requires a client to retrieve an access token from the
AS for the resource it wants to access on a RS, using the token AS for the resource it wants to access on a RS, using the token
endpoint, as specified in section 5.6 of [I-D.ietf-ace-oauth-authz]. endpoint, as specified in section 5.6 of [I-D.ietf-ace-oauth-authz].
To determine the AS in charge of a resource hosted at the RS, the To determine the AS in charge of a resource hosted at the RS, the
client C MAY send an initial Unauthorized Resource Request message to client C MAY send an initial Unauthorized Resource Request message to
the RS. The RS then denies the request and sends the address of its the RS. The RS then denies the request and sends the address of its
AS back to the client C as specified in section 5.1 of AS back to the client C as specified in section 5.1 of
[I-D.ietf-ace-oauth-authz]. The access token request and response [I-D.ietf-ace-oauth-authz]. The access token request and response
MUST be confidentiality-protected and ensure authenticity. This MUST be confidentiality-protected and ensure authenticity. This
profile RECOMMENDS the use of OSCORE between client and AS, but TLS profile RECOMMENDS the use of OSCORE between client and AS, but other
or DTLS MAY be used additionally or instead. protocols (such as TLS or DTLS) can be used as well.
Once the client has retrieved the access token, it generates a nonce Once the client has retrieved the access token, it generates a nonce
N1 and posts both the token and N1 to the RS using the authz-info N1 and posts both the token and N1 to the RS using the authz-info
endpoint and mechanisms specified in section 5.8 of endpoint and mechanisms specified in section 5.8 of
[I-D.ietf-ace-oauth-authz] and Content-Format = application/ace+cbor. [I-D.ietf-ace-oauth-authz] and Content-Format = application/ace+cbor.
Note that, as specified in the ACE framework, the authz-info endpoint
is not a protected resource, so there is no cryptographic protection
to this request.
If the access token is valid, the RS replies to this request with a If the access token is valid, the RS replies to this request with a
2.01 (Created) response with Content-Format = application/ace+cbor, 2.01 (Created) response with Content-Format = application/ace+cbor,
which contains a nonce N2 in a CBOR map. Moreover, the server which contains a nonce N2 in a CBOR map. Moreover, the server
concatenates N1 with N2 and appends the result to the Master Salt in concatenates the input salt, N1, and N2 to obtain the Master Salt of
the Security Context (see section 3 of the OSCORE Security Context (see section 3 of [RFC8613]). The RS
[I-D.ietf-core-object-security]). The RS then derives the complete then derives the complete Security Context associated with the
Security Context associated with the received token from it plus the received token from it plus the parameters received in the access
parameters received in the AS, following section 3.2 of token from the AS, following section 3.2 of [RFC8613].
[I-D.ietf-core-object-security].
After receiving the nonce N2, the client concatenates it with N1 and After receiving the nonce N2, the client concatenates the input salt,
appends the result to the Master Salt in its Security Context (see N1 and N2 to obtain the Master Salt of the OSCORE Security Context
section 3 of [I-D.ietf-core-object-security]). The client then (see section 3 of [RFC8613]). The client then derives the complete
derives the complete Security Context from the nonces plus the Security Context from the nonces plus the parameters received from
parameters received from the AS. the AS.
Finally, the client sends a request protected with OSCORE to the RS. Finally, the client sends a request protected with OSCORE to the RS.
If the request verifies, then this Security Context is stored in the If the request verifies, the server stores the complete Security
server, and used in the response, and in further communications with Context state that is ready for use in protecting messages, and uses
the client, until token expiration. This Security Context is it in the response, and in further communications with the client,
discarded if the same token is re-used to successfully derive a new until token expiration. This Security Context is discarded when a
Security Context. token (whether the same or different) is used to successfully derive
a new Security Context for that client.
The use of random nonces during the exchange prevents the reuse of The use of random nonces during the exchange prevents the reuse of an
AEAD nonces and keys with different messages, in case of re- AEAD nonces/key pair for two different messages. This situation
derivation of the Security Context both for Clients and Resource might occur when client and RS derive a new Security Context from an
Servers from an old non-expired access token, e.g. in case of re-boot existing (non-expired) access token, as might occur when either party
of either the client or RS. In fact, by using random nonces as part has just rebooted. Instead, by using random nonces as part of the
of the Master Salt, the request to the authz-info endpoint posting Master Salt, the request to the authz-info endpoint posting the same
the same token results in a different Security Context, since Master token results in a different Security Context, by OSCORE
Secret, Sender ID and Recipient ID are the same but Master Salt is construction, since even though the Master Secret, Sender ID and
different. Therefore, the main requirement for the nonces is that Recipient ID are the same, the Master Salt is different (see
they have a good amount of randomness. If random nonces were not Section 3.2.1 of [RFC8613]). Therefore, the main requirement for the
used, a node re-using a non-expired old token would be susceptible to nonces is that they have a good amount of randomness. If random
on-path attackers provoking the creation of OSCORE messages using old nonces were not used, a node re-using a non-expired old token would
AEAD keys and nonces. be susceptible to on-path attackers provoking the creation of OSCORE
messages using old AEAD keys and nonces.
After the whole message exchange has taken place, the client can
contact the AS to request an update of its access rights, sending a
similar request to the token endpoint that also includes an
identifier so that the AS can find the correct OSCORE security
material it has previously shared with the Client. This specific
identifier, which [I-D.ietf-ace-oauth-authz] encodes as a bstr, is
formatted to include two OSCORE identifiers, namely ID context and
client ID, that are necessary to determine the correct OSCORE
Security Context.
An overview of the profile flow for the OSCORE profile is given in An overview of the profile flow for the OSCORE profile is given in
Figure 1. Figure 1.
C RS AS C RS AS
| [-- Resource Request --->] | | | [-- Resource Request --->] | |
| | | | | |
| [<---- AS Request ------] | | | [<---- AS Request ------] | |
| Creation Hints | | | Creation Hints | |
| | | | | |
skipping to change at page 5, line 46 skipping to change at page 6, line 38
| | | | | |
| <--- OSCORE Response ----- | | | <--- OSCORE Response ----- | |
| ... | | | ... | |
Figure 1: Protocol Overview Figure 1: Protocol Overview
3. Client-AS Communication 3. Client-AS Communication
The following subsections describe the details of the POST request The following subsections describe the details of the POST request
and response to the token endpoint between client and AS. and response to the token endpoint between client and AS.
Section 3.2 of [I-D.ietf-core-object-security] defines how to derive Section 3.2 of [RFC8613] defines how to derive a Security Context
a Security Context based on a shared master secret and a set of other based on a shared master secret and a set of other parameters,
parameters, established between client and server, which the client established between client and server, which the client receives from
receives from the AS in this exchange. The proof-of-possession key the AS in this exchange. The proof-of-possession key (pop-key)
(pop-key) provisioned from the AS MUST be used as master secret in included in the response from the AS MUST be used as master secret in
OSCORE. OSCORE.
3.1. C-to-AS: POST to token endpoint 3.1. C-to-AS: POST to token endpoint
The client-to-AS request is specified in Section 5.6.1 of The client-to-AS request is specified in Section 5.6.1 of
[I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
The client MUST send this POST request to the token endpoint over a The client must send this POST request to the token endpoint over a
secure channel that guarantees authentication, message integrity and secure channel that guarantees authentication, message integrity and
confidentiality (see Section 5). confidentiality (see Section 5).
An example of such a request, in CBOR diagnostic notation without the An example of such a request, with payload in CBOR diagnostic
tag and value abbreviations is reported in Figure 2 notation without the tag and value abbreviations is reported in
Figure 2
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "as.example.com" Uri-Host: "as.example.com"
Uri-Path: "token" Uri-Path: "token"
Content-Format: "application/ace+cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
{ {
"req_aud" : "tempSensor4711", "req_aud" : "tempSensor4711",
"scope" : "read" "scope" : "read"
} }
Figure 2: Example C-to-AS POST /token request for an access token Figure 2: Example C-to-AS POST /token request for an access token
bound to a symmetric key. bound to a symmetric key.
If the client wants to update its access rights without changing an If the client wants to update its access rights without changing an
existing OSCORE Security Context, it MUST include in its POST request existing OSCORE Security Context, it MUST include in its POST request
to the token endpoint a req_cnf object. The req_cnf MUST include a to the token endpoint a req_cnf object. The req_cnf MUST include a
kid field carrying a CBOR array object containing the client's kid field carrying a bstr-wrapped CBOR array object containing the
identifier (assigned in section Section 3.2) and optionally the client's identifier (assigned as discussed in Section 3.2) and
context identifier (if assigned in section Section 3.2). The CBOR optionally the context identifier (if assigned as discussed in
array is defined in Figure 3, and follows the notation of [RFC8610]. Section 3.2). The CBOR array is defined in Figure 3, and follows the
These identifiers can be used by the AS to determine the shared notation of [RFC8610]. These identifiers, together with other
secret to construct the proof-of-possession token and therefore MUST information such as audience, can be used by the AS to determine the
identify a symmetric key that was previously generated by the AS as a shared secret bound to the proof-of-possession token and therefore
shared secret for the communication between the client and the RS. MUST identify a symmetric key that was previously generated by the AS
The AS MUST verify that the received value identifies a proof-of- as a shared secret for the communication between the client and the
possession key and token that have previously been issued to the RS. The AS MUST verify that the received value identifies a proof-
requesting client. If that is not the case, the Client-to-AS request of-possession key that has previously been issued to the requesting
MUST be declined with the error code 'invalid_request' as defined in client. If that is not the case, the Client-to-AS request MUST be
declined with the error code 'invalid_request' as defined in
Section 5.6.3 of [I-D.ietf-ace-oauth-authz]. Section 5.6.3 of [I-D.ietf-ace-oauth-authz].
kid = [ kid_arr = [
clientId, clientId,
?IdContext ?IdContext
] ]
kid = bstr .cbor kid_arr
Figure 3: CDDL Notation of kid for Update of Access Rights Figure 3: CDDL Notation of kid for Update of Access Rights
An example of such a request, in CBOR diagnostic notation without the An example of such a request, with payload in CBOR diagnostic
tag and value abbreviations is reported in Figure 4 notation without the tag and value abbreviations is reported in
Figure 4
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "as.example.com" Uri-Host: "as.example.com"
Uri-Path: "token" Uri-Path: "token"
Content-Format: "application/ace+cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
{ {
"req_aud" : "tempSensor4711", "req_aud" : "tempSensor4711",
"scope" : "write", "scope" : "write",
"req_cnf" : { "req_cnf" : {
"kid" : ["myclient","contextid1"] "kid" : << ["myclient","contextid1"] >>
} }
Figure 4: Example C-to-AS POST /token request for updating rights to Figure 4: Example C-to-AS POST /token request for updating rights to
an access token bound to a symmetric key. an access token bound to a symmetric key.
3.2. AS-to-C: Access Token 3.2. AS-to-C: Access Token
After verifying the POST request to the token endpoint and that the After verifying the POST request to the token endpoint and that the
client is authorized to obtain an access token corresponding to its client is authorized to obtain an access token corresponding to its
access token request, the AS responds as defined in section 5.6.2 of access token request, the AS responds as defined in section 5.6.2 of
skipping to change at page 7, line 48 skipping to change at page 9, line 5
The AS can signal that the use of OSCORE is REQUIRED for a specific The AS can signal that the use of OSCORE is REQUIRED for a specific
access token by including the "profile" parameter with the value access token by including the "profile" parameter with the value
"coap_oscore" in the access token response. This means that the "coap_oscore" in the access token response. This means that the
client MUST use OSCORE towards all resource servers for which this client MUST use OSCORE towards all resource servers for which this
access token is valid, and follow Section 4.3 to derive the security access token is valid, and follow Section 4.3 to derive the security
context to run OSCORE. Usually it is assumed that constrained context to run OSCORE. Usually it is assumed that constrained
devices will be pre-configured with the necessary profile, so that devices will be pre-configured with the necessary profile, so that
this kind of profile negotiation can be omitted. this kind of profile negotiation can be omitted.
Moreover, the AS MUST provision the following data: Moreover, the AS MUST send the following data:
o a master secret o a master secret
o a server identifier o a server identifier
Additionally, the AS MAY provision the following data, in the same Additionally, the AS MAY send the following data, in the same
response. response.
o a client identifier o a client identifier
o a context identifier o a context identifier
o an AEAD algorithm o an AEAD algorithm
o an HKDF algorithm o an HKDF algorithm
o a salt o a salt
o a replay window type and size o the OSCORE version number
The OSCORE_Security_Context is a CBOR map object, defined in The OSCORE_Security_Context is a CBOR map object, defined in
Section 3.2.1. The master secret MUST be communicated as the 'ms' Section 3.2.1. This object is transported in the 'cnf' parameter of
field in the OSCORE_Security_Context in the 'cnf' parameter of the the access token response as defined in Section 3.2 of
access token response as defined in Section 3.2 of [I-D.ietf-ace-oauth-params], as value of a field named 'osc'
[I-D.ietf-ace-oauth-params]. The AEAD algorithm MAY be included as registered in Section 9.3 and Section 9.4. The master secret MUST be
communicated as the 'ms' field in the 'osc' field in the 'cnf'
parameter of the access token response as defined in Section 3.2 of
[I-D.ietf-ace-oauth-params]. The AEAD algorithm may be included as
the 'alg' parameter in the OSCORE_Security_Context; the HKDF the 'alg' parameter in the OSCORE_Security_Context; the HKDF
algorithm MAY be included as the 'hkdf' parameter of the algorithm may be included as the 'hkdf' parameter of the
OSCORE_Security_Context, a salt MAY be included as the 'salt' OSCORE_Security_Context, a salt may be included as the 'salt'
parameter of the OSCORE_Security_Context, and the replay window type parameter of the OSCORE_Security_Context, and the OSCORE version
and size MAY be included as the 'rpl' of the OSCORE_Security_Context, number may be included as the 'version' parameter of the
as defined in Section 3.2.1. OSCORE_Security_Context.
The same parameters MUST be included as metadata of the access token. The same parameters MUST be included as part of the access token.
This profile RECOMMENDS the use of CBOR web token (CWT) as specified This profile RECOMMENDS the use of CBOR web token (CWT) as specified
in [RFC8392]. If the token is a CWT, the same in [RFC8392]. If the token is a CWT, the same
OSCORE_Security_Context structure defined above MUST be placed in the OSCORE_Security_Context structure defined above MUST be placed in the
'cnf' claim of this token. 'osc' field of the 'cnf' claim of this token. The access token MUST
be encrypted, since it will be transferred from the client to the RS
over an unprotected channel.
The AS MUST also assign an identifier to the RS (serverId), MAY The AS MUST also assign an identifier to the RS (serverId), MAY
assign an identifier to the client (clientId), and MAY assign an assign an identifier to the client (clientId), and MAY assign an
identifier to the context (contextId). These identifiers are then identifier to the context (contextId). These identifiers are then
used as Sender ID, Recipient ID and ID Context in the OSCORE context used as Sender ID, Recipient ID and ID Context in the OSCORE context
as described in section 3.1 of [I-D.ietf-core-object-security]. The as described in section 3.1 of [RFC8613]. Applications need to
couple (client identifier, context identifier) MUST be unique in the consider that these identifiers are sent in the clear and may reveal
set of all clients on a single RS. Moreover, when assigned, information about the endpoints, as mentioned in section 12.8 of
serverId, clientId and contextId MUST be included in the [RFC8613]. The pair (client identifier, context identifier) MUST be
OSCORE_Security_Context, as defined in Section 3.2.1. unique in the set of all clients for a single RS. Moreover,
clientId, serverId and (when assigned) contextId MUST be included in
the OSCORE_Security_Context, as defined in Section 3.2.1.
We assume in this document that a resource is associated to one We assume in this document that a resource is associated to one
single AS, which makes it possible to assume unique identifiers for single AS, which makes it possible for the AS to enforce uniqueness
each client requesting a particular resource to a RS. If this is not of identifiers for each client requesting a particular resource to a
the case, collisions of identifiers may appear in the RS, in which RS. If this is not the case, collisions of identifiers may occur at
case the RS needs to have a mechanism in place to disambiguate the RS, in which case the RS needs to have a mechanism in place to
identifiers or mitigate their effect. disambiguate identifiers or mitigate the effect of the collisions.
Note that in Section 4.3 C sets the Sender ID of its Security Context Note that in Section 4.3 C sets the Sender ID of its Security Context
to the clientId value received and the Recipient ID to the serverId to the clientId value received and the Recipient ID to the serverId
value, and RS does the opposite. value, and RS does the opposite.
Figure 5 shows an example of such an AS response, in CBOR diagnostic Figure 5 shows an example of an AS response, with payload in CBOR
notation without the tag and value abbreviations. diagnostic notation without the tag and value abbreviations. The
access token has been truncated for readability.
Header: Created (Code=2.01) Header: Created (Code=2.01)
Content-Type: "application/ace+cbor" Content-Type: "application/ace+cbor"
Payload: Payload:
{ {
"access_token" : h'a5037674656d7053656e73 ...' "access_token" : h'a5037674656d7053656e73 ...
(remainder of access token omitted for brevity)', (remainder of access token (CWT) omitted for brevity)',
"profile" : "coap_oscore", "profile" : "coap_oscore",
"expires_in" : "3600", "expires_in" : "3600",
"cnf" : { "cnf" : {
"OSCORE_Security_Context" : { "osc" : {
"alg" : "AES-CCM-16-64-128", "alg" : "AES-CCM-16-64-128",
"clientId" : b64'qA', "clientId" : h'00',
"serverId" : b64'Qg', "serverId" : h'01',
"ms" : h'f9af838368e353e78888e1426bd94e6f' "ms" : h'f9af838368e353e78888e1426bd94e6f'
} }
} }
} }
Figure 5: Example AS-to-C Access Token response with OSCORE profile. Figure 5: Example AS-to-C Access Token response with OSCORE profile.
Figure 6 shows an example CWT, containing the necessary OSCORE Figure 6 shows an example CWT, containing the necessary OSCORE
parameters in the 'cnf' claim, in CBOR diagnostic notation without parameters in the 'cnf' claim, in CBOR diagnostic notation without
tag and value abbreviations. tag and value abbreviations.
{ {
"aud" : "tempSensorInLivingRoom", "aud" : "tempSensorInLivingRoom",
"iat" : "1360189224", "iat" : "1360189224",
"exp" : "1360289224", "exp" : "1360289224",
"scope" : "temperature_g firmware_p", "scope" : "temperature_g firmware_p",
"cnf" : { "cnf" : {
"OSCORE_Security_Context" : { "osc" : {
"alg" : "AES-CCM-16-64-128", "alg" : "AES-CCM-16-64-128",
"clientId" : h'636C69656E74', "clientId" : h'00',
"serverId" : h'736572766572', "serverId" : h'01',
"ms" : h'f9af838368e353e78888e1426bd94e6f' "ms" : h'f9af838368e353e78888e1426bd94e6f'
} }
} }
Figure 6: Example CWT with OSCORE parameters. Figure 6: Example CWT with OSCORE parameters.
The same CWT token as in Figure 6, using the value abbreviations The same CWT token as in Figure 6, using the value abbreviations
defined in [I-D.ietf-ace-oauth-authz] and defined in [I-D.ietf-ace-oauth-authz] and
[I-D.ietf-ace-cwt-proof-of-possession] and encoded in CBOR is shown [I-D.ietf-ace-cwt-proof-of-possession] and encoded in CBOR is shown
in Figure 7. in Figure 7.
skipping to change at page 11, line 41 skipping to change at page 12, line 41
50 # bytes(16) 50 # bytes(16)
F9AF838368E353E78888E1426BD94E6F F9AF838368E353E78888E1426BD94E6F
# "\xF9\xAF\x83\x83h\xE3S\xE7 # "\xF9\xAF\x83\x83h\xE3S\xE7
\x88\x88\xE1Bk\xD9No" \x88\x88\xE1Bk\xD9No"
Figure 7: Example CWT with OSCORE parameters. Figure 7: Example CWT with OSCORE parameters.
If the client has requested an update to its access rights using the If the client has requested an update to its access rights using the
same OSCORE Security Context, which is valid and authorized, the AS same OSCORE Security Context, which is valid and authorized, the AS
MUST omit the 'cnf' parameter in the response, and MUST carry the MUST omit the 'cnf' parameter in the response, and MUST carry the
client identifier and optionally the context identifier in the 'kid' client identifier and the context identifier (if it was set and
included in the initial access token response by the AS) in the 'kid'
field in the 'cnf' parameter of the token, with the same structure field in the 'cnf' parameter of the token, with the same structure
defined in Figure 3. These identifiers need to be provisioned, in defined in Figure 3. These identifiers need to be included in the
order for the RS to identify the previously generated Security response, in order for the RS to identify the previously generated
Context. Security Context.
Figure 8 shows an example of such an AS response, in CBOR diagnostic Figure 8 shows an example of such an AS response, with payload in
notation without the tag and value abbreviations. CBOR diagnostic notation without the tag and value abbreviations.
The access token has been truncated for readability.
Header: Created (Code=2.01) Header: Created (Code=2.01)
Content-Type: "application/ace+cbor" Content-Type: "application/ace+cbor"
Payload: Payload:
{ {
"access_token" : h'a5037674656d7053656e73 ...' "access_token" : h'a5037674656d7053656e73 ...
(remainder of access token omitted for brevity)', (remainder of access token (CWT) omitted for brevity)',
"profile" : "coap_oscore", "profile" : "coap_oscore",
"expires_in" : "3600" "expires_in" : "3600"
} }
Figure 8: Example AS-to-C Access Token response with OSCORE profile, Figure 8: Example AS-to-C Access Token response with OSCORE profile,
for update of access rights. for update of access rights.
Figure 9 shows an example CWT, containing the necessary OSCORE Figure 9 shows an example CWT, containing the necessary OSCORE
parameters in the 'cnf' claim for update of access rights, in CBOR parameters in the 'cnf' claim for update of access rights, in CBOR
diagnostic notation without tag and value abbreviations. diagnostic notation without tag and value abbreviations.
{ {
"aud" : "tempSensorInLivingRoom", "aud" : "tempSensorInLivingRoom",
"iat" : "1360189224", "iat" : "1360189224",
"exp" : "1360289224", "exp" : "1360289224",
"scope" : "temperature_h", "scope" : "temperature_h",
"cnf" : { "cnf" : {
"kid" : b64'qA' "kid" : h'43814100'
} }
} }
Figure 9: Example CWT with OSCORE parameters for update of access Figure 9: Example CWT with OSCORE parameters for update of access
rights. rights.
3.2.1. OSCORE_Security_Context Object 3.2.1. OSCORE_Security_Context Object
An OSCORE_Security_Context is an object that represents part or all An OSCORE_Security_Context is an object that represents part or all
of an OSCORE Security Context (Section 3.1 of of an OSCORE Security Context, i.e., the local set of information
[I-D.ietf-core-object-security]). The OSCORE_Security_Context object elements necessary to carry out the cryptographic operations in
can either be encoded as JSON object or as CBOR map. In both cases, OSCORE (Section 3.1 of [RFC8613]). In particular, the
the set of common parameters that can appear in an OSCORE_Security_Context object is defined to be serialized and
transported between nodes, as specified by this document, but can
also be used in this way by other specifications if needed. The
OSCORE_Security_Context object can either be encoded as a JSON object
or as a CBOR map. The set of common parameters that can appear in an
OSCORE_Security_Context object can be found in the IANA "OSCORE OSCORE_Security_Context object can be found in the IANA "OSCORE
Security Context Parameters" registry (Section Section 9.2) and is Security Context Parameters" registry (Section 9.2), defined for
defined below. All parameters are optional. Table 1 provides a extensibility, and is specified below. All parameters are optional.
summary of the OSCORE_Security_Context parameters defined in this Table 1 provides a summary of the OSCORE_Security_Context parameters
section. defined in this section.
+-----------+-------+----------------+--------------+---------------+ +-----------+-------+----------------+--------------+---------------+
| name | CBOR | CBOR type | registry | description | | name | CBOR | CBOR type | registry | description |
| | label | | | | | | label | | | |
+-----------+-------+----------------+--------------+---------------+ +-----------+-------+----------------+--------------+---------------+
| version | 0 | int | | OSCORE |
| | | | | Version |
| | | | | |
| ms | 1 | bstr | | OSCORE Master | | ms | 1 | bstr | | OSCORE Master |
| | | | | Secret value | | | | | | Secret value |
| | | | | | | | | | | |
| clientId | 2 | bstr | | OSCORE Sender | | clientId | 2 | bstr | | OSCORE Sender |
| | | | | ID value of | | | | | | ID value of |
| | | | | the client, | | | | | | the client, |
| | | | | OSCORE | | | | | | OSCORE |
| | | | | Recipient ID | | | | | | Recipient ID |
| | | | | value of the | | | | | | value of the |
| | | | | server | | | | | | server |
| | | | | | | | | | | |
| serverId | 3 | bstr | | OSCORE Sender | | serverId | 3 | bstr | | OSCORE Sender |
| | | | | ID value of | | | | | | ID value of |
| | | | | the server, | | | | | | the server, |
| | | | | OSCORE | | | | | | OSCORE |
| | | | | Recipient ID | | | | | | Recipient ID |
| | | | | value of the | | | | | | value of the |
| | | | | client | | | | | | client |
| | | | | | | | | | | |
| hkdf | 4 | bstr / int | COSE | OSCORE HKDF | | hkdf | 4 | tstr / int | COSE | OSCORE HKDF |
| | | | Algorithm | value | | | | | Algorithm | value |
| | | | Values | | | | | | Values | |
| | | | (HMAC-based) | | | | | | (HMAC-based) | |
| | | | | | | | | | | |
| alg | 5 | tstr / int | COSE | OSCORE AEAD | | alg | 5 | tstr / int | COSE | OSCORE AEAD |
| | | | Algorithm | Algorithm | | | | | Algorithm | Algorithm |
| | | | Values | value | | | | | Values | value |
| | | | (AEAD) | | | | | | (AEAD) | |
| | | | | | | | | | | |
| salt | 6 | bstr | | OSCORE Master | | salt | 6 | bstr | | OSCORE Master |
| | | | | Salt value | | | | | | Salt value |
| | | | | | | | | | | |
| contextId | 7 | bstr | | OSCORE ID | | contextId | 7 | bstr | | OSCORE ID |
| | | | | Context value | | | | | | Context value |
| | | | | |
| rpl | 8 | bstr / int | | OSCORE Replay |
| | | | | Window Type |
| | | | | and Size |
+-----------+-------+----------------+--------------+---------------+ +-----------+-------+----------------+--------------+---------------+
Table 1: OSCORE_Security_Context Parameters Table 1: OSCORE_Security_Context Parameters
version: This parameter identifies the OSCORE Version number, which
is an int. For more information about this field, see section 5.4
of [RFC8613]. In JSON, the "version" value is an integer. In
CBOR, the "version" type is int, and has label 0.
ms: This parameter identifies the OSCORE Master Secret value, which ms: This parameter identifies the OSCORE Master Secret value, which
is a byte string. For more information about this field, see is a byte string. For more information about this field, see
section 3.1 of [I-D.ietf-core-object-security]. In JSON, the "ms" section 3.1 of [RFC8613]. In JSON, the "ms" value is a Base64
value is a Base64 encoded byte string. In CBOR, the "ms" type is encoded byte string. In CBOR, the "ms" type is bstr, and has
bstr, and has label 1. label 1.
clientId: This parameter identifies a client identifier as a byte clientId: This parameter identifies a client identifier as a byte
string. This identifier is used as OSCORE Sender ID in the client string. This identifier is used as OSCORE Sender ID in the client
and OSCORE Recipient ID in the server. For more information about and OSCORE Recipient ID in the server. For more information about
this field, see section 3.1 of [I-D.ietf-core-object-security]. this field, see section 3.1 of [RFC8613]. In JSON, the "clientId"
In JSON, the "clientId" value is a Base64 encoded byte string. In value is a Base64 encoded byte string. In CBOR, the "clientId"
CBOR, the "clientId" type is bstr, and has label 2. type is bstr, and has label 2.
serverId: This parameter identifies a server identifier as a byte serverId: This parameter identifies a server identifier as a byte
string. This identifier is used as OSCORE Sender ID in the server string. This identifier is used as OSCORE Sender ID in the server
and OSCORE Recipient ID in the client. For more information about and OSCORE Recipient ID in the client. For more information about
this field, see section 3.1 of [I-D.ietf-core-object-security]. this field, see section 3.1 of [RFC8613]. In JSON, the "serverId"
In JSON, the "serverId" value is a Base64 encoded byte string. In value is a Base64 encoded byte string. In CBOR, the "serverId"
CBOR, the "serverId" type is bstr, and has label 3. type is bstr, and has label 3.
hkdf: This parameter identifies the OSCORE HKDF Algorithm. For more hkdf: This parameter identifies the OSCORE HKDF Algorithm. For more
information about this field, see section 3.1 of information about this field, see section 3.1 of [RFC8613]. The
[I-D.ietf-core-object-security]. The values used MUST be values used MUST be registered in the IANA "COSE Algorithms"
registered in the IANA "COSE Algorithms" registry and MUST be registry and MUST be HMAC-based HKDF algorithms. The value can
HMAC-based HKDF algorithms. The value can either be the integer either be the integer or the text string value of the HMAC-based
or the text string value of the HMAC-based HKDF algorithm in the HKDF algorithm in the "COSE Algorithms" registry. In JSON, the
"COSE Algorithms" registry. In JSON, the "hkdf" value is a case- "hkdf" value is a case-sensitive ASCII string or an integer. In
sensitive ASCII string or an integer. In CBOR, the "hkdf" type is CBOR, the "hkdf" type is tstr or int, and has label 4.
tstr or int, and has label 4.
alg: This parameter identifies the OSCORE AEAD Algorithm. For more alg: This parameter identifies the OSCORE AEAD Algorithm. For more
information about this field, see section 3.1 of information about this field, see section 3.1 of [RFC8613] The
[I-D.ietf-core-object-security] The values used MUST be registered values used MUST be registered in the IANA "COSE Algorithms"
in the IANA "COSE Algorithms" registry and MUST be AEAD registry and MUST be AEAD algorithms. The value can either be the
algorithms. The value can either be the integer or the text integer or the text string value of the HMAC-based HKDF algorithm
string value of the HMAC-based HKDF algorithm in the "COSE in the "COSE Algorithms" registry. In JSON, the "alg" value is a
Algorithms" registry. In JSON, the "alg" value is a case- case-sensitive ASCII string or an integer. In CBOR, the "alg"
sensitive ASCII string or an integer. In CBOR, the "alg" type is type is tstr or int, and has label 5.
tstr or int, and has label 5.
salt: This parameter identifies the OSCORE Master Salt value, which salt: This parameter identifies the OSCORE Master Salt value, which
is a byte string. For more information about this field, see is a byte string. For more information about this field, see
section 3.1 of [I-D.ietf-core-object-security]. In JSON, the section 3.1 of [RFC8613]. In JSON, the "salt" value is a Base64
"salt" value is a Base64 encoded byte string. In CBOR, the "salt" encoded byte string. In CBOR, the "salt" type is bstr, and has
type is bstr, and has label 6. label 6.
contextId: This parameter identifies the security context as a byte contextId: This parameter identifies the security context as a byte
string. This identifier is used as OSCORE ID Context. For more string. This identifier is used as OSCORE ID Context. For more
information about this field, see section 3.1 of information about this field, see section 3.1 of [RFC8613]. In
[I-D.ietf-core-object-security]. In JSON, the "contextID" value JSON, the "contextID" value is a Base64 encoded byte string. In
is a Base64 encoded byte string. In CBOR, the "contextID" type is CBOR, the "contextID" type is bstr, and has label 7.
bstr, and has label 7.
rpl: This parameter is used to carry the OSCORE value, encoded as a
bstr. This parameter identifies the OSCORE Replay Window Size and
Type value, which is a byte string. For more information about
this field, see section 3.1 of [I-D.ietf-core-object-security].
In JSON, the "rpl" value is a Base64 encoded byte string. In
CBOR, the "rpl" type is bstr, and has label 8.
An example of JSON OSCORE_Security_Context is given in Figure 10. An example of JSON OSCORE_Security_Context is given in Figure 10.
"OSCORE_Security_Context" : { "osc" : {
"alg" : "AES-CCM-16-64-128", "alg" : "AES-CCM-16-64-128",
"clientId" : b64'qA', "clientId" : b64'AA',
"serverId" : b64'Qg', "serverId" : b64'AQ',
"ms" : b64'+a+Dg2jjU+eIiOFCa9lObw' "ms" : b64'+a+Dg2jjU+eIiOFCa9lObw'
} }
Figure 10: Example JSON OSCORE_Security_Context object Figure 10: Example JSON OSCORE_Security_Context object
The CDDL grammar describing the CBOR OSCORE_Security_Context object The CDDL grammar describing the CBOR OSCORE_Security_Context object
is: is:
OSCORE_Security_Context = { OSCORE_Security_Context = {
? 0 => int, ; version
? 1 => bstr, ; ms ? 1 => bstr, ; ms
? 2 => bstr, ; clientId ? 2 => bstr, ; clientId
? 3 => bstr, ; serverId ? 3 => bstr, ; serverId
? 4 => tstr / int, ; hkdf ? 4 => tstr / int, ; hkdf
? 5 => tstr / int, ; alg ? 5 => tstr / int, ; alg
? 6 => bstr, ; salt ? 6 => bstr, ; salt
? 7 => bstr, ; contextId ? 7 => bstr, ; contextId
? 8 => bstr / tstr, ; rpl
* int / tstr => any * int / tstr => any
} }
4. Client-RS Communication 4. Client-RS Communication
The following subsections describe the details of the POST request The following subsections describe the details of the POST request
and response to the authz-info endpoint between client and RS. The and response to the authz-info endpoint between client and RS. The
client generates a nonce N1 and posts it together with the token that client generates a nonce N1, and posts it together with the token
includes the materials provisioned by the AS to the RS. The RS then that includes the materials (e.g., OSCORE parameters) received from
derives a nonce N2 and use Section 3.2 of the AS to the RS. The RS then generates a nonce N2, and use
[I-D.ietf-core-object-security] to derive a security context based on Section 3.2 of [RFC8613] to derive a security context based on a
a shared master secret and the two nonces, established between client shared master secret and the two nonces, established between client
and server. and server. The nonces are encoded as CBOR bstr if CBOR is used, and
as Base64 string if JSON is used. This security context is used to
protect all future communication between client and RS using OSCORE,
as long as the access token is valid.
Note that the proof-of-possession required to bind the access token Note that the RS and client authenticates themselves by generating
to the client is implicitly performed by generating the shared OSCORE the shared OSCORE Security Context using the pop-key as master
Security Context using the pop-key as master secret, for both client secret. An attacker posting a valid token to the RS will not be able
and RS. An attacker using a stolen token will not be able to to generate a valid OSCORE context and thus not be able to prove
generate a valid OSCORE context and thus not be able to prove
possession of the pop-key. possession of the pop-key.
4.1. C-to-RS: POST to authz-info endpoint 4.1. C-to-RS: POST to authz-info endpoint
The client MUST generate a nonce N1 very unlikely to have been The client MUST generate a nonce value very unlikely to have been
previously used with the same input keying material. This profile previously used with the same input keying material. This profile
RECOMMENDS to use a 64-bit long random number as nonce. The client RECOMMENDS to use a 64-bit long random number as nonce's value. The
MUST store this nonce as long as the response from the RS is not client MUST store the nonce N1 as long as the response from the RS is
received and the access token related to it is still valid. The not received and the access token related to it is still valid. The
client MUST use CoAP and the Authorization Information resource as client MUST use CoAP and the Authorization Information resource as
described in section 5.8.1 of [I-D.ietf-ace-oauth-authz] to transport described in section 5.8.1 of [I-D.ietf-ace-oauth-authz] to transport
the token and N1 to the RS. the token and N1 to the RS.
Note that the use of the payload and the Content-Format is different Note that the use of the payload and the Content-Format is different
from what described in section 5.8.1 of [I-D.ietf-ace-oauth-authz], from what described in section 5.8.1 of [I-D.ietf-ace-oauth-authz],
which only transports the token without any CBOR wrapping. In this which only transports the token without any CBOR wrapping. In this
profile, the client MUST wrap the token and N1 in a CBOR map. The profile, the client MUST wrap the token and N1 in a CBOR map. The
client MUST use the Content-Format "application/ace+cbor" defined in client MUST use the Content-Format "application/ace+cbor" defined in
section 8.14 of [I-D.ietf-ace-oauth-authz]. The client MUST include section 8.14 of [I-D.ietf-ace-oauth-authz]. The client MUST include
the access token using the correct CBOR label (e.g., "cwt" for CWT, the access token using the correct CBOR label (e.g., "cwt" for CWT,
"jwt" for JWT) and N1 using the 'cnonce' parameter defined in section "jwt" for JWT) and N1 using the 'cnonce' parameter defined in section
5.1.2 of [I-D.ietf-ace-oauth-authz]. 5.1.2 of [I-D.ietf-ace-oauth-authz].
The authz-info endpoint is not protected, nor are the responses from The authz-info endpoint is not protected, nor are the responses from
this resource. this resource.
The access token MUST be encrypted, since it is transferred from the The access token MUST be encrypted, since it is transferred from the
client to the RS over an unprotected channel. client to the RS over an unprotected channel.
Note that a client may be required to re-POST the access token, since Note that a client may be required to re-POST the access token in
an RS may delete a stored access token, due to lack of memory. order to complete a request, since an RS may delete a stored access
token at any time, for example due to all storage space being
consumed. This situation is detected by the client when it receives
an AS Request Creation Hints response.
Figure 11 shows an example of the request sent from the client to the Figure 11 shows an example of the request sent from the client to the
RS, in CBOR diagnostic notation without the tag and value RS, with payload in CBOR diagnostic notation without the tag and
abbreviations. value abbreviations. The access token has been truncated for
readability.
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "rs.example.com" Uri-Host: "rs.example.com"
Uri-Path: "authz-info" Uri-Path: "authz-info"
Content-Format: "application/ace+cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
{ {
"access_token": h'a5037674656d7053656e73 ...' "access_token": h'a5037674656d7053656e73 ...
(remainder of access token omitted for brevity)', (remainder of access token (CWT) omitted for brevity)',
"cnonce": h'018a278f7faab55a' "cnonce": h'018a278f7faab55a'
} }
Figure 11: Example C-to-RS POST /authz-info request using CWT Figure 11: Example C-to-RS POST /authz-info request using CWT
4.2. RS-to-C: 2.01 (Created) 4.2. RS-to-C: 2.01 (Created)
The RS MUST follow the procedures defined in section 5.8.1 of The RS MUST follow the procedures defined in section 5.8.1 of
[I-D.ietf-ace-oauth-authz]: the RS MUST verify the validity of the [I-D.ietf-ace-oauth-authz]: the RS must verify the validity of the
token. If the token is valid, the RS MUST respond to the POST token. If the token is valid, the RS must respond to the POST
request with 2.01 (Created). If the token is valid but is associated request with 2.01 (Created). If the token is valid but is associated
to claims that the RS cannot process (e.g., an unknown scope), or if to claims that the RS cannot process (e.g., an unknown scope), or if
any of the expected parameters in the OSCORE_Security_Context is any of the expected parameters in the 'osc' is missing (e.g., any of
missing (e.g. any of the mandatory parameters from the AS), or if any the mandatory parameters from the AS), or if any parameters received
parameters received in the OSCORE_Security_Context is unrecognized, in the 'osc' is unrecognized, the RS must respond with an error
the RS MUST respond with an error response code equivalent to the response code equivalent to the CoAP code 4.00 (Bad Request). In the
CoAP code 4.00 (Bad Request). In the latter two cases, the RS MAY latter two cases, the RS may provide additional information in the
provide additional information in the error response, in order to error response, in order to clarify what went wrong. The RS may make
clarify what went wrong. The RS MAY make an introspection request to an introspection request to validate the token before responding to
validate the token before responding to the POST request to the the POST request to the authz-info endpoint.
authz-info endpoint.
Additionally, the RS MUST generate a nonce N2 very unlikely to have Additionally, the RS MUST generate a nonce N2 very unlikely to have
been previously used with the same input keying material, and send it been previously used with the same input keying material, and send it
within the 2.01 (Created) response. The payload of the 2.01 within the 2.01 (Created) response. The payload of the 2.01
(Created) response MUST be a CBOR map containing the 'cnonce' (Created) response MUST be a CBOR map containing the 'cnonce'
parameter defined in section 5.1.2 of [I-D.ietf-ace-oauth-authz], set parameter defined in section 5.1.2 of [I-D.ietf-ace-oauth-authz], set
to N2. This profile RECOMMENDS to use a 64-bit long random number as to N2. This profile RECOMMENDS to use a 64-bit long random number as
nonce. Moreover, if the OSCORE_Security_Context in the token did not nonce's value. Moreover, if the 'osc' field in the token did not
contain a 'clientId' parameter, the RS MUST generate an identifier, contain a 'clientId' parameter, the RS MUST generate an identifier,
unique in the set of all its existing client identifiers, and send it unique in the set of all its existing client identifiers, and send it
in a 'clientId' parameter in the CBOR map as a CBOR bstr. The RS MAY in a 'clientId' parameter in the CBOR map as a CBOR bstr. The RS MAY
generate and send a 'ClientId' identifier even though the generate and send a 'ClientId' identifier even though the 'osc' field
OSCORE_Security_Context contained such a parameter, in order to contained such a parameter, in order to guarantee the uniqueness of
guarantee the uniqueness of the client identifier. The RS MUST use the client identifier. The RS MUST use the Content-Format
the Content-Format "application/ace+cbor" defined in section 8.14 of "application/ace+cbor" defined in section 8.14 of
[I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
Figure 12 shows an example of the response sent from the RS to the Figure 12 shows an example of the response sent from the RS to the
client, in CBOR diagnostic notation without the tag and value client, with payload in CBOR diagnostic notation without the tag and
abbreviations. value abbreviations.
Header: Created (Code=2.01) Header: Created (Code=2.01)
Content-Format: "application/ace+cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
{ {
"cnonce": h'25a8991cd700ac01' "cnonce": h'25a8991cd700ac01'
} }
Figure 12: Example RS-to-C 2.01 (Created) response Figure 12: Example RS-to-C 2.01 (Created) response
When receiving an updated access token with updated authorization As specified in section 5.8.1 of [I-D.ietf-ace-oauth-authz], when
information from the client (see section Section 3.1), it is receiving an updated access token with updated authorization
RECOMMENDED that the RS overwrites the previous token, that is only information from the client (see Section 3.1), it is recommended that
the latest authorization information in the token received by the RS the RS overwrites the previous token, that is only the latest
is valid. This simplifies for the RS to keep track of authorization authorization information in the token received by the RS is valid.
information for a given client. This simplifies for the RS to keep track of authorization information
for a given client.
As specified in section 5.8.3 of [I-D.ietf-ace-oauth-authz], the RS As specified in section 5.8.3 of [I-D.ietf-ace-oauth-authz], the RS
MUST notify the client with an error response with code 4.01 must notify the client with an error response with code 4.01
(Unauthorized) for any long running request before terminating the (Unauthorized) for any long running request before terminating the
session, when the access token expires. session, when the access token expires.
4.3. OSCORE Setup 4.3. OSCORE Setup
Once receiving the 2.01 (Created) response from the RS, following the Once receiving the 2.01 (Created) response from the RS, following the
POST request to authz-info endpoint, the client MUST extract the POST request to authz-info endpoint, the client MUST extract the CBOR
nonce N2 from the 'cnonce' parameter and the client identifier from bstr nonce N2 from the 'cnonce' parameter and the client identifier
the 'clientId' in the CBOR map in the payload of the response. Then, from the 'clientId' in the CBOR map in the payload of the response.
the client MUST set the Master Salt of the Security Context created Then, the client MUST set the Master Salt of the Security Context
to communicate with the RS to the concatenation of salt, N1, and N2, created to communicate with the RS to the concatenation of salt, N1,
in this order: Master Salt = salt | N1 | N2, where | denotes byte and N2, in this order: Master Salt = salt | N1 | N2, where | denotes
string concatenation, and where salt was received from the AS in byte string concatenation, where salt was received from the AS in
Section 3.2. The client MUST set the Master Secret and Recipient ID Section 3.2, and where N1 and N2 are the two nonces encoded as CBOR
from the parameters received from the AS in Section 3.2. The client bstr. The client MUST set the Master Secret and Recipient ID from
MUST set the AEAD Algorithm, ID Context, HKDF, and Replay Window from the parameters received from the AS in Section 3.2. The client MUST
the parameters received from the AS in Section 3.2, if present. In set the AEAD Algorithm, ID Context, HKDF, and OSCORE Version from the
case these parameters are omitted, the default values are used as parameters received from the AS in Section 3.2, if present. In case
described in section 3.2 of [I-D.ietf-core-object-security]. The these parameters are omitted, the default values are used as
client MUST set the Sender ID from the 'clientId in the 2.01 described in sections 3.2 and 5.4 of [RFC8613]. The client MUST set
(Created) response, if present; otherwise, the client MUST set the the Sender ID from the 'clientId in the 2.01 (Created) response, if
Sender ID from the parameters received from the AS in Section 3.2. present; otherwise, the client MUST set the Sender ID from the
After that, the client MUST derive the complete Security Context parameters received from the AS in Section 3.2. After that, the
following section 3.2.1 of [I-D.ietf-core-object-security]. From client MUST derive the complete Security Context following section
this point on, the client MUST use this Security Context to 3.2.1 of [RFC8613]. From this point on, the client MUST use this
communicate with the RS when accessing the resources as specified by Security Context to communicate with the RS when accessing the
the authorization information. resources as specified by the authorization information.
If any of the expected parameters is missing (e.g. any of the If any of the expected parameters is missing (e.g., any of the
mandatory parameters from the AS, or the 'clientId', either received mandatory parameters from the AS, or the 'clientId', either received
from the AS or in the 2.01 (Created) response from the RS), the from the AS or in the 2.01 (Created) response from the RS), the
client MUST stop the exchange, and MUST NOT derive the Security client MUST stop the exchange, and MUST NOT derive the Security
Context. The client MAY restart the exchange, to get the correct Context. The client MAY restart the exchange, to get the correct
security material. security material.
The client then uses this Security Context to send requests to RS The client then uses this Security Context to send requests to RS
using OSCORE. using OSCORE.
After sending the 2.01 (Created) response, the RS MUST set the Master After sending the 2.01 (Created) response, the RS MUST set the Master
Salt of the Security Context created to communicate with the client Salt of the Security Context created to communicate with the client
to the concatenation of salt, N1, and N2, in this order: Master Salt to the concatenation of salt, N1, and N2, in this order: Master Salt
= salt | N1 | N2, where | denotes byte string concatenation, and = salt | N1 | N2, where | denotes byte string concatenation, where
where salt was received from the AS in Section 4.2. The RS MUST set salt was received from the AS in Section 4.2, and where N1 and N2 are
the Master Secret, Sender ID and Recipient ID from the parameters, the two nonces encoded as CBOR bstr. The RS MUST set the Master
received from the client in the access token in Section 4.1 after Secret, Sender ID and Recipient ID from the parameters, received from
validation of the token as specified in Section 4.2. The RS MUST set the AS and forwarded by the client in the access token in Section 4.1
the AEAD Algorithm, ID Context, HKDF, and Replay Window from the after validation of the token as specified in Section 4.2. The RS
parameters received from the client in the access token in MUST set the AEAD Algorithm, ID Context, HKDF, and OSCORE Version
Section 4.1 after validation of the token as specified in from the parameters received from the AS and forwarded by the client
Section 4.2, if present. In case these parameters are omitted, the in the access token in Section 4.1 after validation of the token as
default values are used as described in section 3.2 of specified in Section 4.2, if present. In case these parameters are
[I-D.ietf-core-object-security]. After that, the RS MUST derive the omitted, the default values are used as described in sections 3.2 and
complete Security Context following section 3.2.1 of 5.4 of [RFC8613]. After that, the RS MUST derive the complete
[I-D.ietf-core-object-security], and MUST associate this Security Security Context following section 3.2.1 of [RFC8613], and MUST
Context with the authorization information from the access token. associate this Security Context with the authorization information
from the access token.
The RS then uses this Security Context to verify the request and send The RS then uses this Security Context to verify requests and send
responses to C using OSCORE. If OSCORE verification fails, error responses to C using OSCORE. If OSCORE verification fails, error
responses are used, as specified in section 8 of responses are used, as specified in section 8 of [RFC8613].
[I-D.ietf-core-object-security]. Additionally, if OSCORE Additionally, if OSCORE verification succeeds, the verification of
verification succeeds, the verification of access rights is performed access rights is performed as described in section Section 4.4. The
as described in section Section 4.4. The RS MUST NOT use the RS MUST NOT use the Security Context after the related token has
Security Context after the related token has expired, and MUST expired, and MUST respond with a unprotected 4.01 (Unauthorized)
respond with a unprotected 4.01 (Unauthorized) error message. error message to requests received that correspond to a Security
Context with an expired token.
If the exchange was an update of access rights, i.e. a new Security If the exchange was an update of access rights, i.e., a new Security
Context was derived from a client that already had a Security Context Context was derived from a client that already had a Security Context
in place, the is RECOMMENDED to delete the old Security Context after in place, the is RECOMMENDED to delete the old Security Context after
OSCORE verification and verification of access rights succeed. The OSCORE verification and verification of access rights succeed. The
RS MUST delete the Security Context if it deletes the access token RS MUST delete the Security Context if it deletes the access token
associated to it. associated to it.
4.4. Access rights verification 4.4. Access rights verification
The RS MUST follow the procedures defined in section 5.8.2 of The RS MUST follow the procedures defined in section 5.8.2 of
[I-D.ietf-ace-oauth-authz]: if an RS receives an OSCORE-protected [I-D.ietf-ace-oauth-authz]: if an RS receives an OSCORE-protected
request from a client, then the RS processes it according to request from a client, then the RS processes it according to
[I-D.ietf-core-object-security]. If OSCORE verification succeeds, [RFC8613]. If OSCORE verification succeeds, and the target resource
and the target resource requires authorization, the RS retrieves the requires authorization, the RS retrieves the authorization
authorization information from the access token associated to the information using the access token associated to the Security
Security Context. The RS then MUST verify that the authorization Context. The RS then must verify that the authorization information
information covers the resource and the action requested. covers the resource and the action requested.
The response code MUST be 4.01 (Unauthorized) in case the client has The response code must be 4.01 (Unauthorized) in case the client has
not used the Security Context associated with the access token, or if a valid token associated with that Security Context, but the Security
RS has no valid access token for the client. If RS has an access Context has not been used before, as the proof-of-possession in this
token for the client but not for the resource that was requested, RS profile is performed by both parties verifying that they have
MUST reject the request with a 4.03 (Forbidden). If RS has an access established the same Security Context.
token for the client but it does not cover the action that was
requested on the resource, RS MUST reject the request with a 4.05
(Method Not Allowed).
5. Secure Communication with AS 5. Secure Communication with AS
As specified in the ACE framework (section 5.7 of As specified in the ACE framework (section 5.7 of
[I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or client) [I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or client)
and the AS communicates via the introspection or token endpoint. The and the AS communicates via the introspection or token endpoint. The
use of CoAP and OSCORE for this communication is RECOMMENDED in this use of CoAP and OSCORE ([RFC8613]) for this communication is
profile, other protocols (such as HTTP and DTLS or TLS) MAY be used RECOMMENDED in this profile, other protocols (such as HTTP and DTLS
instead. or TLS) MAY be used instead.
If OSCORE is used, the requesting entity and the AS are expected to If OSCORE is used, the requesting entity and the AS are expected to
have pre-established security contexts in place. How these security have pre-established security contexts in place. How these security
contexts are established is out of scope for this profile. contexts are established is out of scope for this profile.
Furthermore the requesting entity and the AS communicate using OSCORE Furthermore the requesting entity and the AS communicate through the
([I-D.ietf-core-object-security]) through the introspection endpoint introspection endpoint as specified in section 5.7 of
as specified in section 5.7 of [I-D.ietf-ace-oauth-authz] and through [I-D.ietf-ace-oauth-authz] and through the token endpoint as
the token endpoint as specified in section 5.6 of specified in section 5.6 of [I-D.ietf-ace-oauth-authz].
[I-D.ietf-ace-oauth-authz].
6. Discarding the Security Context 6. Discarding the Security Context
There are a number of scenarios where a client or RS needs to discard There are a number of scenarios where a client or RS needs to discard
the OSCORE security context, and acquire a new one. the OSCORE security context, and acquire a new one.
The client MUST discard the current security context associated with The client MUST discard the current security context associated with
an RS when: an RS when:
o the Sequence Number space ends. o the Sequence Number space ends.
o the access token associated with the context expires. o the access token associated with the context expires.
o the client receives a number of 4.01 Unauthorized responses to o the client receives a number of 4.01 Unauthorized responses to
OSCORE requests using the same security context. The exact number OSCORE requests using the same security context. The exact number
needs to be specified by the application. needs to be specified by the application.
o the client receives a new nonce in the 2.01 (Created) response o the client receives a new nonce in the 2.01 (Created) response
(see Section 4.2) to a POST request to the authz-info endpoint, (see Section 4.2) to a POST request to the authz-info endpoint,
when re-posting a non-expired token associated to the existing when re-posting a (non-expired) token associated to the existing
context. context.
The RS MUST discard the current security context associated with a The RS MUST discard the current security context associated with a
client when: client when:
o Sequence Number space ends. o the Sequence Number space ends.
o Access token associated with the context expires. o the access token associated with the context expires.
7. Security Considerations 7. Security Considerations
This document specifies a profile for the Authentication and This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework Authorization for Constrained Environments (ACE) framework
[I-D.ietf-ace-oauth-authz]. Thus the general security considerations [I-D.ietf-ace-oauth-authz]. Thus the general security considerations
from the framework also apply to this profile. from the framework also apply to this profile.
Furthermore the general security considerations of OSCORE Furthermore the general security considerations of OSCORE [RFC8613]
[I-D.ietf-core-object-security] also apply to this specific use of also apply to this specific use of the OSCORE protocol.
the OSCORE protocol.
OSCORE is designed to secure point-to-point communication, providing OSCORE is designed to secure point-to-point communication, providing
a secure binding between the request and the response(s). Thus the a secure binding between the request and the response(s). Thus the
basic OSCORE protocol is not intended for use in point-to-multipoint basic OSCORE protocol is not intended for use in point-to-multipoint
communication (e.g. multicast, publish-subscribe). Implementers of communication (e.g., multicast, publish-subscribe). Implementers of
this profile should make sure that their usecase corresponds to the this profile should make sure that their usecase corresponds to the
expected use of OSCORE, to prevent weakening the security assurances expected use of OSCORE, to prevent weakening the security assurances
provided by OSCORE. provided by OSCORE.
Since the use of nonces in the exchange guarantees uniqueness of AEAD Since the use of nonces in the exchange guarantees uniqueness of AEAD
keys and nonces, it is REQUIRED that nonces are not reused with the keys and nonces, it is REQUIRED that nonces are not reused with the
same input keying material even in case of re-boots. This document same input keying material even in case of re-boots. This document
RECOMMENDS the use of 64 bit random nonces to guarantee non-reuse; if RECOMMENDS the use of 64 bit random nonces. Considering the birthday
applications use something else, such as a counter, they need to paradox, the average collision for each nonce will happen after 2^32
guarantee that reboot and lost of state on either node does not messages, which is considerably more token provisionings than
provoke re-use. If that is not guaranteed, nodes are still expected for intended applications. If applications use something
susceptible to re-using AEAD nonces and keys, in case the Security else, such as a counter, they need to guarantee that reboot and loss
Context is lost, and on-path attacker replay messages. of state on either node does not provoke re-use. If that is not
guaranteed, nodes are susceptible to re-use of AEAD (nonces, keys)
pairs, especially since an on-path attacker can cause the client to
use an arbitrary nonce for Security Context establishment by
replaying client-to-server messages.
This profiles recommends that the RS maintains a single access token This profile recommends that the RS maintains a single access token
for a client. The use of multiple access tokens for a single client for a client. The use of multiple access tokens for a single client
increases the strain on the resource server as it must consider every increases the strain on the resource server as it must consider every
access token and calculate the actual permissions of the client. access token and calculate the actual permissions of the client.
Also, tokens may contradict each other which may lead the server to Also, tokens indicating different or disjoint permissions from each
enforce wrong permissions. If one of the access tokens expires other may lead the server to enforce wrong permissions. If one of
earlier than others, the resulting permissions may offer insufficient the access tokens expires earlier than others, the resulting
protection. Developers should avoid using multiple access tokens for permissions may offer insufficient protection. Developers should
a client. avoid using multiple access tokens for a client.
8. Privacy Considerations 8. Privacy Considerations
This document specifies a profile for the Authentication and This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework Authorization for Constrained Environments (ACE) framework
[I-D.ietf-ace-oauth-authz]. Thus the general privacy considerations [I-D.ietf-ace-oauth-authz]. Thus the general privacy considerations
from the framework also apply to this profile. from the framework also apply to this profile.
As this document uses OSCORE, thus the privacy considerations from As this document uses OSCORE, thus the privacy considerations from
[I-D.ietf-core-object-security] apply here as well. [RFC8613] apply here as well.
An unprotected response to an unauthorized request may disclose An unprotected response to an unauthorized request may disclose
information about the resource server and/or its existing information about the resource server and/or its existing
relationship with the client. It is advisable to include as little relationship with the client. It is advisable to include as little
information as possible in an unencrypted response. When an OSCORE information as possible in an unencrypted response. When an OSCORE
Security Context already exists between the client and the resource Security Context already exists between the client and the resource
server, more detailed information may be included. server, more detailed information may be included.
Although encrypted, the token is sent in the clear to the authz-info
endpoint, so if a client uses the same single token from multiple
locations with multiple Resource Servers, it can risk being tracked
by the token's value.
The nonces exchanged in the request and response to the authz-info
endpoint are also sent in the clear, so using random nonces is best
for privacy (as opposed to, e.g., a counter, that might leak some
information about the client).
The AS is the party tasked of assigning the identifiers used in
OSCORE, which are privacy sensitive (see Section 12.8 of [RFC8613]),
and which could reveal information about the client, or may be used
for correlating requests from one client.
Note that some information might still leak after OSCORE is Note that some information might still leak after OSCORE is
established, due to observable message sizes, the source, and the established, due to observable message sizes, the source, and the
destination addresses. destination addresses.
9. IANA Considerations 9. IANA Considerations
Note to RFC Editor: Please replace all occurrences of "[[this Note to RFC Editor: Please replace all occurrences of "[[this
specification]]" with the RFC number of this specification and delete specification]]" with the RFC number of this specification and delete
this paragraph. this paragraph.
skipping to change at page 23, line 22 skipping to change at page 24, line 40
Section 9.5. It should be noted that in addition to the expert Section 9.5. It should be noted that in addition to the expert
review, some portions of the registry require a specification, review, some portions of the registry require a specification,
potentially on standards track, be supplied as well. potentially on standards track, be supplied as well.
The columns of the registry are: The columns of the registry are:
name The JSON name requested (e.g., "ms"). Because a core goal of name The JSON name requested (e.g., "ms"). Because a core goal of
this specification is for the resulting representations to be this specification is for the resulting representations to be
compact, it is RECOMMENDED that the name be short. This name is compact, it is RECOMMENDED that the name be short. This name is
case sensitive. Names may not match other registered names in a case sensitive. Names may not match other registered names in a
case-insensitive manner unless the Designated Experts state that case-insensitive manner unless the Designated Experts determine
there is a compelling reason to allow an exception. The name is that there is a compelling reason to allow an exception. The name
not used in the CBOR encoding. is not used in the CBOR encoding.
CBOR label The value to be used to identify this algorithm. Key map CBOR label The value to be used to identify this algorithm. Map key
labels MUST be unique. The label can be a positive integer, a labels MUST be unique. The label can be a positive integer, a
negative integer or a string. Integer values between 0 and 255 negative integer or a string. Integer values between -256 and 255
and strings of length 1 are designated as Standards Track Document and strings of length 1 are designated as Standards Track Document
required. Integer values from 256 to 65535 and strings of length required. Integer values from -65536 to -257 and from 256 to
2 are designated as Specification Required. Integer values of 65535 and strings of length 2 are designated as Specification
greater than 65535 and strings of length greater than 2 are Required. Integer values greater than 65535 and strings of length
designated as expert review. Integer values less than -65536 are greater than 2 are designated as expert review. Integer values
marked as private use. less than -65536 are marked as private use.
CBOR Type This field contains the CBOR type for the field. CBOR Type This field contains the CBOR type for the field.
registry This field denotes the registry that values may come from, registry This field denotes the registry that values may come from,
if one exists. if one exists.
description This field contains a brief description for the field. description This field contains a brief description for the field.
specification This contains a pointer to the public specification specification This contains a pointer to the public specification
for the field if one exists for the field if one exists
This registry will be initially populated by the values in Table 1. This registry will be initially populated by the values in Table 1.
The specification column for all of these entries will be this The specification column for all of these entries will be this
document. document and [RFC8613].
9.3. CWT Confirmation Methods Registry 9.3. CWT Confirmation Methods Registry
The following registration is done for the CWT Confirmation Methods The following registration is done for the CWT Confirmation Methods
Registry following the procedure specified in section 7.2.1 of Registry following the procedure specified in section 7.2.1 of
[I-D.ietf-ace-cwt-proof-of-possession]: [I-D.ietf-ace-cwt-proof-of-possession]:
o Confirmation Method Name: "OSCORE_Security_Context" o Confirmation Method Name: "osc"
o Confirmation Method Description: OSCORE_Security_Context carrying o Confirmation Method Description: OSCORE_Security_Context carrying
the OSCORE Security Context parameters the parameters for using OSCORE per-message security with implicit
key confirmation
o Confirmation Key: TBD (value between 4 and 255) o Confirmation Key: TBD (value between 4 and 255)
o Confirmation Value Type(s): map o Confirmation Value Type(s): map
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.2.1 of [[this specification]] o Specification Document(s): Section 3.2.1 of [[this specification]]
9.4. JWT Confirmation Methods Registry 9.4. JWT Confirmation Methods Registry
The following registration is done for the JWT Confirmation Methods The following registration is done for the JWT Confirmation Methods
Registry following the procedure specified in section 6.2.1 of Registry following the procedure specified in section 6.2.1 of
[RFC7800]: [RFC7800]:
o Confirmation Method Value: "osc" o Confirmation Method Value: "osc"
o Confirmation Method Description: OSCORE_Security_Context carrying o Confirmation Method Description: OSCORE_Security_Context carrying
the OSCORE Security Context parameters the parameters for using OSCORE per-message security with implicit
key confirmation
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.2.1 of [[this specification]] o Specification Document(s): Section 3.2.1 of [[this specification]]
9.5. Expert Review Instructions 9.5. Expert Review Instructions
The IANA registry established in this document is defined as expert The IANA registry established in this document is defined to use the
review. This section gives some general guidelines for what the Expert Review registration policy. This section gives some general
experts should be looking for, but they are being designated as guidelines for what the experts should be looking for, but they are
experts for a reason so they should be given substantial latitude. being designated as experts for a reason so they should be given
substantial latitude.
Expert reviewers should take into consideration the following points: Expert reviewers should take into consideration the following points:
o Point squatting should be discouraged. Reviewers are encouraged o Point squatting should be discouraged. Reviewers are encouraged
to get sufficient information for registration requests to ensure to get sufficient information for registration requests to ensure
that the usage is not going to duplicate one that is already that the usage is not going to duplicate one that is already
registered and that the point is likely to be used in deployments. registered and that the point is likely to be used in deployments.
The zones tagged as private use are intended for testing purposes The zones tagged as private use are intended for testing purposes
and closed environments, code points in other ranges should not be and closed environments. Code points in other ranges should not
assigned for testing. be assigned for testing.
o Specifications are required for the standards track range of point o Specifications are required for the standards track range of point
assignment. Specifications should exist for specification assignment. Specifications should exist for specification
required ranges, but early assignment before a specification is required ranges, but early assignment before a specification is
available is considered to be permissible. Specifications are available is considered to be permissible. Specifications are
needed for the first-come, first-serve range if they are expected needed for the first-come, first-serve range if they are expected
to be used outside of closed environments in an interoperable way. to be used outside of closed environments in an interoperable way.
When specifications are not provided, the description provided When specifications are not provided, the description provided
needs to have sufficient information to identify what the point is needs to have sufficient information to identify what the point is
being used for. being used for.
o Experts should take into account the expected usage of fields when o Experts should take into account the expected usage of fields when
skipping to change at page 25, line 17 skipping to change at page 26, line 38
size. size.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33
(work in progress), March 2019. (work in progress), February 2020.
[I-D.ietf-ace-oauth-params] [I-D.ietf-ace-oauth-params]
Seitz, L., "Additional OAuth Parameters for Authorization Seitz, L., "Additional OAuth Parameters for Authorization
in Constrained Environments (ACE)", draft-ietf-ace-oauth- in Constrained Environments (ACE)", draft-ietf-ace-oauth-
params-05 (work in progress), March 2019. params-12 (work in progress), February 2020.
[I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-16 (work in
progress), March 2019.
[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,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
skipping to change at page 26, line 11 skipping to change at page 27, line 28
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>. May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-ace-cwt-proof-of-possession] [I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
possession-06 (work in progress), February 2019. possession-11 (work in progress), October 2019.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
skipping to change at page 26, line 43 skipping to change at page 28, line 16
Possession Key Semantics for JSON Web Tokens (JWTs)", Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016, RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/info/rfc7800>. <https://www.rfc-editor.org/info/rfc7800>.
Appendix A. Profile Requirements Appendix A. Profile Requirements
This section lists the specifications on this profile based on the This section lists the specifications on this profile based on the
requirements on the framework, as requested in Appendix C of requirements on the framework, as requested in Appendix C of
[I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
o (Optional) discovery process of how the client finds the right AS o Optionally define new methods for the client to discover the
for an RS it wants to send a request to: Not specified necessary permissions and AS for accessing a resource, different
o communication protocol the client and the RS must use: CoAP from the one proposed in: Not specified
o security protocol the client and RS must use: OSCORE o Optionally specify new grant types: Not specified
o how the client and the RS mutually authenticate: Implicitly by o Optionally define the use of client certificates as client
possession of a common OSCORE security context credential type: Not specified
o Content-format of the protocol messages: "application/ace+cbor" o Specify the communication protocol the client and RS the must use:
o proof-of-possession protocol(s) and how to select one; which key CoAP
types (e.g. symmetric/asymmetric) supported: OSCORE algorithms; o Specify the security protocol the client and RS must use to
pre-established symmetric keys protect their communication: OSCORE
o Specify how the client and the RS mutually authenticate:
o profile identifier: coap_oscore Implicitly by possession of a common OSCORE security context
o (Optional) how the RS talks to the AS for introspection: HTTP/CoAP o Specify the proof-of-possession protocol(s) and how to select one,
(+ TLS/DTLS/OSCORE) if several are available. Also specify which key types (e.g.,
o how the client talks to the AS for requesting a token: HTTP/CoAP symmetric/asymmetric) are supported by a specific proof-of-
(+ TLS/DTLS/OSCORE) possession protocol: OSCORE algorithms; pre-established symmetric
o how/if the authz-info endpoint is protected: Security protocol keys
above o Specify a unique ace_profile identifier: coap_oscore
o (Optional)other methods of token transport than the authz-info o If introspection is supported: Specify the communication and
endpoint: no security protocol for introspection: HTTP/CoAP (+ TLS/DTLS/OSCORE)
o Specify the communication and security protocol for interactions
between client and AS: HTTP/CoAP (+ TLS/DTLS/OSCORE)
o Specify how/if the authz-info endpoint is protected, including how
error responses are protected: Not protected.
o Optionally define other methods of token transport than the authz-
info endpoint: Not defined
Acknowledgments Acknowledgments
The authors wish to thank Jim Schaad and Marco Tiloca for the input The authors wish to thank Jim Schaad and Marco Tiloca for the input
on this memo. on this memo. Special thanks to the responsible area director Ben
Kaduk for his extensive review and contributed text.
Authors' Addresses Authors' Addresses
Francesca Palombini Francesca Palombini
Ericsson AB Ericsson AB
Email: francesca.palombini@ericsson.com Email: francesca.palombini@ericsson.com
Ludwig Seitz Ludwig Seitz
RISE Combitech
Scheelevagen 17 Djaeknegatan 31
Lund 22370 Malmoe 211 35
Sweden Sweden
Email: ludwig.seitz@ri.se Email: ludwig.seitz@combitech.se
Goeran Selander Goeran Selander
Ericsson AB Ericsson AB
Email: goran.selander@ericsson.com Email: goran.selander@ericsson.com
Martin Gunnarsson Martin Gunnarsson
RISE SICS AB RISE
Scheelevagen 17 Scheelevagen 17
Lund 22370 Lund 22370
Sweden Sweden
Email: martin.gunnarsson@ri.se Email: martin.gunnarsson@ri.se
 End of changes. 114 change blocks. 
380 lines changed or deleted 450 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/