draft-ietf-ace-oscore-profile-14.txt   draft-ietf-ace-oscore-profile-15.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: June 17, 2021 Combitech Expires: July 30, 2021 Combitech
G. Selander G. Selander
Ericsson AB Ericsson AB
M. Gunnarsson M. Gunnarsson
RISE RISE
December 14, 2020 January 26, 2021
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-14 draft-ietf-ace-oscore-profile-15
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 and proof-of-possession (OSCORE) to provide communication security and proof-of-possession
for a key owned by the client and bound to an OAuth 2.0 access token. for a key owned by the client and bound to an OAuth 2.0 access token.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 June 17, 2021. This Internet-Draft will expire on July 30, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 29 skipping to change at page 2, line 29
3.2.1. The OSCORE_Input_Material . . . . . . . . . . . . . . 12 3.2.1. The OSCORE_Input_Material . . . . . . . . . . . . . . 12
4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 15 4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 15
4.1. C-to-RS: POST to authz-info endpoint . . . . . . . . . . 16 4.1. C-to-RS: POST to authz-info endpoint . . . . . . . . . . 16
4.1.1. The Nonce 1 Parameter . . . . . . . . . . . . . . . . 17 4.1.1. The Nonce 1 Parameter . . . . . . . . . . . . . . . . 17
4.1.2. The ace_client_recipientid Parameter . . . . . . . . 18 4.1.2. The ace_client_recipientid Parameter . . . . . . . . 18
4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 18 4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 18
4.2.1. The Nonce 2 Parameter . . . . . . . . . . . . . . . . 19 4.2.1. The Nonce 2 Parameter . . . . . . . . . . . . . . . . 19
4.2.2. The ace_server_recipientid Parameter . . . . . . . . 20 4.2.2. The ace_server_recipientid Parameter . . . . . . . . 20
4.3. OSCORE Setup . . . . . . . . . . . . . . . . . . . . . . 20 4.3. OSCORE Setup . . . . . . . . . . . . . . . . . . . . . . 20
4.4. Access rights verification . . . . . . . . . . . . . . . 22 4.4. Access rights verification . . . . . . . . . . . . . . . 22
5. Secure Communication with AS . . . . . . . . . . . . . . . . 22 5. Secure Communication with AS . . . . . . . . . . . . . . . . 23
6. Discarding the Security Context . . . . . . . . . . . . . . . 23 6. Discarding the Security Context . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9.1. ACE Profile Registry . . . . . . . . . . . . . . . . . . 26 9.1. ACE Profile Registry . . . . . . . . . . . . . . . . . . 26
9.2. OAuth Parameters Registry . . . . . . . . . . . . . . . . 26 9.2. OAuth Parameters Registry . . . . . . . . . . . . . . . . 26
9.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 27 9.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 27
9.4. OSCORE Security Context Parameters Registry . . . . . . . 27 9.4. OSCORE Security Context Parameters Registry . . . . . . . 27
9.5. CWT Confirmation Methods Registry . . . . . . . . . . . . 28 9.5. CWT Confirmation Methods Registry . . . . . . . . . . . . 28
9.6. JWT Confirmation Methods Registry . . . . . . . . . . . . 28 9.6. JWT Confirmation Methods Registry . . . . . . . . . . . . 28
9.7. Expert Review Instructions . . . . . . . . . . . . . . . 29 9.7. Expert Review Instructions . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . 31 10.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 31 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 31
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
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 the Constrained Application Protocol (CoAP) [RFC7252] to server use the Constrained Application Protocol (CoAP) [RFC7252] to
skipping to change at page 3, line 42 skipping to change at page 3, line 42
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Certain security-related terms such as "authentication", Certain security-related terms such as "authentication",
"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].
Readers are expected to be familiar with the terms and concepts
defined in OSCORE [RFC8613], such as "Security Context" and
"Recipient ID".
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 Binary Object Representation (CBOR) [I-D.ietf-cbor-7049bis] Concise Binary Object Representation (CBOR) [I-D.ietf-cbor-7049bis]
and Concise Data Definition Language (CDDL) [RFC8610] are used in and Concise Data Definition Language (CDDL) [RFC8610] are used in
this specification. CDDL predefined type names, especially bstr for this specification. CDDL predefined type names, especially bstr for
CBOR byte strings and tstr for CBOR text strings, are used CBOR byte strings and tstr for CBOR text strings, are used
extensively in the document. extensively in the document.
skipping to change at page 4, line 28 skipping to change at page 4, line 31
described in detail in the following sections. described in detail in the following sections.
The RS maintains a collection of OSCORE Security Contexts with The RS maintains a collection of OSCORE Security Contexts with
associated authorization information for all the clients that it is associated authorization information for all the clients that it is
communicating with. The authorization information is maintained as communicating with. The authorization information is maintained as
policy that is used as input to processing requests from those policy that is used as input to processing requests from those
clients. clients.
This profile requires a client to retrieve an access token from the This profile requires a client to retrieve an access token from the
AS for the resource it wants to access on an RS, by sending an access AS for the resource it wants to access on an RS, by sending an access
token request to the token endpoint, as specified in section 5.6 of token request to the token endpoint, as specified in section 5.8 of
[I-D.ietf-ace-oauth-authz]. The access token request and response [I-D.ietf-ace-oauth-authz]. The access token request and response
MUST be confidentiality-protected and ensure authenticity. This MUST be confidentiality-protected and ensure authenticity. This
profile RECOMMENDS the use of OSCORE between client and AS, but other profile RECOMMENDS the use of OSCORE between client and AS, to reduce
the number of libraries the client has to support, but other
protocols (such as TLS or DTLS) can be used as well. protocols (such as TLS or DTLS) can be used as well.
Once the client has retrieved the access token, it generates a nonce Once the client has retrieved the access token, it generates a nonce
N1. The client also generates its OSCORE Recipient ID (see N1, defined in this specification (see Section 4.1.1). The client
Section 3.1 of [RFC8613]), ID1, for use with the keying material also generates its own OSCORE Recipient ID ID1 (see Section 3.1 of
associated to the RS. The client posts the token, N1 and its [RFC8613]), for use with the keying material associated to the RS.
Recipient ID to the RS using the authz-info endpoint and mechanisms The client posts the token, N1 and its Recipient ID to the RS using
specified in section 5.8 of [I-D.ietf-ace-oauth-authz] and Content- the authz-info endpoint and mechanisms specified in section 5.8 of
Format = application/ace+cbor. When using this profile, the [I-D.ietf-ace-oauth-authz] and Content-Format = application/ace+cbor.
communication with the authz-info endpoint is not protected, except When using this profile, the communication with the authz-info
for update of access rights. endpoint is not protected, except for update of access rights.
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 and its newly generated OSCORE Recipient which contains a nonce N2 and its newly generated OSCORE Recipient
ID, ID2, for use with the keying material associated to the client. ID, ID2, for use with the keying material associated to the client.
Moreover, the server concatenates the input salt received in the Moreover, the server concatenates the input salt received in the
token, N1, and N2 to obtain the Master Salt of the OSCORE Security token, N1, and N2 to obtain the Master Salt of the OSCORE Security
Context (see section 3 of [RFC8613]). The RS then derives the Context (see section 3 of [RFC8613]). The RS then derives the
complete Security Context associated with the received token from the complete Security Context associated with the received token from the
Master Salt, the OSCORE Recipient ID generated by the client (set as Master Salt, the OSCORE Recipient ID generated by the client (set as
its OSCORE Sender ID), its own OSCORE Recipient ID, plus the its OSCORE Sender ID), its own OSCORE Recipient ID, plus the
parameters received in the access token from the AS, following parameters received in the access token from the AS, following
section 3.2 of [RFC8613]. section 3.2 of [RFC8613].
In a similar way, after receiving the nonce N2, the client In a similar way, after receiving the nonce N2, the client
skipping to change at page 5, line 15 skipping to change at page 5, line 21
parameters received in the access token from the AS, following parameters received in the access token from the AS, following
section 3.2 of [RFC8613]. section 3.2 of [RFC8613].
In a similar way, after receiving the nonce N2, the client In a similar way, after receiving the nonce N2, the client
concatenates the input salt, N1 and N2 to obtain the Master Salt of concatenates the input salt, N1 and N2 to obtain the Master Salt of
the OSCORE Security Context. The client then derives the complete the OSCORE Security Context. The client then derives the complete
Security Context from the Master Salt, the OSCORE Recipient ID Security Context from the Master Salt, the OSCORE Recipient ID
generated by the RS (set as its OSCORE Sender ID), its own OSCORE generated by the RS (set as its OSCORE Sender ID), its own OSCORE
Recipient ID, plus the parameters received from the AS. Recipient ID, plus the parameters received from the AS.
Finally, the client sends a request protected with OSCORE to the RS. Finally, the client starts the communication with the RS by sending a
If the request is successfully verified, the server stores the request protected with OSCORE to the RS. If the request is
complete Security Context state that is ready for use in protecting successfully verified, the server stores the complete Security
messages, and uses it in the response, and in further communications Context state that is ready for use in protecting messages, and uses
with the client, until token deletion, due to e.g. expiration. This it in the response, and in further communications with the client,
Security Context is discarded when a token (whether the same or a until token deletion, due to e.g. expiration. This Security Context
different one) is used to successfully derive a new Security Context is discarded when a token (whether the same or a different one) is
for that client. used to successfully derive a new Security Context for that client.
The use of random nonces during the exchange prevents the reuse of an The use of nonces during the exchange prevents the reuse of an
Authenticated Encryption with Associated Data (AEAD) nonces/key pair Authenticated Encryption with Associated Data (AEAD) nonces/key pair
for two different messages. Two-time pad might otherwise occur when for two different messages. Reuse might otherwise occur when client
client and RS derive a new Security Context from an existing (non- and RS derive a new Security Context from an existing (non- expired)
expired) access token, as might occur when either party has just access token, as might occur when either party has just rebooted, and
rebooted. Instead, by using random nonces as part of the Master might lead to loss of both confidentiality and integrity. Instead,
Salt, the request to the authz-info endpoint posting the same token by using nonces as part of the Master Salt, the request to the authz-
results in a different Security Context, by OSCORE construction, info endpoint posting the same token results in a different Security
since even though the Master Secret, Sender ID and Recipient ID are Context, by OSCORE construction, since even though the Master Secret,
the same, the Master Salt is different (see Section 3.2.1 of Sender ID and Recipient ID are the same, the Master Salt is different
[RFC8613]). Therefore, the main requirement for the nonces is that (see Section 3.2.1 of [RFC8613]). If nonces were reused, a node
they have a good amount of randomness. If random nonces were not reusing 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.
After the whole message exchange has taken place, the client can After the whole message exchange has taken place, the client can
contact the AS to request an update of its access rights, sending a contact the AS to request an update of its access rights, sending a
similar request to the token endpoint that also includes an similar request to the token endpoint that also includes an
identifier so that the AS can find the correct OSCORE security input identifier so that the AS can find the correct OSCORE security input
material it has previously shared with the client. This specific material it has previously shared with the client. This specific
identifier, encoded as a byte string, is assigned by the AS to be identifier, encoded as a byte string, is assigned by the AS to be
unique in the sets of its OSCORE security input materials, and is not unique in the sets of its OSCORE security input materials, and is not
used as input material to derive the full OSCORE Security Context. used as input material to derive the full OSCORE Security Context.
skipping to change at page 7, line 7 skipping to change at page 7, line 7
and response to the token endpoint between client and AS. and response to the token endpoint between client and AS.
Section 3.2 of [RFC8613] defines how to derive a Security Context Section 3.2 of [RFC8613] defines how to derive a Security Context
based on a shared master secret and a set of other parameters, based on a shared master secret and a set of other parameters,
established between client and server, which the client receives from established between client and server, which the client receives from
the AS in this exchange. The proof-of-possession key (pop-key) the AS in this exchange. The proof-of-possession key (pop-key)
included in the response from the AS MUST be used as master secret in included in the response from the AS MUST be used as master secret in
OSCORE. OSCORE.
3.1. C-to-AS: POST to token endpoint 3.1. C-to-AS: POST to token endpoint
The client-to-AS request is specified in Section 5.6.1 of The client-to-AS request is specified in Section 5.8.1 of
[I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
The client must send this POST request to the token endpoint over a The client must send this POST request to the token endpoint over a
secure channel that guarantees authentication, message integrity and secure channel that guarantees authentication, message integrity and
confidentiality (see Section 5). confidentiality (see Section 5).
An example of such a request, with payload in CBOR diagnostic An example of such a request, with payload in CBOR diagnostic
notation without the tag and value abbreviations is reported in notation without the tag and value abbreviations is reported in
Figure 2 Figure 2
skipping to change at page 7, line 34 skipping to change at page 7, 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, with the kid field carrying a to the token endpoint a req_cnf object, with the kid field carrying a
CBOR byte string containing the OSCORE_Input_Material Identifier CBOR byte string containing the OSCORE Input Material Identifier
(assigned as discussed in Section 3.2). This identifier, together (assigned as discussed in Section 3.2). This identifier, together
with other information such as audience (see Section 5.6.1 of with other information such as audience (see Section 5.8.1 of
[I-D.ietf-ace-oauth-authz]), can be used by the AS to determine the [I-D.ietf-ace-oauth-authz]), can be used by the AS to determine the
shared secret bound to the proof-of-possession token and therefore shared secret bound to the proof-of-possession token and therefore
MUST identify a symmetric key that was previously generated by the AS MUST identify a symmetric key that was previously generated by the AS
as a shared secret for the communication between the client and the as a shared secret for the communication between the client and the
RS. The AS MUST verify that the received value identifies a proof- RS. The AS MUST verify that the received value identifies a proof-
of-possession key that has previously been issued to the requesting of-possession key that has previously been issued to the requesting
client. If that is not the case, the Client-to-AS request MUST be client. If that is not the case, the Client-to-AS request MUST be
declined with the error code 'invalid_request' as defined in declined with the error code 'invalid_request' as defined in
Section 5.6.3 of [I-D.ietf-ace-oauth-authz]. Section 5.8.3 of [I-D.ietf-ace-oauth-authz].
An example of such a request, with payload in CBOR diagnostic An example of such a request, with payload in CBOR diagnostic
notation without the tag and value abbreviations is reported in notation without the tag and value abbreviations is reported in
Figure 3 Figure 3
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:
{ {
skipping to change at page 8, line 23 skipping to change at page 8, line 23
"kid" : h'01' "kid" : h'01'
} }
Figure 3: Example C-to-AS POST /token request for updating rights to Figure 3: 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.8.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.8.3 of [I-D.ietf-ace-oauth-authz].
The AS can signal that the use of OSCORE is REQUIRED for a specific The AS can signal that the use of OSCORE is REQUIRED for a specific
access token by including the "profile" parameter with the value access token by including the "profile" parameter with the value
"coap_oscore" in the access token response. This means that the "coap_oscore" in the access token response. This means that the
client MUST use OSCORE towards all resource servers for which this client MUST use OSCORE towards all resource servers for which this
access token is valid, and follow Section 4.3 to derive the security access token is valid, and follow Section 4.3 to derive the security
context to run OSCORE. Usually it is assumed that constrained context to run OSCORE. Usually it is assumed that constrained
devices will be pre-configured with the necessary profile, so that devices will be pre-configured with the necessary profile, so that
this kind of profile signaling can be omitted. this kind of profile signaling can be omitted.
skipping to change at page 13, line 48 skipping to change at page 13, line 48
| contextId | 6 | byte string | | OSCORE ID | | contextId | 6 | byte string | | OSCORE ID |
| | | | | Context | | | | | | Context |
| | | | | value | | | | | | value |
+-----------+-------+-------------+-------------------+-------------+ +-----------+-------+-------------+-------------------+-------------+
Table 1: OSCORE_Input_Material Parameters Table 1: OSCORE_Input_Material Parameters
id: This parameter identifies the OSCORE_Input_Material and is id: This parameter identifies the OSCORE_Input_Material and is
encoded as a byte string. In JSON, the "id" value is a Base64 encoded as a byte string. In JSON, the "id" value is a Base64
encoded byte string. In CBOR, the "id" type is byte string, and encoded byte string. In CBOR, the "id" type is byte string, and
has label 8. has label 0.
version: This parameter identifies the OSCORE Version number, which version: This parameter identifies the OSCORE Version number, which
is an unsigned integer. For more information about this field, is an unsigned integer. For more information about this field,
see section 5.4 of [RFC8613]. In JSON, the "version" value is an see section 5.4 of [RFC8613]. In JSON, the "version" value is an
integer. In CBOR, the "version" type is integer, and has label 0. integer. In CBOR, the "version" type is integer, and has label 1.
ms: This parameter identifies the OSCORE Master Secret value, which ms: This parameter identifies the OSCORE Master Secret value, which
is a byte string. For more information about this field, see is a byte string. For more information about this field, see
section 3.1 of [RFC8613]. In JSON, the "ms" value is a Base64 section 3.1 of [RFC8613]. In JSON, the "ms" value is a Base64
encoded byte string. In CBOR, the "ms" type is byte string, and encoded byte string. In CBOR, the "ms" type is byte string, and
has label 1. has label 2.
hkdf: This parameter identifies the OSCORE HKDF Algorithm. For more hkdf: This parameter identifies the OSCORE HKDF Algorithm. For more
information about this field, see section 3.1 of [RFC8613]. The information about this field, see section 3.1 of [RFC8613]. The
values used MUST be registered in the IANA "COSE Algorithms" values used MUST be registered in the IANA "COSE Algorithms"
registry (see [COSE.Algorithms]) and MUST be HMAC-based HKDF registry (see [COSE.Algorithms]) and MUST be HMAC-based HKDF
algorithms. The value can either be the integer or the text algorithms. The value can either be the integer or the text
string value of the HMAC-based HKDF algorithm in the "COSE string value of the HMAC-based HKDF algorithm in the "COSE
Algorithms" registry. In JSON, the "hkdf" value is a case- Algorithms" registry. In JSON, the "hkdf" value is a case-
sensitive ASCII string or an integer. In CBOR, the "hkdf" type is sensitive ASCII string or an integer. In CBOR, the "hkdf" type is
text string or integer, and has label 4. text string or integer, and has label 3.
alg: This parameter identifies the OSCORE AEAD Algorithm. For more alg: This parameter identifies the OSCORE AEAD Algorithm. For more
information about this field, see section 3.1 of [RFC8613] The information about this field, see section 3.1 of [RFC8613] The
values used MUST be registered in the IANA "COSE Algorithms" values used MUST be registered in the IANA "COSE Algorithms"
registry (see [COSE.Algorithms]) and MUST be AEAD algorithms. The registry (see [COSE.Algorithms]) and MUST be AEAD algorithms. The
value can either be the integer or the text string value of the value can either be the integer or the text string value of the
HMAC-based HKDF algorithm in the "COSE Algorithms" registry. In HMAC-based HKDF algorithm in the "COSE Algorithms" registry. In
JSON, the "alg" value is a case-sensitive ASCII string or an JSON, the "alg" value is a case-sensitive ASCII string or an
integer. In CBOR, the "alg" type is text string or integer, and integer. In CBOR, the "alg" type is text string or integer, and
has label 5. has label 4.
salt: This parameter identifies an input to the OSCORE Master Salt salt: This parameter identifies an input to the OSCORE Master Salt
value, which is a byte string. For more information about this value, which is a byte string. For more information about this
field, see section 3.1 of [RFC8613]. In JSON, the "salt" value is field, see section 3.1 of [RFC8613]. In JSON, the "salt" value is
a Base64 encoded byte string. In CBOR, the "salt" type is byte a Base64 encoded byte string. In CBOR, the "salt" type is byte
string, and has label 6. string, and has label 5.
contextId: This parameter identifies the security context as a byte contextId: This parameter identifies the security context as a byte
string. This identifier is used as OSCORE ID Context. For more string. This identifier is used as OSCORE ID Context. For more
information about this field, see section 3.1 of [RFC8613]. In information about this field, see section 3.1 of [RFC8613]. In
JSON, the "contextID" value is a Base64 encoded byte string. In JSON, the "contextID" value is a Base64 encoded byte string. In
CBOR, the "contextID" type is byte string, and has label 7. CBOR, the "contextID" type is byte string, and has label 6.
An example of JSON OSCORE_Input_Material is given in Figure 9. An example of JSON OSCORE_Input_Material is given in Figure 9.
"osc" : { "osc" : {
"alg" : "AES-CCM-16-64-128", "alg" : "AES-CCM-16-64-128",
"id" : b64'AQ==' "id" : b64'AQ=='
"ms" : b64'+a+Dg2jjU+eIiOFCa9lObw' "ms" : b64'+a+Dg2jjU+eIiOFCa9lObw'
} }
Figure 9: Example JSON OSCORE_Input_Material Figure 9: Example JSON OSCORE_Input_Material
skipping to change at page 15, line 49 skipping to change at page 15, line 49
This security context is used to protect all future communication This security context is used to protect all future communication
between client and RS using OSCORE, as long as the access token is between client and RS using OSCORE, as long as the access token is
valid. valid.
Note that the RS and client authenticates each other by generating Note that the RS and client authenticates each other 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
to generate a valid OSCORE Security Context and thus not be able to to generate a valid OSCORE Security Context and thus not be able to
prove possession of the pop-key. Additionally, the mutual prove possession of the pop-key. Additionally, the mutual
authentication is only achieved after the client has successfully authentication is only achieved after the client has successfully
verified a response from the RS protectd with the generated OSCORE verified a response from the RS protected with the generated OSCORE
Security Context. Security Context.
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 value very unlikely to have been The client MUST generate a nonce value very unlikely to have been
previously used with the same input keying material. This profile previously used with the same input keying material. This profile
RECOMMENDS to use a 64-bit long random number as nonce's value. The RECOMMENDS to use a 64-bit long random number as nonce's value. The
client MUST store the nonce N1 as long as the response from the RS is client MUST store the nonce N1 as long as the response from the RS is
not received and the access token related to it is still valid (to not received and the access token related to it is still valid (to
the best of the client's knowledge). the best of the client's knowledge).
skipping to change at page 18, line 28 skipping to change at page 18, line 28
[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 is missing (e.g., any of the mandatory any of the expected parameters is missing (e.g., any of the mandatory
parameters from the AS or the identifier 'id1'), or if any parameters parameters from the AS or the identifier 'id1'), or if any parameters
received in the 'osc' field is unrecognized, the RS must respond with received in the 'osc' field is unrecognized, the RS must respond with
an error response code equivalent to the CoAP code 4.00 (Bad an error response code equivalent to the CoAP code 4.00 (Bad
Request). In the latter two cases, the RS may provide additional Request). In the latter two cases, the RS may provide additional
information in the error response, in order to clarify what went information in the error response, in order to clarify what went
wrong. The RS may make an introspection request (see Section 5.7.1 wrong. The RS may make an introspection request (see Section 5.9.1
of [I-D.ietf-ace-oauth-authz]) to validate the token before of [I-D.ietf-ace-oauth-authz]) to validate the token before
responding to the POST request to the authz-info endpoint. responding to the POST request to the 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 its own been previously used with the same input keying material, and its own
Recipient ID, ID2. The RS makes sure that ID2 does not collide with Recipient ID, ID2. The RS makes sure that ID2 does not collide with
any of its Recipient IDs. The RS MUST ensure that ID2 is different any of its Recipient IDs. The RS MUST ensure that ID2 is different
from the value received in the ace_client_recipientid parameter. The from the value received in the ace_client_recipientid parameter. The
RS sends N2 and ID2 within the 2.01 (Created) response. The payload RS sends N2 and ID2 within the 2.01 (Created) response. The payload
of the 2.01 (Created) response MUST be a CBOR map containing the of the 2.01 (Created) response MUST be a CBOR map containing the
skipping to change at page 21, line 32 skipping to change at page 21, line 32
present. In case an optional parameter is omitted, the default value present. In case an optional parameter is omitted, the default value
SHALL be used as described in sections 3.2 and 5.4 of [RFC8613]. SHALL be used as described in sections 3.2 and 5.4 of [RFC8613].
After that, the client MUST derive the complete Security Context After that, the client MUST derive the complete Security Context
following section 3.2.1 of [RFC8613]. From this point on, the client following section 3.2.1 of [RFC8613]. From this point on, the client
MUST use this Security Context to communicate with the RS when MUST use this Security Context to communicate with the RS when
accessing the resources as specified by the authorization accessing the resources as specified by the authorization
information. 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 RS), or if mandatory parameters from the AS or the RS), or if
ace_client_recipientid equals ace_server_recipientid, then the client ace_client_recipientid equals ace_server_recipientid (and as a
MUST stop the exchange, and MUST NOT derive the Security Context. consequence the Sender and Recipient Keys derived would be equal, see
The client MAY restart the exchange, to get the correct security section 3.3 of [RFC8613]), then the client MUST stop the exchange,
material. and MUST NOT derive the Security Context. The client MAY restart the
exchange, to get the correct security material.
The client then uses this Security Context to send requests to the RS The client then uses this Security Context to send requests to the RS
using OSCORE. using OSCORE.
After sending the 2.01 (Created) response, the RS MUST set the Master After sending the 2.01 (Created) response, the RS MUST set the Master
Salt of the Security Context created to communicate with the client Salt of the Security Context created to communicate with the client
to the concatenation of salt, N1, and N2, in the same way described to the concatenation of salt, N1, and N2, in the same way described
above. An example of Master Salt construction using CBOR encoding is above. An example of Master Salt construction using CBOR encoding is
given in Figure 12 and using Base64 encoding is given in Figure 13. given in Figure 12 and using Base64 encoding is given in Figure 13.
The RS MUST set the Sender ID from the ace_client_recipientid The RS MUST set the Sender ID from the ace_client_recipientid
skipping to change at page 22, line 49 skipping to change at page 23, line 7
[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.
5. Secure Communication with AS 5. Secure Communication with AS
As specified in the ACE framework (section 5.7 of As specified in the ACE framework (section 5.9 of
[I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or client) [I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or client)
and the AS communicates via the introspection or token endpoint. The and the AS communicates via the introspection or token endpoint. The
use of CoAP and OSCORE ([RFC8613]) for this communication is use of CoAP and OSCORE ([RFC8613]) for this communication is
RECOMMENDED in this profile; other protocols (such as HTTP and DTLS RECOMMENDED in this profile; other protocols (such as HTTP and DTLS
or TLS) MAY be used instead. or TLS) MAY be used instead.
If OSCORE is used, the requesting entity and the AS are expected to If OSCORE is used, the requesting entity and the AS are expected to
have pre-established security contexts in place. How these security have pre-established security contexts in place. How these security
contexts are established is out of scope for this profile. contexts are established is out of scope for this profile.
Furthermore the requesting entity and the AS communicate 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.9 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.8 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.
skipping to change at page 24, line 47 skipping to change at page 25, line 4
provided by OSCORE. provided by OSCORE.
Since the use of nonces in the exchange guarantees uniqueness of AEAD Since the use of nonces in the exchange guarantees uniqueness of AEAD
keys and nonces, it is REQUIRED that nonces are not reused with the keys and nonces, it is REQUIRED that nonces are not reused with the
same input keying material even in case of re-boots. This document same input keying material even in case of re-boots. This document
RECOMMENDS the use of 64 bit random nonces. Considering the birthday RECOMMENDS the use of 64 bit random nonces. Considering the birthday
paradox, the average collision for each nonce will happen after 2^32 paradox, the average collision for each nonce will happen after 2^32
messages, which is considerably more token provisionings than messages, which is considerably more token provisionings than
expected for intended applications. If applications use something expected for intended applications. If applications use something
else, such as a counter, they need to guarantee that reboot and loss else, such as a counter, they need to guarantee that reboot and loss
of state on either node does not provoke re-use. If that is not of state on either node does not provoke reuse. If that is not
guaranteed, nodes are susceptible to re-use of AEAD (nonces, keys) guaranteed, nodes are susceptible to reuse of AEAD (nonces, keys)
pairs, especially since an on-path attacker can cause the client to pairs, especially since an on-path attacker can cause the client to
use an arbitrary nonce for Security Context establishment by use an arbitrary nonce for Security Context establishment by
replaying client-to-server messages. replaying client-to-server messages.
This profile recommends that the RS maintains a single access token This profile recommends that the RS maintains a single access token
for each client. The use of multiple access tokens for a single for each client. The use of multiple access tokens for a single
client increases the strain on the resource server as it must client increases the strain on the resource server as it must
consider every access token and calculate the actual permissions of consider every access token and calculate the actual permissions of
the client. Also, tokens indicating different or disjoint the client. Also, tokens indicating different or disjoint
permissions from each other may lead the server to enforce wrong permissions from each other may lead the server to enforce wrong
permissions. If one of the access tokens expires earlier than permissions. If one of the access tokens expires earlier than
others, the resulting permissions may offer insufficient protection. others, the resulting permissions may offer insufficient protection.
Developers should avoid using multiple access tokens for a same Developers should avoid using multiple access tokens for a same
client. client.
If a single OSCORE_Input_Material is used with multiple RSs, the RSs If a single OSCORE Input Material is used with multiple RSs, the RSs
can impersonate the client to one of the other RS, and impersonate can impersonate the client to one of the other RS, and impersonate
another RS to the client. If a master secret is used with several another RS to the client. If a master secret is used with several
clients, the clients can impersonate RS to one of the other clients. clients, the clients can impersonate RS to one of the other clients.
Similarly if symmetric keys are used to integrity protect the token Similarly if symmetric keys are used to integrity protect the token
between AS and RS and the token can be used with multiple RSs, the between AS and RS and the token can be used with multiple RSs, the
RSs can impersonate AS to one of the other RS. If the token key is RSs can impersonate AS to one of the other RS. If the token key is
used for any other communication between the RSs and AS, the RSs can used for any other communication between the RSs and AS, the RSs can
impersonate each other to the AS. impersonate each other to the AS.
8. Privacy Considerations 8. Privacy Considerations
 End of changes. 36 change blocks. 
64 lines changed or deleted 70 lines changed or added

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