draft-ietf-ace-oscore-profile-06.txt   draft-ietf-ace-oscore-profile-07.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: July 7, 2019 RISE SICS AB Expires: August 23, 2019 RISE SICS AB
G. Selander G. Selander
Ericsson AB Ericsson AB
M. Gunnarsson M. Gunnarsson
RISE SICS AB RISE SICS AB
January 3, 2019 February 19, 2019
OSCORE profile of the Authentication and Authorization for Constrained OSCORE profile of the Authentication and Authorization for Constrained
Environments Framework Environments Framework
draft-ietf-ace-oscore-profile-06 draft-ietf-ace-oscore-profile-07
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 July 7, 2019. This Internet-Draft will expire on August 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9.1. ACE OAuth Profile Registry . . . . . . . . . . . . . . . 21 9.1. ACE OAuth Profile Registry . . . . . . . . . . . . . . . 21
9.2. OSCORE Security Context Parameters Registry . . . . . . . 22 9.2. OSCORE Security Context Parameters Registry . . . . . . . 22
9.3. CWT Confirmation Methods Registry . . . . . . . . . . . . 22 9.3. CWT Confirmation Methods Registry . . . . . . . . . . . . 22
9.4. JWT Confirmation Methods Registry . . . . . . . . . . . . 23 9.4. JWT Confirmation Methods Registry . . . . . . . . . . . . 23
9.5. Expert Review Instructions . . . . . . . . . . . . . . . 23 9.5. Expert Review Instructions . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 25 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 25
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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
skipping to change at page 3, line 17 skipping to change at page 3, line 17
OSCORE specifies how to use CBOR Object Signing and Encryption (COSE) OSCORE specifies how to use CBOR Object Signing and Encryption (COSE)
[RFC8152] to secure CoAP messages. Note that OSCORE can be used to [RFC8152] to secure CoAP messages. Note that OSCORE can be used to
secure CoAP messages, as well as HTTP and combinations of HTTP and secure CoAP messages, as well as HTTP and combinations of HTTP and
CoAP; a profile of ACE similar to the one described in this document, CoAP; a profile of ACE similar to the one described in this document,
with the difference of using HTTP instead of CoAP as communication with the difference of using HTTP instead of CoAP as communication
protocol, could be specified analogously to this one. protocol, could be specified analogously to this one.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. These "OPTIONAL" in this document are to be interpreted as described in BCP
words may also appear in this document in lowercase, absent their 14 [RFC2119] [RFC8174] when, and only when, they appear in all
normative meanings. 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].
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
skipping to change at page 11, line 28 skipping to change at page 11, line 28
Figure 8 shows an example CWT, containing the necessary OSCORE Figure 8 shows an example CWT, containing the necessary OSCORE
parameters in the 'cnf' claim for update of access rights, in CBOR parameters in the 'cnf' claim for update of access rights, in CBOR
diagnostic notation without tag and value abbreviations. diagnostic notation without tag and value abbreviations.
{ {
"aud" : "tempSensorInLivingRoom", "aud" : "tempSensorInLivingRoom",
"iat" : "1360189224", "iat" : "1360189224",
"exp" : "1360289224", "exp" : "1360289224",
"scope" : "temperature_h", "scope" : "temperature_h",
"cnf" : { "cnf" : {
"kid" : b64'Qg' "kid" : b64'qA'
} }
} }
Figure 8: Example CWT with OSCORE parameters for update of access Figure 8: Example CWT with OSCORE parameters for update of access
rights. rights.
3.2.1. OSCORE_Security_Context Object 3.2.1. OSCORE_Security_Context Object
An OSCORE_Security_Context is an object that represents part or all An OSCORE_Security_Context is an object that represents part or all
of an OSCORE Security Context (Section 3.1 of of an OSCORE Security Context (Section 3.1 of
skipping to change at page 13, line 16 skipping to change at page 13, line 16
bstr, and has label 1. bstr, and has label 1.
clientId: This parameter identifies a client identifier as a byte clientId: This parameter identifies a client identifier as a byte
string. This identifier is used as OSCORE Sender ID in the client string. This identifier is used as OSCORE Sender ID in the client
and OSCORE Recipient ID in the server. For more information about and OSCORE Recipient ID in the server. For more information about
this field, see section 3.1 of [I-D.ietf-core-object-security]. this field, see section 3.1 of [I-D.ietf-core-object-security].
In JSON, the "clientId" value is a Base64 encoded byte string. In In JSON, the "clientId" value is a Base64 encoded byte string. In
CBOR, the "clientId" type is bstr, and has label 2. CBOR, the "clientId" type is bstr, and has label 2.
serverId: This parameter identifies a server identifier as a byte serverId: This parameter identifies a server identifier as a byte
string. This identifier is used as OSCORE Sender ID in the client string. This identifier is used as OSCORE Sender ID in the server
and OSCORE Recipient ID in the server. For more information about and OSCORE Recipient ID in the client. For more information about
this field, see section 3.1 of [I-D.ietf-core-object-security]. this field, see section 3.1 of [I-D.ietf-core-object-security].
In JSON, the "serverId" value is a Base64 encoded byte string. In In JSON, the "serverId" value is a Base64 encoded byte string. In
CBOR, the "serverId" type is bstr, and has label 3. CBOR, the "serverId" type is bstr, and has label 3.
hkdf: This parameter identifies the OSCORE HKDF Algorithm. For more hkdf: This parameter identifies the OSCORE HKDF Algorithm. For more
information about this field, see section 3.1 of information about this field, see section 3.1 of
[I-D.ietf-core-object-security]. The values used MUST be [I-D.ietf-core-object-security]. The values used MUST be
registered in the IANA "COSE Algorithms" registry and MUST be registered in the IANA "COSE Algorithms" registry and MUST be
HMAC-based HKDF algorithms. The value can either be the integer HMAC-based HKDF algorithms. The value can either be the integer
or the text string value of the HMAC-based HKDF algorithm in the or the text string value of the HMAC-based HKDF algorithm in the
skipping to change at page 14, line 7 skipping to change at page 14, line 7
"salt" value is a Base64 encoded byte string. In CBOR, the "salt" "salt" value is a Base64 encoded byte string. In CBOR, the "salt"
type is bstr, and has label 6. type is bstr, and has label 6.
contextId: This parameter identifies the security context as a byte contextId: This parameter identifies the security context as a byte
string. This identifier is used as OSCORE ID Context. For more string. This identifier is used as OSCORE ID Context. For more
information about this field, see section 3.1 of information about this field, see section 3.1 of
[I-D.ietf-core-object-security]. In JSON, the "contextID" value [I-D.ietf-core-object-security]. In JSON, the "contextID" value
is a Base64 encoded byte string. In CBOR, the "contextID" type is is a Base64 encoded byte string. In CBOR, the "contextID" type is
bstr, and has label 7. bstr, and has label 7.
repl: This parameter is used to carry the OSCORE value, encoded as a rpl: This parameter is used to carry the OSCORE value, encoded as a
bstr. This parameter identifies the OSCORE Replay Window Size and bstr. This parameter identifies the OSCORE Replay Window Size and
Type value, which is a byte string. For more information about Type value, which is a byte string. For more information about
this field, see section 3.1 of [I-D.ietf-core-object-security]. this field, see section 3.1 of [I-D.ietf-core-object-security].
In JSON, the "repl" value is a Base64 encoded byte string. In In JSON, the "rpl" value is a Base64 encoded byte string. In
CBOR, the "repl" type is bstr, and has label 8. CBOR, the "rpl" type is bstr, and has label 8.
An example of JSON OSCORE_Security_Context is given in Figure 9. An example of JSON OSCORE_Security_Context is given in Figure 9.
"OSCORE_Security_Context" : { "OSCORE_Security_Context" : {
"alg" : "AES-CCM-16-64-128", "alg" : "AES-CCM-16-64-128",
"clientId" : b64'qA', "clientId" : b64'qA',
"serverId" : b64'Qg', "serverId" : b64'Qg',
"ms" : b64'+a+Dg2jjU+eIiOFCa9lObw' "ms" : b64'+a+Dg2jjU+eIiOFCa9lObw'
} }
skipping to change at page 16, line 26 skipping to change at page 16, line 26
Figure 10: Example C-to-RS POST /authz-info request using CWT Figure 10: Example C-to-RS POST /authz-info request using CWT
4.2. RS-to-C: 2.01 (Created) 4.2. RS-to-C: 2.01 (Created)
The RS MUST follow the procedures defined in section 5.8.1 of The RS MUST follow the procedures defined in section 5.8.1 of
[I-D.ietf-ace-oauth-authz]: the RS MUST verify the validity of the [I-D.ietf-ace-oauth-authz]: the RS MUST verify the validity of the
token. If the token is valid, the RS MUST respond to the POST token. If the token is valid, the RS MUST respond to the POST
request with 2.01 (Created). If the token is valid but is associated request with 2.01 (Created). If the token is valid but is associated
to claims that the RS cannot process (e.g., an unknown scope), or if to claims that the RS cannot process (e.g., an unknown scope), or if
any of the expected parameters in the OSCORE_Security_Context is any of the expected parameters in the OSCORE_Security_Context is
missing (e.g. any of the mandatory parameters from the AS), the RS missing (e.g. any of the mandatory parameters from the AS), or if any
MUST respond with a response code equivalent to the CoAP code 4.00 parameters received in the OSCORE_Security_Context is unrecognized,
(Bad Request). In the latter case the RS MAY provide additional the RS MUST respond with an error response code equivalent to the
information in the error response, in order to clarify what went CoAP code 4.00 (Bad Request). In the latter two cases, the RS MAY
wrong. The RS MAY make an introspection request to validate the provide additional information in the error response, in order to
token before responding to the POST request to the authz-info clarify what went wrong. The RS MAY make an introspection request to
endpoint. validate the token before 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 send it been previously used with the same input keying material, and send it
within the 2.01 (Created) response. The payload of the 2.01 within the 2.01 (Created) response. The payload of the 2.01
(Created) response MUST be a CBOR map containing the 'nonce' (Created) response MUST be a CBOR map containing the 'nonce'
parameter defined in section 5.1.2 of [I-D.ietf-ace-oauth-authz], set parameter defined in section 5.1.2 of [I-D.ietf-ace-oauth-authz], set
to N2. This profile RECOMMENDS to use a 64-bit long random number as to N2. This profile RECOMMENDS to use a 64-bit long random number as
nonce. Moreover, if the OSCORE_Security_Context in the token did not nonce. Moreover, if the OSCORE_Security_Context in the token did not
contain a 'clientId' parameter, the RS MUST generate an identifier, contain a 'clientId' parameter, the RS MUST generate an identifier,
unique in the set of all its existing client identifiers, and send it unique in the set of all its existing client identifiers, and send it
skipping to change at page 18, line 16 skipping to change at page 18, line 16
If any of the expected parameters is missing (e.g. any of the If any of the expected parameters is missing (e.g. any of the
mandatory parameters from the AS, or the 'clientId', either received mandatory parameters from the AS, or the 'clientId', either received
from the AS or in the 2.01 (Created) response from the RS), the from the AS or in the 2.01 (Created) response from the RS), the
client MUST stop the exchange, and MUST NOT derive the Security client MUST stop the exchange, and MUST NOT derive the Security
Context. The client MAY restart the exchange, to get the correct Context. The client MAY restart the exchange, to get the correct
security material. security material.
The client then uses this Security Context to send requests to RS The client then uses this Security Context to send requests to RS
using OSCORE. In the first request sent to the RS, the client MAY using OSCORE. In the first request sent to the RS, the client MAY
include the kid context, with value ID Context, i.e. N1 concatenated include the kid context if the application needs to, with value ID
with N2. Context, i.e. N1 concatenated with N2.
After sending the 2.01 (Created) response, the RS MUST set the ID After sending the 2.01 (Created) response, the RS MUST set the ID
Context of the Security Context created to communicate with the Context of the Security Context created to communicate with the
client to the concatenation of N1 and N2, in this order: ID Context = client to the concatenation of N1 and N2, in this order: ID Context =
N1 | N2, where | denotes byte string concatenation. The RS MUST set N1 | N2, where | denotes byte string concatenation. The RS MUST set
the Master Secret, Sender ID and Recipient ID from the parameters, the Master Secret, Sender ID and Recipient ID from the parameters,
received from the client in the access token in Section 4.1 after received from the client in the access token in Section 4.1 after
validation of the token as specified in Section 4.2. The RS MUST set validation of the token as specified in Section 4.2. The RS MUST set
the AEAD Algorithm, Master Salt, HKDF, and Replay Window from the the AEAD Algorithm, Master Salt, HKDF, and Replay Window from the
parameters received from the client in the access token in parameters received from the client in the access token in
Section 4.1 after validation of the token as specified in Section 4.1 after validation of the token as specified in
Section 4.2, if present. In case these parameters are omitted, the Section 4.2, if present. In case these parameters are omitted, the
default values are used as described in section 3.2 of default values are used as described in section 3.2 of
[I-D.ietf-core-object-security]. After that, the RS MUST derive the [I-D.ietf-core-object-security]. After that, the RS MUST derive the
complete Security Context following section 3.2.1 of complete Security Context following section 3.2.1 of
[I-D.ietf-core-object-security], and MUST associate this Security [I-D.ietf-core-object-security], and MUST associate this Security
Context with the authorization information from the access token. Context with the authorization information from the access token.
The RS then uses this Security Context to verify the request and send The RS then uses this Security Context to verify the request and send
responses to RS using OSCORE. If OSCORE verification fails, error responses to C using OSCORE. If OSCORE verification fails, error
responses are used, as specified in section 8 of responses are used, as specified in section 8 of
[I-D.ietf-core-object-security]. Additionally, if OSCORE [I-D.ietf-core-object-security]. Additionally, if OSCORE
verification succeeds, the verification of access rights is performed verification succeeds, the verification of access rights is performed
as described in section Section 4.4. The RS MUST NOT use the as described in section Section 4.4. The RS MUST NOT use the
Security Context after the related token has expired, and MUST Security Context after the related token has expired, and MUST
respond with a unprotected 4.01 (Unauthorized) error message. respond with a unprotected 4.01 (Unauthorized) error message.
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
skipping to change at page 24, line 15 skipping to change at page 24, line 15
size. size.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-17 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-21
(work in progress), November 2018. (work in progress), February 2019.
[I-D.ietf-ace-oauth-params] [I-D.ietf-ace-oauth-params]
Seitz, L., "Additional OAuth Parameters for Authorization Seitz, L., "Additional OAuth Parameters for Authorization
in Constrained Environments (ACE)", draft-ietf-ace-oauth- in Constrained Environments (ACE)", draft-ietf-ace-oauth-
params-01 (work in progress), November 2018. params-04 (work in progress), February 2019.
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-15 (work in (OSCORE)", draft-ietf-core-object-security-15 (work in
progress), August 2018. progress), August 2018.
[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,
skipping to change at page 24, line 43 skipping to change at page 24, line 43
[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>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>. May 2018, <https://www.rfc-editor.org/info/rfc8392>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-ace-cwt-proof-of-possession] [I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
 End of changes. 16 change blocks. 
28 lines changed or deleted 33 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/