< draft-ietf-ace-oscore-profile-07.txt   draft-ietf-ace-oscore-profile-08.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: August 23, 2019 RISE SICS AB Expires: January 9, 2020 RISE
G. Selander G. Selander
Ericsson AB Ericsson AB
M. Gunnarsson M. Gunnarsson
RISE SICS AB RISE SICS AB
February 19, 2019 July 8, 2019
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-07 draft-ietf-ace-oscore-profile-08
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 August 23, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . 7
3.2.1. OSCORE_Security_Context Object . . . . . . . . . . . 11 3.2.1. OSCORE_Security_Context Object . . . . . . . . . . . 12
4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 14 4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 15
4.1. C-to-RS: POST to authz-info endpoint . . . . . . . . . . 15 4.1. C-to-RS: POST to authz-info endpoint . . . . . . . . . . 16
4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 16 4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 17
4.3. OSCORE Setup . . . . . . . . . . . . . . . . . . . . . . 17 4.3. OSCORE Setup . . . . . . . . . . . . . . . . . . . . . . 18
4.4. Access rights verification . . . . . . . . . . . . . . . 18 4.4. Access rights verification . . . . . . . . . . . . . . . 20
5. Secure Communication with AS . . . . . . . . . . . . . . . . 19 5. Secure Communication with AS . . . . . . . . . . . . . . . . 20
6. Discarding the Security Context . . . . . . . . . . . . . . . 19 6. Discarding the Security Context . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9.1. ACE OAuth Profile Registry . . . . . . . . . . . . . . . 21 9.1. ACE OAuth Profile Registry . . . . . . . . . . . . . . . 22
9.2. OSCORE Security Context Parameters Registry . . . . . . . 22 9.2. OSCORE Security Context Parameters Registry . . . . . . . 23
9.3. CWT Confirmation Methods Registry . . . . . . . . . . . . 22 9.3. CWT Confirmation Methods Registry . . . . . . . . . . . . 23
9.4. JWT Confirmation Methods Registry . . . . . . . . . . . . 23 9.4. JWT Confirmation Methods Registry . . . . . . . . . . . . 24
9.5. Expert Review Instructions . . . . . . . . . . . . . . . 23 9.5. Expert Review Instructions . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 25 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 26
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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. In order to provide communication
security, proof of possession, and server authentication they use security, proof of possession, and server authentication they use
Object Security for Constrained RESTful Environments (OSCORE) Object Security for Constrained RESTful Environments (OSCORE)
skipping to change at page 3, line 33 skipping to change at page 3, line 33
"authorization", "confidentiality", "(data) integrity", "message "authorization", "confidentiality", "(data) integrity", "message
authentication code", and "verify" are taken from [RFC4949]. authentication code", and "verify" are taken from [RFC4949].
RESTful terminology follows HTTP [RFC7231]. RESTful terminology follows HTTP [RFC7231].
Terminology for entities in the architecture is defined in OAuth 2.0 Terminology for entities in the architecture is defined in OAuth 2.0
[RFC6749], such as client (C), resource server (RS), and [RFC6749], such as client (C), resource server (RS), and
authorization server (AS). It is assumed in this document that a authorization server (AS). It is assumed in this document that a
given resource on a specific RS is associated to a unique AS. given resource on a specific RS is associated to a unique AS.
Concise Data Definition Language (CDDL) [RFC8610] is used in this
specification.
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
skipping to change at page 4, line 22 skipping to change at page 4, line 25
or DTLS MAY be used additionally or instead. or DTLS MAY be used additionally or instead.
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.
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 sets the ID Context in the Security concatenates N1 with N2 and appends the result to the Master Salt in
Context (see section 3 of [I-D.ietf-core-object-security]) to N1 the Security Context (see section 3 of
concatenated with N2. The RS then derives the complete Security [I-D.ietf-core-object-security]). The RS then derives the complete
Context associated with the received token from it plus the Security Context associated with the received token from it plus the
parameters received in the AS, following section 3.2 of parameters received in the AS, following section 3.2 of
[I-D.ietf-core-object-security]. [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 it with N1 and
sets the ID Context in its Security Context (see section 3 of appends the result to the Master Salt in its Security Context (see
[I-D.ietf-core-object-security]) to N1 concatenated with N2. The section 3 of [I-D.ietf-core-object-security]). The client then
client then derives the complete Security Context from the ID Context derives the complete Security Context from the nonces plus the
plus the parameters received from the AS. parameters received from 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.
This message may contain the ID Context value. If the request If the request verifies, then this Security Context is stored in the
verifies, then this Security Context is stored in the server, and server, and used in the response, and in further communications with
used in the response, and in further communications with the client, the client, until token expiration. This Security Context is
until token expiration. This Security Context is discarded if the discarded if the same token is re-used to successfully derive a new
same token is re-used to successfully derive a new Security Context. Security Context.
Once the client receives a valid response, it does not continue to
include the ID Context value in further requests.
The use of random nonces during the exchange prevents the reuse of The use of random nonces during the exchange prevents the reuse of
AEAD nonces and keys with different messages, in case of re- AEAD nonces and keys with different messages, in case of re-
derivation of the Security Context both for Clients and Resource derivation of the Security Context both for Clients and Resource
Servers from an old non-expired access token, e.g. in case of re-boot Servers from an old non-expired access token, e.g. in case of re-boot
of either the client or RS. In fact, by using random nonces as ID of either the client or RS. In fact, by using random nonces as part
Context, the request to the authz-info endpoint posting the same of the Master Salt, the request to the authz-info endpoint posting
token results in a different Security Context, since Master Secret, the same token results in a different Security Context, since Master
Sender ID and Recipient ID are the same but ID Context is different. Secret, Sender ID and Recipient ID are the same but Master Salt is
Therefore, the main requirement for the nonces is that they have a different. Therefore, the main requirement for the nonces is that
good amount of randomness. If random nonces were not used, a node they have a good amount of randomness. If random nonces were not
re-using a non-expired old token would be susceptible to on-path used, a node re-using a non-expired old token would be susceptible to
attackers provoking the creation of OSCORE messages using old AEAD on-path attackers provoking the creation of OSCORE messages using old
keys and nonces. AEAD keys and nonces.
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 Information --] | | | [<---- AS Request ------] | |
| Creation Hints | |
| | | | | |
| ----- POST /token ----------------------------> | | ----- POST /token ----------------------------> |
| | | | | |
| <---------------------------- Access Token ----- | | <---------------------------- Access Token ----- |
| + RS Information | | + Access Information |
| ---- POST /authz-info ---> | | | ---- POST /authz-info ---> | |
| (access_token, N1) | | | (access_token, N1) | |
| | | | | |
| <--- 2.01 Created (N2) --- | | | <--- 2.01 Created (N2) --- | |
| | | | | |
/Sec Context /Sec Context | /Sec Context /Sec Context |
Derivation/ Derivation/ | Derivation/ Derivation/ |
| | | | | |
| ---- OSCORE Request -----> | | | ---- OSCORE Request -----> | |
| ?(N1, N2) | |
| | | | | |
| <--- OSCORE Response ----- | | | <--- OSCORE Response ----- | |
| | | | | |
| ---- OSCORE Request -----> | | | ---- OSCORE Request -----> | |
| | | | | |
| <--- OSCORE Response ----- | | | <--- OSCORE Response ----- | |
| ... | | | ... | |
Figure 1: Protocol Overview Figure 1: Protocol Overview
skipping to change at page 6, line 32 skipping to change at page 6, line 34
{ {
"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 carrying the client's to the token endpoint a req_cnf object. The req_cnf MUST include a
identifier (that was assigned in section Section 3.2) in the kid kid field carrying a CBOR array object containing the client's
field. This identifier can be used by the AS to determine the shared identifier (assigned in section Section 3.2) and optionally the
context identifier (if assigned in section Section 3.2). The CBOR
array is defined in Figure 3, and follows the notation of [RFC8610].
These identifiers can be used by the AS to determine the shared
secret to construct the proof-of-possession token and therefore MUST secret to construct the proof-of-possession token and therefore MUST
identify a symmetric key that was previously generated by the AS as a identify a symmetric key that was previously generated by the AS as a
shared secret for the communication between the client and the RS. shared secret for the communication between the client and the RS.
The AS MUST verify that the received value identifies a proof-of- The AS MUST verify that the received value identifies a proof-of-
possession key and token that have previously been issued to the possession key and token that have previously been issued to the
requesting client. If that is not the case, the Client-to-AS request requesting client. If that is not the case, the Client-to-AS request
MUST be declined with the error code 'invalid_request' as defined in 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 = [
clientId,
?IdContext
]
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, in CBOR diagnostic notation without the
tag and value abbreviations is reported in Figure 3 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" "kid" : ["myclient","contextid1"]
} }
Figure 3: 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
[I-D.ietf-ace-oauth-authz]. If the client request was invalid, or [I-D.ietf-ace-oauth-authz]. If the client request was invalid, or
not authorized, the AS returns an error response as described in not authorized, the AS returns an error response as described in
section 5.6.3 of [I-D.ietf-ace-oauth-authz]. section 5.6.3 of [I-D.ietf-ace-oauth-authz].
skipping to change at page 7, line 40 skipping to change at page 8, line 4
"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 provision 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 provision the following data, in the same
response. response.
o a client identifier o a client 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 a replay window type and size
The master secret MUST be communicated as the 'ms' field in the
OSCORE_Security_Context in the 'cnf' parameter of the access token
response as defined in Section 3.2 of [I-D.ietf-ace-oauth-params].
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 AEAD algorithm MAY be included as the 'alg' Section 3.2.1. The master secret MUST be communicated as the 'ms'
parameter in the OSCORE_Security_Context; the HKDF algorithm MAY be field in the OSCORE_Security_Context in the 'cnf' parameter of the
included as the 'hkdf' parameter of the OSCORE_Security_Context, the access token response as defined in Section 3.2 of
salt MAY be included as the 'salt' parameter of the [I-D.ietf-ace-oauth-params]. The AEAD algorithm MAY be included as
COSCORE_Security_Context, and the replay window type and size MAY be the 'alg' parameter in the OSCORE_Security_Context; the HKDF
included as the 'rpl' of the OSCORE_Security_Context, as defined in algorithm MAY be included as the 'hkdf' parameter of the
Section 3.2.1. OSCORE_Security_Context, a salt MAY be included as the 'salt'
parameter of the OSCORE_Security_Context, and the replay window type
and size MAY be included as the 'rpl' of the OSCORE_Security_Context,
as defined in Section 3.2.1.
The same parameters MUST be included as metadata of the access token. The same parameters MUST be included as metadata 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. 'cnf' claim of this token.
The AS MUST also assign an identifier to the RS, and MAY assign an The AS MUST also assign an identifier to the RS (serverId), MAY
identifier to the client. These identifiers are then used as Sender assign an identifier to the client (clientId), and MAY assign an
ID and Recipient ID in the OSCORE context as described in section 3.1 identifier to the context (contextId). These identifiers are then
of [I-D.ietf-core-object-security]. The client identifiers MUST be used as Sender ID, Recipient ID and ID Context in the OSCORE context
unique in the set of all clients on a single RS, and RS identifiers as described in section 3.1 of [I-D.ietf-core-object-security]. The
MUST be unique in the set of all RS for any given client. Moreover, couple (client identifier, context identifier) MUST be unique in the
when assigned, these MUST be included in the OSCORE_Security_Context, set of all clients on a single RS. Moreover, when assigned,
as defined in Section 3.2.1. serverId, clientId and 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 to assume unique identifiers for
each client requesting a particular resource to a RS. If this is not each client requesting a particular resource to a RS. If this is not
the case, collisions of identifiers may appear in the RS, in which the case, collisions of identifiers may appear in the RS, in which
case the RS needs to have a mechanism in place to disambiguate case the RS needs to have a mechanism in place to disambiguate
identifiers or mitigate their effect. identifiers or mitigate their effect.
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 4 shows an example of such an AS response, in CBOR diagnostic Figure 5 shows an example of such an AS response, in CBOR diagnostic
notation without the tag and value abbreviations. notation without the tag and value abbreviations.
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 omitted for brevity)',
"profile" : "coap_oscore", "profile" : "coap_oscore",
"expires_in" : "3600", "expires_in" : "3600",
"cnf" : { "cnf" : {
"OSCORE_Security_Context" : { "OSCORE_Security_Context" : {
"alg" : "AES-CCM-16-64-128", "alg" : "AES-CCM-16-64-128",
"clientId" : b64'qA', "clientId" : b64'qA',
"serverId" : b64'Qg', "serverId" : b64'Qg',
"ms" : h'f9af838368e353e78888e1426bd94e6f' "ms" : h'f9af838368e353e78888e1426bd94e6f'
} }
} }
} }
Figure 4: Example AS-to-C Access Token response with OSCORE profile. Figure 5: Example AS-to-C Access Token response with OSCORE profile.
Figure 5 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" : { "OSCORE_Security_Context" : {
"alg" : "AES-CCM-16-64-128", "alg" : "AES-CCM-16-64-128",
"clientId" : "client", "clientId" : h'636C69656E74',
"serverId" : "server", "serverId" : h'736572766572',
"ms" : h'f9af838368e353e78888e1426bd94e6f' "ms" : h'f9af838368e353e78888e1426bd94e6f'
} }
} }
Figure 5: Example CWT with OSCORE parameters. Figure 6: Example CWT with OSCORE parameters.
The same CWT token as in Figure 5, 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 6. in Figure 7.
NOTE TO THE RFC EDITOR: before publishing, it should be checked (and NOTE TO THE RFC EDITOR: before publishing, it should be checked (and
in case fixed) that the values used below (which are not yet in case fixed) that the values used below (which are not yet
registered) are the final values registered in IANA. registered) are the final values registered in IANA.
A5 # map(5) A5 # map(5)
03 # unsigned(3) 03 # unsigned(3)
76 # text(22) 76 # text(22)
74656D7053656E736F72496E4C6976696E67526F6F6D 74656D7053656E736F72496E4C6976696E67526F6F6D
# "tempSensorInLivingRoom" # "tempSensorInLivingRoom"
skipping to change at page 10, line 29 skipping to change at page 11, line 25
78 18 # text(24) 78 18 # text(24)
74656D70657261747572655F67206669726D776172655F70 74656D70657261747572655F67206669726D776172655F70
# "temperature_g firmware_p" # "temperature_g firmware_p"
08 # unsigned(8) 08 # unsigned(8)
A1 # map(1) A1 # map(1)
04 # unsigned(4) 04 # unsigned(4)
A4 # map(4) A4 # map(4)
05 # unsigned(5) 05 # unsigned(5)
0A # unsigned(10) 0A # unsigned(10)
02 # unsigned(2) 02 # unsigned(2)
66 # text(6) 46 # bytes(6)
636C69656E74 # "client" 636C69656E74 # "client"
03 # unsigned(3) 03 # unsigned(3)
66 # text(6) 46 # bytes(6)
736572766572 # "server" 736572766572 # "server"
01 # unsigned(1) 01 # unsigned(1)
50 # bytes(16) 50 # bytes(16)
F9AF838368E353E78888E1426BD94E6F F9AF838368E353E78888E1426BD94E6F
# "\xF9\xAF\x83\x83h\xE3S\xE7
\x88\x88\xE1Bk\xD9No"
Figure 6: 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 in the 'kid' field in the 'cnf' parameter of the client identifier and optionally the context identifier in the 'kid'
token. The client identifier needs to be provisioned, in order for field in the 'cnf' parameter of the token, with the same structure
the RS to identify the previously generated Security Context. defined in Figure 3. These identifiers need to be provisioned, in
order for the RS to identify the previously generated Security
Context.
Figure 7 shows an example of such an AS response, in CBOR diagnostic Figure 8 shows an example of such an AS response, in CBOR diagnostic
notation without the tag and value abbreviations. notation without the tag and value abbreviations.
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 omitted for brevity)',
"profile" : "coap_oscore", "profile" : "coap_oscore",
"expires_in" : "3600" "expires_in" : "3600"
} }
Figure 7: 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 8 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" : b64'qA'
} }
} }
Figure 8: 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 (Section 3.1 of
[I-D.ietf-core-object-security]). The OSCORE_Security_Context object [I-D.ietf-core-object-security]). The OSCORE_Security_Context object
can either be encoded as JSON or as CBOR. In both cases, the set of can either be encoded as JSON object or as CBOR map. In both cases,
common parameters that can appear in an OSCORE_Security_Context the set of common parameters that can appear in an
object can be found in the IANA "OSCORE Security Context Parameters" OSCORE_Security_Context object can be found in the IANA "OSCORE
registry (Section Section 9.2) and is defined below. All parameters Security Context Parameters" registry (Section Section 9.2) and is
are optional. Table 1 provides a summary of the defined below. All parameters are optional. Table 1 provides a
OSCORE_Security_Context parameters defined in this section. summary of the OSCORE_Security_Context parameters defined in this
section.
+-----------+-------+----------------+--------------+---------------+ +-----------+-------+----------------+--------------+---------------+
| name | CBOR | CBOR type | registry | description | | name | CBOR | CBOR type | registry | description |
| | label | | | | | | label | | | |
+-----------+-------+----------------+--------------+---------------+ +-----------+-------+----------------+--------------+---------------+
| 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 |
skipping to change at page 14, line 14 skipping to change at page 15, line 14
is a Base64 encoded byte string. In CBOR, the "contextID" type is is a Base64 encoded byte string. In 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 rpl: This parameter is used to carry the OSCORE value, encoded as a
bstr. This parameter identifies the OSCORE Replay Window Size and bstr. This parameter identifies the OSCORE Replay Window Size and
Type value, which is a byte string. For more information about Type value, which is a byte string. For more information about
this field, see section 3.1 of [I-D.ietf-core-object-security]. 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 In JSON, the "rpl" value is a Base64 encoded byte string. In
CBOR, the "rpl" type is bstr, and has label 8. CBOR, the "rpl" type is bstr, and has label 8.
An example of JSON OSCORE_Security_Context is given in Figure 9. An example of JSON OSCORE_Security_Context is given in Figure 10.
"OSCORE_Security_Context" : { "OSCORE_Security_Context" : {
"alg" : "AES-CCM-16-64-128", "alg" : "AES-CCM-16-64-128",
"clientId" : b64'qA', "clientId" : b64'qA',
"serverId" : b64'Qg', "serverId" : b64'Qg',
"ms" : b64'+a+Dg2jjU+eIiOFCa9lObw' "ms" : b64'+a+Dg2jjU+eIiOFCa9lObw'
} }
Figure 9: 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 = {
? 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
skipping to change at page 15, line 21 skipping to change at page 16, line 21
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 N1 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. The client
MUST store this nonce as long as the response from the RS is not MUST store this nonce as long as the response from the RS is not
received and the access token related to it is still valid. The 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 client MUST use the Content-Format the token and N1 to the RS.
"application/ace+cbor" defined in section 8.14 of
[I-D.ietf-ace-oauth-authz]. The client MUST include the access token Note that the use of the payload and the Content-Format is different
using the correct CBOR label (e.g., "cwt" for CWT, "jwt" for JWT) and from what described in section 5.8.1 of [I-D.ietf-ace-oauth-authz],
N1 using the 'nonce' parameter defined in section 5.1.2 of which only transports the token without any CBOR wrapping. In this
[I-D.ietf-ace-oauth-authz]. 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
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,
"jwt" for JWT) and N1 using the 'cnonce' parameter defined in section
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, since
an RS may delete a stored access token, due to lack of memory. an RS may delete a stored access token, due to lack of memory.
Figure 10 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, in CBOR diagnostic notation without the tag and value
abbreviations. abbreviations.
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 omitted for brevity)',
"nonce": h'018a278f7faab55a' "cnonce": h'018a278f7faab55a'
} }
Figure 10: 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 OSCORE_Security_Context is
missing (e.g. any of the mandatory parameters from the AS), or if any missing (e.g. any of the mandatory parameters from the AS), or if any
skipping to change at page 16, line 38 skipping to change at page 17, line 38
the RS MUST respond with an error response code equivalent to the the RS MUST respond with an error response code equivalent to the
CoAP code 4.00 (Bad Request). In the latter two cases, the RS MAY CoAP code 4.00 (Bad Request). In the latter two cases, the RS MAY
provide additional information in the error response, in order to provide additional information in the error response, in order to
clarify what went wrong. The RS MAY make an introspection request to clarify what went wrong. The RS MAY make an introspection request to
validate the token before responding to the POST request to the validate the token before responding to 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 'nonce' (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. Moreover, if the OSCORE_Security_Context 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
OSCORE_Security_Context contained such a parameter, in order to OSCORE_Security_Context contained such a parameter, in order to
guarantee the uniqueness of the client identifier. The RS MUST use guarantee the uniqueness of the client identifier. The RS MUST use
the Content-Format "application/ace+cbor" defined in section 8.14 of the Content-Format "application/ace+cbor" defined in section 8.14 of
[I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
Figure 11 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, in CBOR diagnostic notation without the tag and value
abbreviations. abbreviations.
Header: Created (Code=2.01) Header: Created (Code=2.01)
Content-Format: "application/ace+cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
{ {
"nonce": h'25a8991cd700ac01' "cnonce": h'25a8991cd700ac01'
} }
Figure 11: 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 When receiving an updated access token with updated authorization
information from the client (see section Section 3.1), it is information from the client (see section Section 3.1), it is
RECOMMENDED that the RS overwrites the previous token, that is only RECOMMENDED that the RS overwrites the previous token, that is only
the latest authorization information in the token received by the RS the latest authorization information in the token received by the RS
is valid. This simplifies for the RS to keep track of authorization is valid. This simplifies for the RS to keep track of authorization
information for a given client. 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
nonce N2 from the 'nonce' parameter and the client identifier from nonce N2 from the 'cnonce' parameter and the client identifier from
the 'clientId' in the CBOR map in the payload of the response. Then, the 'clientId' in the CBOR map in the payload of the response. Then,
the client MUST set the ID Context of the Security Context created to the client MUST set the Master Salt of the Security Context created
communicate with the RS to the concatenation of N1 and N2, in this to communicate with the RS to the concatenation of salt, N1, and N2,
order: ID Context = N1 | N2, where | denotes byte string in this order: Master Salt = salt | N1 | N2, where | denotes byte
concatenation. The client MUST set the Master Secret and Recipient string concatenation, and where salt was received from the AS in
ID from the parameters received from the AS in Section 3.2. The Section 3.2. The client MUST set the Master Secret and Recipient ID
client MUST set the AEAD Algorithm, Master Salt, HKDF, and Replay from the parameters received from the AS in Section 3.2. The client
Window from the parameters received from the AS in Section 3.2, if MUST set the AEAD Algorithm, ID Context, HKDF, and Replay Window from
present. In case these parameters are omitted, the default values the parameters received from the AS in Section 3.2, if present. In
are used as described in section 3.2 of case these parameters are omitted, the default values are used as
[I-D.ietf-core-object-security]. The client MUST set the Sender ID described in section 3.2 of [I-D.ietf-core-object-security]. The
from the 'clientId in the 2.01 (Created) response, if present; client MUST set the Sender ID from the 'clientId in the 2.01
otherwise, the client MUST set the Sender ID from the parameters (Created) response, if present; otherwise, the client MUST set the
received from the AS in Section 3.2. After that, the client MUST Sender ID from the parameters received from the AS in Section 3.2.
derive the complete Security Context following section 3.2.1 of After that, the client MUST derive the complete Security Context
[I-D.ietf-core-object-security]. From this point on, the client MUST following section 3.2.1 of [I-D.ietf-core-object-security]. From
use this Security Context to communicate with the RS when accessing this point on, the client MUST use this Security Context to
the resources as specified by the authorization information. communicate with the RS when accessing the 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. In the first request sent to the RS, the client MAY using OSCORE.
include the kid context if the application needs to, with value ID
Context, i.e. N1 concatenated with N2.
After sending the 2.01 (Created) response, the RS MUST set the ID After sending the 2.01 (Created) response, the RS MUST set the Master
Context of the Security Context created to communicate with the Salt of the Security Context created to communicate with the client
client to the concatenation of N1 and N2, in this order: ID Context = to the concatenation of salt, N1, and N2, in this order: Master Salt
N1 | N2, where | denotes byte string concatenation. The RS MUST set = salt | N1 | N2, where | denotes byte string concatenation, and
where salt was received from the AS in Section 4.2. The RS MUST set
the Master Secret, Sender ID and Recipient ID from the parameters, the Master Secret, Sender ID and Recipient ID from the parameters,
received from the client in the access token in Section 4.1 after received from the client in the access token in Section 4.1 after
validation of the token as specified in Section 4.2. The RS MUST set validation of the token as specified in Section 4.2. The RS MUST set
the AEAD Algorithm, Master Salt, HKDF, and Replay Window from the the AEAD Algorithm, ID Context, HKDF, and Replay Window from the
parameters received from the client in the access token in parameters received from the client in the access token in
Section 4.1 after validation of the token as specified in Section 4.1 after validation of the token as specified in
Section 4.2, if present. In case these parameters are omitted, the Section 4.2, if present. In case these parameters are omitted, the
default values are used as described in section 3.2 of default values are used as described in section 3.2 of
[I-D.ietf-core-object-security]. After that, the RS MUST derive the [I-D.ietf-core-object-security]. After that, the RS MUST derive the
complete Security Context following section 3.2.1 of complete Security Context following section 3.2.1 of
[I-D.ietf-core-object-security], and MUST associate this Security [I-D.ietf-core-object-security], and MUST associate this Security
Context with the authorization information from the access token. 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 the request 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
[I-D.ietf-core-object-security]. Additionally, if OSCORE [I-D.ietf-core-object-security]. Additionally, if OSCORE
verification succeeds, the verification of access rights is performed verification succeeds, the verification of access rights is performed
as described in section Section 4.4. The RS MUST NOT use the as described in section Section 4.4. The RS MUST NOT use the
Security Context after the related token has expired, and MUST Security Context after the related token has expired, and MUST
respond with a unprotected 4.01 (Unauthorized) error message. respond with a unprotected 4.01 (Unauthorized) error message.
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
in place, the is RECOMMENDED to delete the old Security Context after
OSCORE verification and verification of access rights succeed. The
RS MUST delete the Security Context if it deletes the access token
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, [I-D.ietf-core-object-security]. If OSCORE verification succeeds,
and the target resource requires authorization, the RS retrieves the and the target resource requires authorization, the RS retrieves the
authorization information from the access token associated to the authorization information from the access token associated to the
Security Context. The RS then MUST verify that the authorization Security Context. The RS then MUST verify that the authorization
information covers the resource and the action requested. information covers the resource and the action requested.
skipping to change at page 24, line 15 skipping to change at page 25, line 17
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-21 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24
(work in progress), February 2019. (work in progress), March 2019.
[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-04 (work in progress), February 2019. params-05 (work in progress), March 2019.
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-15 (work in (OSCORE)", draft-ietf-core-object-security-16 (work in
progress), August 2018. 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 25, line 5 skipping to change at page 26, line 5
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
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-05 (work in progress), November 2018. possession-06 (work in progress), February 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 23 skipping to change at page 27, line 28
on this memo. on this memo.
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 SICS AB RISE
Scheelevagen 17 Scheelevagen 17
Lund 22370 Lund 22370
Sweden Sweden
Email: ludwig.seitz@ri.se Email: ludwig.seitz@ri.se
Goeran Selander Goeran Selander
Ericsson AB Ericsson AB
Email: goran.selander@ericsson.com Email: goran.selander@ericsson.com
 End of changes. 63 change blocks. 
150 lines changed or deleted 188 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/