< draft-ietf-ace-oauth-authz-29.txt   draft-ietf-ace-oauth-authz-30.txt >
ACE Working Group L. Seitz ACE Working Group L. Seitz
Internet-Draft Combitech Internet-Draft Combitech
Intended status: Standards Track G. Selander Intended status: Standards Track G. Selander
Expires: June 16, 2020 Ericsson Expires: July 14, 2020 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
December 14, 2019 January 11, 2020
Authentication and Authorization for Constrained Environments (ACE) Authentication and Authorization for Constrained Environments (ACE)
using the OAuth 2.0 Framework (ACE-OAuth) using the OAuth 2.0 Framework (ACE-OAuth)
draft-ietf-ace-oauth-authz-29 draft-ietf-ace-oauth-authz-30
Abstract Abstract
This specification defines a framework for authentication and This specification defines a framework for authentication and
authorization in Internet of Things (IoT) environments called ACE- authorization in Internet of Things (IoT) environments called ACE-
OAuth. The framework is based on a set of building blocks including OAuth. The framework is based on a set of building blocks including
OAuth 2.0 and the Constrained Application Protocol (CoAP), thus OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
transforming a well-known and widely used authorization solution into transforming a well-known and widely used authorization solution into
a form suitable for IoT devices. Existing specifications are used a form suitable for IoT devices. Existing specifications are used
where possible, but extensions are added and profiles are defined to where possible, but extensions are added and profiles are defined to
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 16, 2020. This Internet-Draft will expire on July 14, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 11, line 35 skipping to change at page 11, line 35
DTLS [RFC6347], [I-D.ietf-tls-dtls13] and OSCORE [RFC8613] are DTLS [RFC6347], [I-D.ietf-tls-dtls13] and OSCORE [RFC8613] are
mentioned as examples, other protocols fulfilling the requirements mentioned as examples, other protocols fulfilling the requirements
from Section 6.5 are also applicable. from Section 6.5 are also applicable.
4. Protocol Interactions 4. Protocol Interactions
The ACE framework is based on the OAuth 2.0 protocol interactions The ACE framework is based on the OAuth 2.0 protocol interactions
using the token endpoint and optionally the introspection endpoint. using the token endpoint and optionally the introspection endpoint.
A client obtains an access token, and optionally a refresh token, A client obtains an access token, and optionally a refresh token,
from an AS using the token endpoint and subsequently presents the from an AS using the token endpoint and subsequently presents the
access token to a RS to gain access to a protected resource. In most access token to an RS to gain access to a protected resource. In
deployments the RS can process the access token locally, however in most deployments the RS can process the access token locally, however
some cases the RS may present it to the AS via the introspection in some cases the RS may present it to the AS via the introspection
endpoint to get fresh information. These interactions are shown in endpoint to get fresh information. These interactions are shown in
Figure 1. An overview of various OAuth concepts is provided in Figure 1. An overview of various OAuth concepts is provided in
Section 3.1. Section 3.1.
The OAuth 2.0 framework defines a number of "protocol flows" via The OAuth 2.0 framework defines a number of "protocol flows" via
grant types, which have been extended further with extensions to grant types, which have been extended further with extensions to
OAuth 2.0 (such as [RFC7521] and [RFC8628]). What grant types works OAuth 2.0 (such as [RFC7521] and [RFC8628]). What grant types works
best depends on the usage scenario and [RFC7744] describes many best depends on the usage scenario and [RFC7744] describes many
different IoT use cases but there are two preferred grant types, different IoT use cases but there are two preferred grant types,
namely the Authorization Code Grant (described in Section 4.1 of namely the Authorization Code Grant (described in Section 4.1 of
skipping to change at page 19, line 39 skipping to change at page 19, line 39
5.1.2.1. The Client-Nonce Parameter 5.1.2.1. The Client-Nonce Parameter
If the RS does not synchronize its clock with the AS, it could be If the RS does not synchronize its clock with the AS, it could be
tricked into accepting old access tokens, that are either expired or tricked into accepting old access tokens, that are either expired or
have been compromised. In order to ensure some level of token have been compromised. In order to ensure some level of token
freshness in that case, the RS can use the "cnonce" (client-nonce) freshness in that case, the RS can use the "cnonce" (client-nonce)
parameter. The processing requirements for this parameter are as parameter. The processing requirements for this parameter are as
follows: follows:
o A RS sending a "cnonce" parameter in an AS Request Creation Hints o An RS sending a "cnonce" parameter in an AS Request Creation Hints
message MUST store information to validate that a given cnonce is message MUST store information to validate that a given cnonce is
fresh. How this is implemented internally is out of scope for fresh. How this is implemented internally is out of scope for
this specification. Expiration of client-nonces should be based this specification. Expiration of client-nonces should be based
roughly on the time it would take a client to obtain an access roughly on the time it would take a client to obtain an access
token after receiving the AS Request Creation Hints message, with token after receiving the AS Request Creation Hints message, with
some allowance for unexpected delays. some allowance for unexpected delays.
o A client receiving a "cnonce" parameter in an AS Request Creation o A client receiving a "cnonce" parameter in an AS Request Creation
Hints message MUST include this in the parameters when requesting Hints message MUST include this in the parameters when requesting
an access token at the AS, using the "cnonce" parameter from an access token at the AS, using the "cnonce" parameter from
Section 5.6.4.4. Section 5.6.4.4.
o If an AS grants an access token request containing a "cnonce" o If an AS grants an access token request containing a "cnonce"
parameter, it MUST include this value in the access token, using parameter, it MUST include this value in the access token, using
the "cnonce" claim specified in Section 5.8. the "cnonce" claim specified in Section 5.8.
o A RS that is using the client-nonce mechanism and that receives an o An RS that is using the client-nonce mechanism and that receives
access token MUST verify that this token contains a cnonce claim, an access token MUST verify that this token contains a cnonce
with a client-nonce value that is fresh according to the claim, with a client-nonce value that is fresh according to the
information stored at the first step above. If the cnonce claim information stored at the first step above. If the cnonce claim
is not present or if the cnonce claim value is not fresh, the RS is not present or if the cnonce claim value is not fresh, the RS
MUST discard the access token. If this was an interaction with MUST discard the access token. If this was an interaction with
the authz-info endpoint the RS MUST also respond with an error the authz-info endpoint the RS MUST also respond with an error
message using a response code equivalent to the CoAP code 4.01 message using a response code equivalent to the CoAP code 4.01
(Unauthorized). (Unauthorized).
5.2. Authorization Grants 5.2. Authorization Grants
To request an access token, the client obtains authorization from the To request an access token, the client obtains authorization from the
skipping to change at page 28, line 5 skipping to change at page 28, line 5
for the error response. for the error response.
o The parameters "error", "error_description" and "error_uri" MUST o The parameters "error", "error_description" and "error_uri" MUST
be abbreviated using the codes specified in Figure 12, when a CBOR be abbreviated using the codes specified in Figure 12, when a CBOR
encoding is used. encoding is used.
o The error code (i.e., value of the "error" parameter) MUST be o The error code (i.e., value of the "error" parameter) MUST be
abbreviated as specified in Figure 10, when a CBOR encoding is abbreviated as specified in Figure 10, when a CBOR encoding is
used. used.
/------------------------+-------------\ /---------------------------+-------------\
| Name | CBOR Values | | Name | CBOR Values |
|------------------------+-------------| |---------------------------+-------------|
| invalid_request | 1 | | invalid_request | 1 |
| invalid_client | 2 | | invalid_client | 2 |
| invalid_grant | 3 | | invalid_grant | 3 |
| unauthorized_client | 4 | | unauthorized_client | 4 |
| unsupported_grant_type | 5 | | unsupported_grant_type | 5 |
| invalid_scope | 6 | | invalid_scope | 6 |
| unsupported_pop_key | 7 | | unsupported_pop_key | 7 |
| incompatible_profiles | 8 | | incompatible_ace_profiles | 8 |
\------------------------+-------------/ \---------------------------+-------------/
Figure 10: CBOR abbreviations for common error codes Figure 10: CBOR abbreviations for common error codes
In addition to the error responses defined in OAuth 2.0, the In addition to the error responses defined in OAuth 2.0, the
following behavior MUST be implemented by the AS: following behavior MUST be implemented by the AS:
o If the client submits an asymmetric key in the token request that o If the client submits an asymmetric key in the token request that
the RS cannot process, the AS MUST reject that request with a the RS cannot process, the AS MUST reject that request with a
response code equivalent to the CoAP code 4.00 (Bad Request) response code equivalent to the CoAP code 4.00 (Bad Request)
including the error code "unsupported_pop_key" defined in including the error code "unsupported_pop_key" defined in
Figure 10. Figure 10.
o If the client and the RS it has requested an access token for do o If the client and the RS it has requested an access token for do
not share a common profile, the AS MUST reject that request with a not share a common profile, the AS MUST reject that request with a
response code equivalent to the CoAP code 4.00 (Bad Request) response code equivalent to the CoAP code 4.00 (Bad Request)
including the error code "incompatible_profiles" defined in including the error code "incompatible_ace_profiles" defined in
Figure 10. Figure 10.
5.6.4. Request and Response Parameters 5.6.4. Request and Response Parameters
This section provides more detail about the new parameters that can This section provides more detail about the new parameters that can
be used in access token requests and responses, as well as be used in access token requests and responses, as well as
abbreviations for more compact encoding of existing parameters and abbreviations for more compact encoding of existing parameters and
common parameter values. common parameter values.
5.6.4.1. Grant Type 5.6.4.1. Grant Type
skipping to change at page 29, line 45 skipping to change at page 29, line 45
Profiles of this framework MUST define the communication protocol and Profiles of this framework MUST define the communication protocol and
the communication security protocol between the client and the RS. the communication security protocol between the client and the RS.
The security protocol MUST provide encryption, integrity and replay The security protocol MUST provide encryption, integrity and replay
protection. It MUST also provide a binding between requests and protection. It MUST also provide a binding between requests and
responses. Furthermore profiles MUST define a list of allowed proof- responses. Furthermore profiles MUST define a list of allowed proof-
of-possession methods, if they support proof-of-possession tokens. of-possession methods, if they support proof-of-possession tokens.
A profile MUST specify an identifier that MUST be used to uniquely A profile MUST specify an identifier that MUST be used to uniquely
identify itself in the "ace_profile" parameter. The textual identify itself in the "ace_profile" parameter. The textual
representation of the profile identifier is just intended for human representation of the profile identifier is intended for human
readability and MUST NOT be used in parameters and claims. Profiles readability and for JSON-based interactions, it MUST NOT be used for
MUST register their identifier in the registry defined in CBOR-based interactions. Profiles MUST register their identifier in
Section 8.7. the registry defined in Section 8.7.
Profiles MAY define additional parameters for both the token request Profiles MAY define additional parameters for both the token request
and the Access Information in the access token response in order to and the Access Information in the access token response in order to
support negotiation or signaling of profile specific parameters. support negotiation or signaling of profile specific parameters.
Clients that want the AS to provide them with the "ace_profile" Clients that want the AS to provide them with the "ace_profile"
parameter in the access token response can indicate that by sending a parameter in the access token response can indicate that by sending a
ace_profile parameter with a null value in the access token request. ace_profile parameter with a null value (for CBOR-based interactions)
or an empty string (for JSON based interactions) in the access token
request.
5.6.4.4. Client-Nonce 5.6.4.4. Client-Nonce
This parameter MUST be sent from the client to the AS, if it This parameter MUST be sent from the client to the AS, if it
previously received a "cnonce" parameter in the AS Request Creation previously received a "cnonce" parameter in the AS Request Creation
Hints Section 5.1.2. The parameter is encoded as a byte string and Hints Section 5.1.2. The parameter is encoded as a byte string for
copies the value from the cnonce parameter in the AS Request Creation CBOR-based interactions, and as a string (Base64 encoded binary) for
Hints. JSON-based interactions. It MUST copy the value from the cnonce
parameter in the AS Request Creation Hints.
5.6.5. Mapping Parameters to CBOR 5.6.5. Mapping Parameters to CBOR
If CBOR encoding is used, all OAuth parameters in access token If CBOR encoding is used, all OAuth parameters in access token
requests and responses MUST be mapped to CBOR types as specified in requests and responses MUST be mapped to CBOR types as specified in
the registry defined by Section 8.9, using the given integer the registry defined by Section 8.9, using the given integer
abbreviation for the map keys. abbreviation for the map keys.
Note that we have aligned the abbreviations corresponding to claims Note that we have aligned the abbreviations corresponding to claims
with the abbreviations defined in [RFC8392]. with the abbreviations defined in [RFC8392].
skipping to change at page 32, line 32 skipping to change at page 32, line 32
optional parameters representing additional context that is known by optional parameters representing additional context that is known by
the requesting entity to aid the AS in its response MAY be included. the requesting entity to aid the AS in its response MAY be included.
For CoAP-based interaction, all messages MUST use the content type For CoAP-based interaction, all messages MUST use the content type
"application/ace+cbor", while for HTTP-based interactions the "application/ace+cbor", while for HTTP-based interactions the
equivalent media type "application/ace+cbor" MUST be used. equivalent media type "application/ace+cbor" MUST be used.
The same parameters are required and optional as in Section 2.1 of The same parameters are required and optional as in Section 2.1 of
[RFC7662]. [RFC7662].
For example, Figure 13 shows a RS calling the token introspection For example, Figure 13 shows an RS calling the token introspection
endpoint at the AS to query about an OAuth 2.0 proof-of-possession endpoint at the AS to query about an OAuth 2.0 proof-of-possession
token. Note that object security based on OSCORE [RFC8613] is token. Note that object security based on OSCORE [RFC8613] is
assumed in this example, therefore the Content-Format is assumed in this example, therefore the Content-Format is
"application/oscore". Figure 14 shows the decoded payload. "application/oscore". Figure 14 shows the decoded payload.
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "as.example.com" Uri-Host: "as.example.com"
Uri-Path: "introspect" Uri-Path: "introspect"
OSCORE: 0x09, 0x05, 0x25 OSCORE: 0x09, 0x05, 0x25
Content-Format: "application/oscore" Content-Format: "application/oscore"
skipping to change at page 39, line 42 skipping to change at page 39, line 42
The POST method SHOULD NOT be allowed on children of the authz-info The POST method SHOULD NOT be allowed on children of the authz-info
endpoint. endpoint.
The RS SHOULD implement rate limiting measures to mitigate attacks The RS SHOULD implement rate limiting measures to mitigate attacks
aiming to overload the processing capacity of the RS by repeatedly aiming to overload the processing capacity of the RS by repeatedly
submitting tokens. For CoAP-based communication the RS could use the submitting tokens. For CoAP-based communication the RS could use the
mechanisms from [RFC8516] to indicate that it is overloaded. mechanisms from [RFC8516] to indicate that it is overloaded.
5.8.2. Client Requests to the RS 5.8.2. Client Requests to the RS
Before sending a request to a RS, the client MUST verify that the Before sending a request to an RS, the client MUST verify that the
keys used to protect this communication are still valid. See keys used to protect this communication are still valid. See
Section 5.8.4 for details on how the client determines the validity Section 5.8.4 for details on how the client determines the validity
of the keys used. of the keys used.
If an RS receives a request from a client, and the target resource If an RS receives a request from a client, and the target resource
requires authorization, the RS MUST first verify that it has an requires authorization, the RS MUST first verify that it has an
access token that authorizes this request, and that the client has access token that authorizes this request, and that the client has
performed the proof-of-possession binding that token to the request. performed the proof-of-possession binding that token to the request.
The response code MUST be 4.01 (Unauthorized) in case the client has The response code MUST be 4.01 (Unauthorized) in case the client has
skipping to change at page 41, line 10 skipping to change at page 41, line 10
introspection request as specified in Section 5.7. This requires introspection request as specified in Section 5.7. This requires
the RS to have a reliable network connection to the AS and to be the RS to have a reliable network connection to the AS and to be
able to handle two secure sessions in parallel (C to RS and RS to able to handle two secure sessions in parallel (C to RS and RS to
AS). AS).
o In order to support token expiration for devices that have no o In order to support token expiration for devices that have no
reliable way of synchronizing their internal clocks, this reliable way of synchronizing their internal clocks, this
specification defines the following approach: The claim "exi" specification defines the following approach: The claim "exi"
("expires in") can be used, to provide the RS with the lifetime of ("expires in") can be used, to provide the RS with the lifetime of
the token in seconds from the time the RS first receives the the token in seconds from the time the RS first receives the
token. Processing this claim requires that the RS does the token. For CBOR-based interaction this parameter is encoded as
following: unsigned integer, while JSON-based interactions encode this as
JSON number.
o Processing this claim requires that the RS does the following:
* For each token the RS receives, that contains an "exi" claim: * For each token the RS receives, that contains an "exi" claim:
Keep track of the time it received that token and revisit that Keep track of the time it received that token and revisit that
list regularly to expunge expired tokens. list regularly to expunge expired tokens.
* Keep track of the identifiers of tokens containing the "exi" * Keep track of the identifiers of tokens containing the "exi"
claim that have expired (in order to avoid accepting them claim that have expired (in order to avoid accepting them
again). again).
If a token that authorizes a long running request such as a CoAP If a token that authorizes a long running request such as a CoAP
skipping to change at page 46, line 44 skipping to change at page 46, line 44
The RS needs to keep state about expired tokens that used "exi" in The RS needs to keep state about expired tokens that used "exi" in
order to be sure not to accept it again. Attacker may use this to order to be sure not to accept it again. Attacker may use this to
deplete the RS's storage resources. deplete the RS's storage resources.
The first drawback is inherent to the deployment scenario and the The first drawback is inherent to the deployment scenario and the
"exi" solution. It can therefore not be mitigated without requiring "exi" solution. It can therefore not be mitigated without requiring
the the RS be online at times. The second drawback can be mitigated the the RS be online at times. The second drawback can be mitigated
by regularly storing the value of "exi" counters to persistent by regularly storing the value of "exi" counters to persistent
memory. The third problem can be mitigated by the AS, by assigning memory. The third problem can be mitigated by the AS, by assigning
identifiers (e.g. 'cti') to the tokens, that include a RS identifier identifiers (e.g. 'cti') to the tokens, that include an RS identifier
and a sequence number. The RS would then just have to store the and a sequence number. The RS would then just have to store the
highest sequence number of an expired token it has seen, thus highest sequence number of an expired token it has seen, thus
limiting the necessary state. limiting the necessary state.
6.7. Combining profiles 6.7. Combining profiles
There may be use cases were different profiles of this framework are There may be use cases were different profiles of this framework are
combined. For example, an MQTT-TLS profile is used between the combined. For example, an MQTT-TLS profile is used between the
client and the RS in combination with a CoAP-DTLS profile for client and the RS in combination with a CoAP-DTLS profile for
interactions between the client and the AS. The security of a interactions between the client and the AS. The security of a
skipping to change at page 51, line 12 skipping to change at page 51, line 12
This registry will be initially populated by the values in Figure 2. This registry will be initially populated by the values in Figure 2.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
8.2. OAuth Extensions Error Registration 8.2. OAuth Extensions Error Registration
This specification registers the following error values in the OAuth This specification registers the following error values in the OAuth
Extensions Error registry [IANA.OAuthExtensionsErrorRegistry]. Extensions Error registry [IANA.OAuthExtensionsErrorRegistry].
o Error name: "unsupported_pop_key" o Error name: "unsupported_pop_key"
o Error usage location: token error response o Error usage location: token error response
o Related protocol extension: The ACE framework [this document] o Related protocol extension: [this document]
o Change Controller: IESG o Change Controller: IESG
o Specification document(s): Section 5.6.3 of [this document] o Specification document(s): Section 5.6.3 of [this document]
o Error name: "incompatible_profiles" o Error name: "incompatible_ace_profiles"
o Error usage location: token error response o Error usage location: token error response
o Related protocol extension: The ACE framework [this document] o Related protocol extension: [this document]
o Change Controller: IESG o Change Controller: IESG
o Specification document(s): Section 5.6.3 of [this document] o Specification document(s): Section 5.6.3 of [this document]
8.3. OAuth Error Code CBOR Mappings Registry 8.3. OAuth Error Code CBOR Mappings Registry
This specification establishes the IANA "OAuth Error Code CBOR This specification establishes the IANA "OAuth Error Code CBOR
Mappings" registry. The registry has been created to use the "Expert Mappings" registry. The registry has been created to use the "Expert
Review" registration procedure [RFC8126], except for the value range Review" registration procedure [RFC8126], except for the value range
designated for private use. designated for private use.
skipping to change at page 53, line 44 skipping to change at page 53, line 44
registrations from the ACE framework profiles. registrations from the ACE framework profiles.
8.8. OAuth Parameter Registration 8.8. OAuth Parameter Registration
This specification registers the following parameter in the "OAuth This specification registers the following parameter in the "OAuth
Parameters" registry [IANA.OAuthParameters]: Parameters" registry [IANA.OAuthParameters]:
o Name: "ace_profile" o Name: "ace_profile"
o Parameter Usage Location: token response o Parameter Usage Location: token response
o Change Controller: IESG o Change Controller: IESG
o Reference: Section 5.6.4.3 of [this document] o Reference: Section 5.6.2 and Section 5.6.4.3 of [this document]
8.9. OAuth Parameters CBOR Mappings Registry 8.9. OAuth Parameters CBOR Mappings Registry
This specification establishes the IANA "OAuth Parameters CBOR This specification establishes the IANA "OAuth Parameters CBOR
Mappings" registry. The registry has been created to use the "Expert Mappings" registry. The registry has been created to use the "Expert
Review" registration procedure [RFC8126], except for the value range Review" registration procedure [RFC8126], except for the value range
designated for private use. designated for private use.
The columns of this registry are: The columns of this registry are:
skipping to change at page 54, line 27 skipping to change at page 54, line 27
This registry will be initially populated by the values in Figure 12. This registry will be initially populated by the values in Figure 12.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
8.10. OAuth Introspection Response Parameter Registration 8.10. OAuth Introspection Response Parameter Registration
This specification registers the following parameter in the OAuth This specification registers the following parameter in the OAuth
Token Introspection Response registry Token Introspection Response registry
[IANA.TokenIntrospectionResponse]. [IANA.TokenIntrospectionResponse].
o Name: "ace_profile" o Name: "ace_profile"
o Description: The communication and communication security profile o Description: The ACE profile used between client and RS.
used between client and RS, as defined in ACE profiles.
o Change Controller: IESG o Change Controller: IESG
o Reference: Section 5.7.2 of [this document] o Reference: Section 5.7.2 of [this document]
8.11. OAuth Token Introspection Response CBOR Mappings Registry 8.11. OAuth Token Introspection Response CBOR Mappings Registry
This specification establishes the IANA "OAuth Token Introspection This specification establishes the IANA "OAuth Token Introspection
Response CBOR Mappings" registry. The registry has been created to Response CBOR Mappings" registry. The registry has been created to
use the "Expert Review" registration procedure [RFC8126], except for use the "Expert Review" registration procedure [RFC8126], except for
the value range designated for private use. the value range designated for private use.
skipping to change at page 55, line 16 skipping to change at page 55, line 16
intentionally coincide with the CWT claim name mappings from intentionally coincide with the CWT claim name mappings from
[RFC8392]. [RFC8392].
8.12. JSON Web Token Claims 8.12. JSON Web Token Claims
This specification registers the following new claims in the JSON Web This specification registers the following new claims in the JSON Web
Token (JWT) registry of JSON Web Token Claims Token (JWT) registry of JSON Web Token Claims
[IANA.JsonWebTokenClaims]: [IANA.JsonWebTokenClaims]:
o Claim Name: "ace_profile" o Claim Name: "ace_profile"
o Claim Description: The profile a token is supposed to be used o Claim Description: The ACE profile a token is supposed to be used
with. with.
o Change Controller: IESG o Change Controller: IESG
o Reference: Section 5.8 of [this document] o Reference: Section 5.8 of [this document]
o Claim Name: "exi" o Claim Name: "exi"
o Claim Description: "Expires in". Lifetime of the token in seconds o Claim Description: "Expires in". Lifetime of the token in seconds
from the time the RS first sees it. Used to implement a weaker from the time the RS first sees it. Used to implement a weaker
from of token expiration for devices that cannot synchronize their from of token expiration for devices that cannot synchronize their
internal clocks. internal clocks.
o Change Controller: IESG o Change Controller: IESG
skipping to change at page 56, line 4 skipping to change at page 56, line 4
o Claim Description: The scope of an access token as defined in o Claim Description: The scope of an access token as defined in
[RFC6749]. [RFC6749].
o JWT Claim Name: scope o JWT Claim Name: scope
o Claim Key: TBD (suggested: 9) o Claim Key: TBD (suggested: 9)
o Claim Value Type(s): byte string or text string o Claim Value Type(s): byte string or text string
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.2 of o Specification Document(s): Section 4.2 of
[I-D.ietf-oauth-token-exchange] [I-D.ietf-oauth-token-exchange]
o Claim Name: "ace_profile" o Claim Name: "ace_profile"
o Claim Description: The profile a token is supposed to be used o Claim Description: The ACE profile a token is supposed to be used
with. with.
o JWT Claim Name: ace_profile o JWT Claim Name: ace_profile
o Claim Key: TBD (suggested: 38) o Claim Key: TBD (suggested: 38)
o Claim Value Type(s): integer o Claim Value Type(s): integer
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.8 of [this document] o Specification Document(s): Section 5.8 of [this document]
o Claim Name: "exi" o Claim Name: "exi"
o Claim Description: The expiration time of a token measured from o Claim Description: The expiration time of a token measured from
when it was received at the RS in seconds. when it was received at the RS in seconds.
skipping to change at page 57, line 36 skipping to change at page 57, line 36
Change controller: IESG Change controller: IESG
8.15. CoAP Content-Format Registry 8.15. CoAP Content-Format Registry
This specification registers the following entry to the "CoAP This specification registers the following entry to the "CoAP
Content-Formats" registry: Content-Formats" registry:
Media Type: application/ace+cbor Media Type: application/ace+cbor
Encoding Encoding: -
ID: 19 ID: TBD (suggested: 19)
Reference: [this document] Reference: [this document]
8.16. Expert Review Instructions 8.16. Expert Review Instructions
All of the IANA registries established in this document are defined All of the IANA registries established in this document are defined
to use a registration policy of Expert Review. This section gives to use a registration policy of Expert Review. This section gives
some general guidelines for what the experts should be looking for, some general guidelines for what the experts should be looking for,
but they are being designated as experts for a reason, so they should but they are being designated as experts for a reason, so they should
be given substantial latitude. be given substantial latitude.
skipping to change at page 59, line 25 skipping to change at page 59, line 25
[I-D.ietf-ace-cwt-proof-of-possession] [I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
possession-11 (work in progress), October 2019. possession-11 (work in progress), October 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-06 (work in progress), November 2019. params-10 (work in progress), January 2020.
[I-D.ietf-oauth-token-exchange] [I-D.ietf-oauth-token-exchange]
Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C. Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.
Mortimore, "OAuth 2.0 Token Exchange", draft-ietf-oauth- Mortimore, "OAuth 2.0 Token Exchange", draft-ietf-oauth-
token-exchange-19 (work in progress), July 2019. token-exchange-19 (work in progress), July 2019.
[IANA.CborWebTokenClaims] [IANA.CborWebTokenClaims]
IANA, "CBOR Web Token (CWT) Claims", IANA, "CBOR Web Token (CWT) Claims",
<https://www.iana.org/assignments/cwt/cwt.xhtml#claims- <https://www.iana.org/assignments/cwt/cwt.xhtml#claims-
registry>. registry>.
skipping to change at page 66, line 38 skipping to change at page 66, line 38
size of messages sent over the wire, the RAM size of data objects size of messages sent over the wire, the RAM size of data objects
that need to be kept in memory and the size of libraries that that need to be kept in memory and the size of libraries that
devices need to support. devices need to support.
Access Information: Access Information:
This framework defines the name "Access Information" for data This framework defines the name "Access Information" for data
concerning the RS that the AS returns to the client in an access concerning the RS that the AS returns to the client in an access
token response (see Section 5.6.2). This aims at enabling token response (see Section 5.6.2). This aims at enabling
scenarios where a powerful client, supporting multiple profiles, scenarios where a powerful client, supporting multiple profiles,
needs to interact with a RS for which it does not know the needs to interact with an RS for which it does not know the
supported profiles and the raw public key. supported profiles and the raw public key.
Proof-of-Possession: Proof-of-Possession:
This framework makes use of proof-of-possession tokens, using the This framework makes use of proof-of-possession tokens, using the
"cnf" claim [I-D.ietf-ace-cwt-proof-of-possession]. A request "cnf" claim [I-D.ietf-ace-cwt-proof-of-possession]. A request
parameter "cnf" and a Response parameter "cnf", both having a parameter "cnf" and a Response parameter "cnf", both having a
value space semantically and syntactically identical to the "cnf" value space semantically and syntactically identical to the "cnf"
claim, are defined for the token endpoint, to allow requesting and claim, are defined for the token endpoint, to allow requesting and
stating confirmation keys. This aims at making token theft stating confirmation keys. This aims at making token theft
harder. Token theft is specifically relevant in constrained use harder. Token theft is specifically relevant in constrained use
cases, as communication often passes through middle-boxes, which cases, as communication often passes through middle-boxes, which
could be able to steal bearer tokens and use them to gain could be able to steal bearer tokens and use them to gain
unauthorized access. unauthorized access.
Authz-Info endpoint: Authz-Info endpoint:
This framework introduces a new way of providing access tokens to This framework introduces a new way of providing access tokens to
a RS by exposing a authz-info endpoint, to which access tokens can an RS by exposing a authz-info endpoint, to which access tokens
be POSTed. This aims at reducing the size of the request message can be POSTed. This aims at reducing the size of the request
and the code complexity at the RS. The size of the request message and the code complexity at the RS. The size of the
message is problematic, since many constrained protocols have request message is problematic, since many constrained protocols
severe message size limitations at the physical layer (e.g., in have severe message size limitations at the physical layer (e.g.,
the order of 100 bytes). This means that larger packets get in the order of 100 bytes). This means that larger packets get
fragmented, which in turn combines badly with the high rate of fragmented, which in turn combines badly with the high rate of
packet loss, and the need to retransmit the whole message if one packet loss, and the need to retransmit the whole message if one
packet gets lost. Thus separating sending of the request and packet gets lost. Thus separating sending of the request and
sending of the access tokens helps to reduce fragmentation. sending of the access tokens helps to reduce fragmentation.
Client Credentials Grant: Client Credentials Grant:
This framework RECOMMENDS the use of the client credentials grant This framework RECOMMENDS the use of the client credentials grant
for machine-to-machine communication use cases, where manual for machine-to-machine communication use cases, where manual
intervention of the resource owner to produce a grant token is not intervention of the resource owner to produce a grant token is not
skipping to change at page 71, line 13 skipping to change at page 71, line 13
responses. Section 5 and Section 5.6 responses. Section 5 and Section 5.6
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. Section 5.8.1 error responses are protected. Section 5.8.1
o Optionally define other methods of token transport than the authz- o Optionally define other methods of token transport than the authz-
info endpoint. Section 5.8.1 info endpoint. Section 5.8.1
Appendix D. Assumptions on AS knowledge about C and RS Appendix D. Assumptions on AS knowledge about C and RS
This section lists the assumptions on what an AS should know about a This section lists the assumptions on what an AS should know about a
client and a RS in order to be able to respond to requests to the client and an RS in order to be able to respond to requests to the
token and introspection endpoints. How this information is token and introspection endpoints. How this information is
established is out of scope for this document. established is out of scope for this document.
o The identifier of the client or RS. o The identifier of the client or RS.
o The profiles that the client or RS supports. o The profiles that the client or RS supports.
o The scopes that the RS supports. o The scopes that the RS supports.
o The audiences that the RS identifies with. o The audiences that the RS identifies with.
o The key types (e.g., pre-shared symmetric key, raw public key, key o The key types (e.g., pre-shared symmetric key, raw public key, key
length, other key parameters) that the client or RS supports. length, other key parameters) that the client or RS supports.
o The types of access tokens the RS supports (e.g., CWT). o The types of access tokens the RS supports (e.g., CWT).
skipping to change at page 71, line 45 skipping to change at page 71, line 45
Appendix E. Deployment Examples Appendix E. Deployment Examples
There is a large variety of IoT deployments, as is indicated in There is a large variety of IoT deployments, as is indicated in
Appendix A, and this section highlights a few common variants. This Appendix A, and this section highlights a few common variants. This
section is not normative but illustrates how the framework can be section is not normative but illustrates how the framework can be
applied. applied.
For each of the deployment variants, there are a number of possible For each of the deployment variants, there are a number of possible
security setups between clients, resource servers and authorization security setups between clients, resource servers and authorization
servers. The main focus in the following subsections is on how servers. The main focus in the following subsections is on how
authorization of a client request for a resource hosted by a RS is authorization of a client request for a resource hosted by an RS is
performed. This requires the security of the requests and responses performed. This requires the security of the requests and responses
between the clients and the RS to be considered. between the clients and the RS to be considered.
Note: CBOR diagnostic notation is used for examples of requests and Note: CBOR diagnostic notation is used for examples of requests and
responses. responses.
E.1. Local Token Validation E.1. Local Token Validation
In this scenario, the case where the resource server is offline is In this scenario, the case where the resource server is offline is
considered, i.e., it is not connected to the AS at the time of the considered, i.e., it is not connected to the AS at the time of the
skipping to change at page 76, line 42 skipping to change at page 76, line 42
out during a phase when the client had connectivity to AS. out during a phase when the client had connectivity to AS.
Since the client is assumed to be offline, at least for a certain Since the client is assumed to be offline, at least for a certain
period of time, a pre-provisioned access token has to be long-lived. period of time, a pre-provisioned access token has to be long-lived.
Since the client is constrained, the token will not be self contained Since the client is constrained, the token will not be self contained
(i.e. not a CWT) but instead just a reference. The resource server (i.e. not a CWT) but instead just a reference. The resource server
uses its connectivity to learn about the claims associated to the uses its connectivity to learn about the claims associated to the
access token by using introspection, which is shown in the example access token by using introspection, which is shown in the example
below. below.
In the example interactions between an offline client (key fob), a RS In the example interactions between an offline client (key fob), an
(online lock), and an AS is shown. It is assumed that there is a RS (online lock), and an AS is shown. It is assumed that there is a
provisioning step where the client has access to the AS. This provisioning step where the client has access to the AS. This
corresponds to message exchanges A and B which are shown in corresponds to message exchanges A and B which are shown in
Figure 22. Figure 22.
Authorization consent from the resource owner can be pre-configured, Authorization consent from the resource owner can be pre-configured,
but it can also be provided via an interactive flow with the resource but it can also be provided via an interactive flow with the resource
owner. An example of this for the key fob case could be that the owner. An example of this for the key fob case could be that the
resource owner has a connected car, he buys a generic key that he resource owner has a connected car, he buys a generic key that he
wants to use with the car. To authorize the key fob he connects it wants to use with the car. To authorize the key fob he connects it
to his computer that then provides the UI for the device. After that to his computer that then provides the UI for the device. After that
 End of changes. 32 change blocks. 
60 lines changed or deleted 65 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/