draft-ietf-ace-oscore-profile-10.txt   draft-ietf-ace-oscore-profile-11.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: September 10, 2020 Combitech Expires: December 20, 2020 Combitech
G. Selander G. Selander
Ericsson AB Ericsson AB
M. Gunnarsson M. Gunnarsson
RISE RISE
March 9, 2020 June 18, 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-10 draft-ietf-ace-oscore-profile-11
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 September 10, 2020. This Internet-Draft will expire on December 20, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3. Client-AS Communication . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 8 3.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . . . 8
3.2.1. OSCORE_Security_Context Object . . . . . . . . . . . 13 3.2.1. OSCORE_Security_Context Object . . . . . . . . . . . 13
4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 16 4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 17
4.1. C-to-RS: POST to authz-info endpoint . . . . . . . . . . 17 4.1. C-to-RS: POST to authz-info endpoint . . . . . . . . . . 18
4.1.1. The Nonce 1 Parameter . . . . . . . . . . . . . . . . 18 4.1.1. The Nonce 1 Parameter . . . . . . . . . . . . . . . . 19
4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 18 4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 19
4.2.1. The Nonce 2 Parameter . . . . . . . . . . . . . . . . 19 4.2.1. The Nonce 2 Parameter . . . . . . . . . . . . . . . . 21
4.3. OSCORE Setup . . . . . . . . . . . . . . . . . . . . . . 19 4.3. OSCORE Setup . . . . . . . . . . . . . . . . . . . . . . 21
4.4. Access rights verification . . . . . . . . . . . . . . . 21 4.4. Access rights verification . . . . . . . . . . . . . . . 22
5. Secure Communication with AS . . . . . . . . . . . . . . . . 21 5. Secure Communication with AS . . . . . . . . . . . . . . . . 22
6. Discarding the Security Context . . . . . . . . . . . . . . . 21 6. Discarding the Security Context . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.1. ACE OAuth Profile Registry . . . . . . . . . . . . . . . 24 9.1. ACE OAuth Profile Registry . . . . . . . . . . . . . . . 25
9.2. OAuth Parameters Registry . . . . . . . . . . . . . . . . 24 9.2. OAuth Parameters Registry . . . . . . . . . . . . . . . . 26
9.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 24 9.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 26
9.4. OSCORE Security Context Parameters Registry . . . . . . . 25 9.4. OSCORE Security Context Parameters Registry . . . . . . . 26
9.5. CWT Confirmation Methods Registry . . . . . . . . . . . . 25 9.5. CWT Confirmation Methods Registry . . . . . . . . . . . . 27
9.6. JWT Confirmation Methods Registry . . . . . . . . . . . . 26 9.6. JWT Confirmation Methods Registry . . . . . . . . . . . . 28
9.7. Expert Review Instructions . . . . . . . . . . . . . . . 26 9.7. Expert Review Instructions . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 28 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 30
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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. Note that this profile uses a access to the resource server. Note that this profile uses a
symmetric-crypto-based scheme, where the symmetric secret is used as symmetric-crypto-based scheme, where the symmetric secret is used as
input material for keying material derivation. In order to provide input material for keying material derivation. In order to provide
skipping to change at page 7, line 30 skipping to change at page 7, line 30
"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 bstr-wrapped CBOR array object containing the kid field carrying a bstr-wrapped CBOR array object containing the
client's identifier (assigned as discussed in Section 3.2) and client's identifier (assigned as discussed in Section 3.2) and the
optionally the context identifier (if assigned as discussed in context identifier (if assigned as discussed in Section 3.2). The
Section 3.2). The CBOR array is defined in Figure 3, and follows the CBOR array is defined in Figure 3, and follows the notation of
notation of [RFC8610]. These identifiers, together with other [RFC8610]. These identifiers, together with other information such
information such as audience, can be used by the AS to determine the as audience, can be used by the AS to determine the shared secret
shared secret bound to the proof-of-possession token and therefore bound to the proof-of-possession token and therefore MUST identify a
MUST identify a symmetric key that was previously generated by the AS symmetric key that was previously generated by the AS as a shared
as a shared secret for the communication between the client and the secret for the communication between the client and the RS. The AS
RS. The AS MUST verify that the received value identifies a proof- MUST verify that the received value identifies a proof-of-possession
of-possession key that has previously been issued to the requesting key that has previously been issued to the requesting client. If
client. If that is not the case, the Client-to-AS request MUST be that is not the case, the Client-to-AS request MUST be declined with
declined with the error code 'invalid_request' as defined in the error code 'invalid_request' as defined in Section 5.6.3 of
Section 5.6.3 of [I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
kid_arr = [ kid_arr = [
clientId, clientId,
?IdContext ?IdContext
] ]
kid = bstr .cbor kid_arr 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
skipping to change at page 9, line 29 skipping to change at page 9, line 29
o an HKDF algorithm o an HKDF algorithm
o a salt o a salt
o the OSCORE version number 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. This object is transported in the 'cnf' parameter of Section 3.2.1. This object is transported in the 'cnf' parameter of
the access token response as defined in Section 3.2 of the 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], as the value of a field named 'osc',
registered in Section 9.5 and Section 9.6. The master secret MUST be registered in Section 9.5 and Section 9.6. The master secret MUST be
communicated as the 'ms' field in the 'osc' field in the 'cnf' 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 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 [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 OSCORE version parameter of the OSCORE_Security_Context, and the OSCORE version
number may be included as the 'version' parameter of the number may be included as the 'version' parameter of the
OSCORE_Security_Context. OSCORE_Security_Context.
skipping to change at page 10, line 22 skipping to change at page 10, line 22
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 for the AS to enforce uniqueness single AS, which makes it possible for the AS to enforce uniqueness
of identifiers for each client requesting a particular resource to a of identifiers for each client requesting a particular resource to a
RS. If this is not the case, collisions of identifiers may occur at RS. If this is not the case, collisions of identifiers may occur at
the RS, in which case the RS needs to have a mechanism in place to the RS, in which case the RS needs to have a mechanism in place to
disambiguate identifiers or mitigate the effect of the collisions. disambiguate identifiers or mitigate the effect of the collisions.
Moreover, implementers of this specification need to be aware that if Moreover, implementers of this specification need to be aware that if
other authentication mechanisms are used to set up OSCORE between the other authentication mechanisms are used to set up OSCORE between the
same client and RS, that do not rely on AS assigning identifiers, same client and RS, that do not rely on AS assigning identifiers,
collisions may happen and need to be mitigated. collisions may happen and need to be mitigated. A mitigation example
would be to use distinct namespaces of identifiers for different
authentication mechanisms.
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 an AS response, with payload in CBOR Figure 5 shows an example of an AS response, with payload in CBOR
diagnostic notation without the tag and value abbreviations. The diagnostic notation without the tag and value abbreviations. The
access token has been truncated for readability. access token has been truncated for readability.
Header: Created (Code=2.01) Header: Created (Code=2.01)
skipping to change at page 11, line 26 skipping to change at page 11, line 46
"alg" : "AES-CCM-16-64-128", "alg" : "AES-CCM-16-64-128",
"clientId" : h'00', "clientId" : h'00',
"serverId" : h'01', "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 [RFC8747] and encoded in
[I-D.ietf-ace-cwt-proof-of-possession] and encoded in CBOR is shown CBOR is shown in Figure 7.
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 12, line 45 skipping to change at page 12, line 49
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 the context identifier (if it was set and client identifier and the context identifier (if it was set and
included in the initial access token response by the AS) in the 'kid' 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 included in the defined in Figure 3. These identifiers need to be included in the
response, in order for the RS to identify the previously generated token in order for the RS to identify the previously generated
Security Context. Security Context.
Figure 8 shows an example of such an AS response, with payload in Figure 8 shows an example of such an AS response, with payload in
CBOR diagnostic notation without the tag and value abbreviations. CBOR diagnostic notation without the tag and value abbreviations.
The access token has been truncated for readability. 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:
{ {
skipping to change at page 13, line 43 skipping to change at page 13, line 47
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, i.e., the local set of information of an OSCORE Security Context, i.e., the local set of information
elements necessary to carry out the cryptographic operations in elements necessary to carry out the cryptographic operations in
OSCORE (Section 3.1 of [RFC8613]). In particular, the OSCORE (Section 3.1 of [RFC8613]). In particular, the
OSCORE_Security_Context object is defined to be serialized and OSCORE_Security_Context object is defined to be serialized and
transported between nodes, as specified by this document, but can transported between nodes, as specified by this document, but can
also be used in this way by other specifications if needed. The also be used by other specifications if needed. The
OSCORE_Security_Context object can either be encoded as a JSON object 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 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 9.4), defined for Security Context Parameters" registry (Section 9.4), defined for
extensibility, and is specified below. All parameters are optional. extensibility, and is specified below. All parameters are optional.
Table 1 provides a summary of the OSCORE_Security_Context parameters Table 1 provides a summary of the OSCORE_Security_Context parameters
defined in this section. defined in this section.
+-----------+-------+----------------+--------------+---------------+ +-----------+-------+----------------+--------------+---------------+
| name | CBOR | CBOR type | registry | description | | name | CBOR | CBOR type | registry | description |
skipping to change at page 16, line 43 skipping to change at page 17, line 43
? 7 => bstr, ; contextId ? 7 => bstr, ; contextId
* 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 client generates a nonce N1, and posts it together with the token
that includes the materials (e.g., OSCORE parameters) received from that includes the materials (e.g., OSCORE parameters) received from
the AS to the RS. The RS then generates a nonce N2, and use the AS to the RS. The RS then generates a nonce N2, and uses
Section 3.2 of [RFC8613] to derive a security context based on a Section 3.2 of [RFC8613] to derive a security context based on a
shared master secret and the two nonces, established between client shared master secret and the two nonces, established between client
and server. The nonces are encoded as CBOR bstr if CBOR is used, and 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 as Base64 string if JSON is used. This security context is used to
protect all future communication between client and RS using OSCORE, protect all future communication between client and RS using OSCORE,
as long as the access token is valid. as long as the access token is valid.
Note that the RS and client authenticates themselves by generating Note that the RS and client authenticates themselves by generating
the shared OSCORE Security Context using the pop-key as master the shared OSCORE Security Context using the pop-key as master
secret. An attacker posting a valid token to the RS will not be able secret. An attacker posting a valid token to the RS will not be able
skipping to change at page 17, line 28 skipping to change at page 18, line 28
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 "access_token" parameter and N1 using the
"jwt" for JWT) and N1 using the 'nonce1' parameter defined in 'nonce1' parameter defined in Section 4.1.1.
Section 4.1.1.
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 in Note that a client may be required to re-POST the access token in
order to complete a request, since an RS may delete a stored access 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 token (and associated Security Context) at any time, for example due
consumed. This situation is detected by the client when it receives to all storage space being consumed. This situation is detected by
an AS Request Creation Hints response. the client when it receives an AS Request Creation Hints response.
Reposting the same access token will result in deriving a new OSCORE
Security Context to be used with the RS, as different nonces will be
used.
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, with payload in CBOR diagnostic notation without the tag and RS, with payload in CBOR diagnostic notation without the tag and
value abbreviations. The access token has been truncated for value abbreviations. The access token has been truncated for
readability. 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 (CWT) omitted for brevity)', (remainder of access token (CWT) omitted for brevity)',
"nonce1": h'018a278f7faab55a' "nonce1": 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
If the client has already posted a valid token, has already
established a security association with the RS, and wants to update
its access rights, the client can do so by posting the new token
(retrieved from the AS and containing the update of access rights) to
the /authz-info endpoint. The client MUST protect the request using
the OSCORE Security Context established during the first token
exchange. The client MUST only send the access token in the payload,
no nonce is sent. After proper verification (see Section 4.2), the
RS will replace the old token with the new one, maintaining the same
Security Context.
4.1.1. The Nonce 1 Parameter 4.1.1. The Nonce 1 Parameter
This parameter MUST be sent from the client to the RS, together with This parameter MUST be sent from the client to the RS, together with
the access token, if the ace profile used is coap_oscore. The the access token, if the ace profile used is coap_oscore. The
parameter is encoded as a byte string for CBOR-based interactions, parameter is encoded as a byte string for CBOR-based interactions,
and as a string (Base64 encoded binary) for JSON-based interactions. and as a string (Base64 encoded binary) for JSON-based interactions.
This parameter is registered in Section 9.2. This parameter is registered in Section 9.2.
4.2. RS-to-C: 2.01 (Created) 4.2. RS-to-C: 2.01 (Created)
skipping to change at page 19, line 18 skipping to change at page 20, line 27
Header: Created (Code=2.01) Header: Created (Code=2.01)
Content-Format: "application/ace+cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
{ {
"nonce2": h'25a8991cd700ac01' "nonce2": h'25a8991cd700ac01'
} }
Figure 12: Example RS-to-C 2.01 (Created) response Figure 12: Example RS-to-C 2.01 (Created) response
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
(Unauthorized) for any long running request before terminating the
session, when the access token expires.
If the RS receives the token in a OSCORE protected message, it means
that the client is requesting an update of access rights. The RS
MUST discard any nonce in the request, if any was sent. The RS MUST
check that the "kid" of the "cnf" parameter of the new access token
matches the OSCORE Security Context used to protect the message. If
that's the case, the RS MUST discard the old token and associate the
new token to the Security Context identified by "kid". The RS MUST
respond with a 2.01 (Created) response protected with the same
Security Context, with no payload. If any verification fails, the RS
MUST respond with a 4.01 (Unauthorized) error response.
As specified in section 5.8.1 of [I-D.ietf-ace-oauth-authz], when As specified in section 5.8.1 of [I-D.ietf-ace-oauth-authz], when
receiving an updated access token with updated authorization receiving an updated access token with updated authorization
information from the client (see Section 3.1), it is recommended that information from the client (see Section 3.1), it is recommended that
the RS overwrites the previous token, that is only the latest the RS overwrites the previous token, that is only the latest
authorization information in the token received by the RS is valid. authorization information in the token received by the RS is valid.
This simplifies for the RS to keep track of authorization information This simplifies for the RS to keep track of authorization information
for a given client. for a given client.
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
(Unauthorized) for any long running request before terminating the
session, when the access token expires.
4.2.1. The Nonce 2 Parameter 4.2.1. The Nonce 2 Parameter
This parameter MUST be sent from the RS to the Client if the ace This parameter MUST be sent from the RS to the Client if the ace
profile used is coap_oscore. The parameter is encoded as a byte profile used is coap_oscore. The parameter is encoded as a byte
string for CBOR-based interactions, and as a string (Base64 encoded string for CBOR-based interactions, and as a string (Base64 encoded
binary) for JSON-based interactions. This parameter is registered in binary) for JSON-based interactions. This parameter is registered in
Section 9.2 Section 9.2
4.3. OSCORE Setup 4.3. OSCORE Setup
skipping to change at page 20, line 50 skipping to change at page 22, line 23
The RS then uses this Security Context to verify requests 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 [RFC8613]. responses are used, as specified in section 8 of [RFC8613].
Additionally, if OSCORE verification succeeds, the verification of Additionally, if OSCORE verification succeeds, the verification of
access rights is performed as described in section Section 4.4. The access rights is performed as described in section Section 4.4. The
RS MUST NOT use the Security Context after the related token has RS MUST NOT use the Security Context after the related token has
expired, and MUST respond with a unprotected 4.01 (Unauthorized) expired, and MUST respond with a unprotected 4.01 (Unauthorized)
error message to requests received that correspond to a Security error message to requests received that correspond to a Security
Context with an expired token. Context with an expired token.
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 RS 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
[RFC8613]. If OSCORE verification succeeds, and the target resource [RFC8613]. If OSCORE verification succeeds, and the target resource
requires authorization, the RS retrieves the authorization requires authorization, the RS retrieves the authorization
information using the access token associated to the Security information using the access token associated to the Security
Context. The RS then must verify that the authorization information Context. The RS then must verify that the authorization information
covers the resource and the action requested. covers the resource and the action requested.
skipping to change at page 21, line 48 skipping to change at page 23, line 15
Furthermore the requesting entity and the AS communicate through the Furthermore the requesting entity and the AS communicate through the
introspection endpoint as specified in section 5.7 of introspection endpoint as specified in section 5.7 of
[I-D.ietf-ace-oauth-authz] and through the token endpoint as [I-D.ietf-ace-oauth-authz] and through the token endpoint as
specified in section 5.6 of [I-D.ietf-ace-oauth-authz]. specified in section 5.6 of [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 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 has successfully replaced the current security context
with a newer one by posting an access token to the unprotected
/authz-info endpoint at the RS, e.g., by re-posting the same
token, as specified in Section 4.1.
Whenever one more access token is successfully posted to the RS, and
a new Security Context is derived between the client and RS, messages
in transit that were protected with the previous Security Context
might not pass verification, as the old context is discarded. That
means that messages sent shortly before the client posts one more
access token to the RS might not successfully reach the destination.
Analogously, implementations may want to cancel CoAP observations at
the RS registered before the Security Context is replaced, or
conversely they will need to implement a mechanism to ensure that
those observation are to be protected with the newly derived Security
Context.
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 [RFC8613] Furthermore the general security considerations of OSCORE [RFC8613]
also apply to this specific use of the OSCORE protocol. also apply to this specific use of the OSCORE protocol.
skipping to change at page 25, line 50 skipping to change at page 27, line 38
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 and [RFC8613]. document and [RFC8613].
9.5. CWT Confirmation Methods Registry 9.5. 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]: [RFC8747]:
o Confirmation Method Name: "osc" o Confirmation Method Name: "osc"
o Confirmation Method Description: OSCORE_Security_Context carrying o Confirmation Method Description: OSCORE_Security_Context carrying
the parameters for using OSCORE per-message security with implicit the parameters for using OSCORE per-message security with implicit
key confirmation 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]]
skipping to change at page 27, line 28 skipping to change at page 29, line 19
[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-33 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33
(work in progress), February 2020. (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-12 (work in progress), February 2020. params-13 (work in progress), April 2020.
[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 28, line 18 skipping to change at page 30, line 7
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, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
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
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
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>.
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/info/rfc8747>.
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 Optionally define new methods for the client to discover the o Optionally define new methods for the client to discover the
necessary permissions and AS for accessing a resource, different necessary permissions and AS for accessing a resource, different
from the one proposed in: Not specified from the one proposed in: Not specified
o Optionally specify new grant types: Not specified o Optionally specify new grant types: Not specified
skipping to change at page 29, line 30 skipping to change at page 31, line 18
o Specify the communication and security protocol for interactions o Specify the communication and security protocol for interactions
between client and AS: HTTP/CoAP (+ TLS/DTLS/OSCORE) between client and AS: HTTP/CoAP (+ TLS/DTLS/OSCORE)
o Specify how/if the authz-info endpoint is protected, including how o Specify how/if the authz-info endpoint is protected, including how
error responses are protected: Not protected. error responses are protected: Not protected.
o Optionally define other methods of token transport than the authz- o Optionally define other methods of token transport than the authz-
info endpoint: Not defined 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. Special thanks to the responsible area director Ben on this memo. Special thanks to the responsible area director
Kaduk for his extensive review and contributed text. Benjamin Kaduk for his extensive review and contributed text. Ludwig
Seitz worked on this document as part of the CelticNext projects
CyberWI, and CRITISEC with funding from Vinnova.
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
Combitech Combitech
 End of changes. 27 change blocks. 
81 lines changed or deleted 117 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/