--- 1/draft-ietf-ace-oauth-authz-27.txt 2019-12-14 08:13:14.377480931 -0800 +++ 2/draft-ietf-ace-oauth-authz-28.txt 2019-12-14 08:13:14.541485126 -0800 @@ -1,26 +1,26 @@ ACE Working Group L. Seitz -Internet-Draft RISE +Internet-Draft Combitech Intended status: Standards Track G. Selander -Expires: May 24, 2020 Ericsson +Expires: June 16, 2020 Ericsson E. Wahlstroem S. Erdtman Spotify AB H. Tschofenig Arm Ltd. - November 21, 2019 + December 14, 2019 Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) - draft-ietf-ace-oauth-authz-27 + draft-ietf-ace-oauth-authz-28 Abstract This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 24, 2020. + This Internet-Draft will expire on June 16, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -97,79 +97,79 @@ 5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 39 5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 40 5.8.4. Key Expiration . . . . . . . . . . . . . . . . . . . 41 6. Security Considerations . . . . . . . . . . . . . . . . . . . 42 6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 42 6.2. Communication Security . . . . . . . . . . . . . . . . . 43 6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 43 6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 44 6.5. Minimal security requirements for communication . 45 6.6. Token Freshness and Expiration . . . . . . . . . . . . . 46 - 6.7. Combining profiles . . . . . . . . . . . . . . . . . . . 46 + 6.7. Combining profiles . . . . . . . . . . . . . . . . . . . 47 6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47 - 6.9. Identifying audiences . . . . . . . . . . . . . . . . . . 47 + 6.9. Identifying audiences . . . . . . . . . . . . . . . . . . 48 6.10. Denial of service against or with Introspection . . 48 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 8.1. ACE Authorization Server Request Creation Hints . . . . . 50 - 8.2. OAuth Extensions Error Registration . . . . . . . . . . . 50 + 8.2. OAuth Extensions Error Registration . . . . . . . . . . . 51 8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 51 8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 51 8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 52 8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 52 8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 52 - 8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 52 + 8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 53 8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 53 8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 53 8.10. OAuth Introspection Response Parameter Registration . . . 54 8.11. OAuth Token Introspection Response CBOR Mappings Registry 54 8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55 8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 55 8.14. Media Type Registrations . . . . . . . . . . . . . . . . 56 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 57 8.16. Expert Review Instructions . . . . . . . . . . . . . . . 57 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 10.1. Normative References . . . . . . . . . . . . . . . . . . 59 10.2. Informative References . . . . . . . . . . . . . . . . . 61 Appendix A. Design Justification . . . . . . . . . . . . . . . . 64 - Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 67 + Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 68 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 70 - Appendix D. Assumptions on AS knowledge about C and RS . . . . . 70 + Appendix D. Assumptions on AS knowledge about C and RS . . . . . 71 Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 71 - E.1. Local Token Validation . . . . . . . . . . . . . . . . . 71 - E.2. Introspection Aided Token Validation . . . . . . . . . . 75 + E.1. Local Token Validation . . . . . . . . . . . . . . . . . 72 + E.2. Introspection Aided Token Validation . . . . . . . . . . 76 - Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 79 - F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 80 - F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 80 - F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 80 - F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 80 - F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 80 - F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 80 - F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 81 - F.8. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 81 - F.9. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 81 - F.10. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 81 - F.11. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 82 - F.12. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 82 - F.13. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 82 - F.14. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 82 - F.15. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 82 - F.16. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 83 - F.17. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 83 - F.18. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 83 - F.19. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 84 - F.20. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 84 - F.21. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 84 - F.22. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 85 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 85 + Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 80 + F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 81 + F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 81 + F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 81 + F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 81 + F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 81 + F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 81 + F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 82 + F.8. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 82 + F.9. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 82 + F.10. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 82 + F.11. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 83 + F.12. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 83 + F.13. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 83 + F.14. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 83 + F.15. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 83 + F.16. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 84 + F.17. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 84 + F.18. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 84 + F.19. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 85 + F.20. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 85 + F.21. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 85 + F.22. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 86 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86 1. Introduction Authorization is the process for granting approval to an entity to access a generic resource [RFC4949]. The authorization task itself can best be described as granting access to a requesting client, for a resource hosted on a device, the resource server (RS). This exchange is mediated by one or multiple authorization servers (AS). Managing authorization for a large number of devices and users can be a complex task. @@ -1903,23 +1903,23 @@ If the token is intended for multiple recipients (i.e. an audience that is a group), integrity protection of the token with a symmetric key, shared between the AS and the recipients, is not sufficient, since any of the recipients could modify the token undetected by the other recipients. Therefore a token with a multi-recipient audience MUST be protected with an asymmetric signature. It is important for the authorization server to include the identity of the intended recipient (the audience), typically a single resource - server (or a list of resource servers), in the token. Using a single - shared secret as proof-of-possession key with multiple resource - servers is NOT RECOMMENDED since the benefit from using the proof-of- + server (or a list of resource servers), in the token. The same + shared secret MUST NOT be used as proof-of-possession key with + multiple resource servers since the benefit from using the proof-of- possession concept is then significantly reduced. If clients are capable of doing so, they should frequently request fresh access tokens, as this allows the AS to keep the lifetime of the tokens short. This allows the AS to use shorter proof-of- possession key sizes, which translate to a performance benefit for the client and for the resource server. Shorter keys also lead to shorter messages (particularly with asymmetric keying material). When authorization servers bind symmetric keys to access tokens, they @@ -1929,24 +1929,24 @@ that is still valid. Client-initiated revocation is specified in [RFC7009] for OAuth 2.0. Other revocation mechanisms are currently not specified, as the underlying assumption in OAuth is that access tokens are issued with a relatively short lifetime. This may not hold true for disconnected constrained devices, needing access tokens with relatively long lifetimes, and would therefore necessitate further standardization work that is out of scope for this document. 6.2. Communication Security - The authorization server MUST offer confidentiality protection for - any interactions with the client. This step is extremely important - since the client may obtain the proof-of-possession key from the - authorization server for use with a specific access token. Not using + Communication with the authorization server MUST use confidentiality + protection. This step is extremely important since the client or the + RS may obtain the proof-of-possession key from the authorization + server for use with a specific access token. Not using confidentiality protection exposes this secret (and the access token) to an eavesdropper thereby completely negating proof-of-possession security. Profiles MUST specify how communication security according to the requirements in Section 5 is provided. Additional protection for the access token can be applied by encrypting it, for example encryption of CWTs is specified in Section 5.1 of [RFC8392]. Such additional protection can be necessary if the token is later transferred over an insecure connection (e.g. when it is sent to the authz-info endpoint). @@ -1967,28 +1967,28 @@ need to be protected against unauthorized access. In constrained devices, deployed in publicly accessible places, such protection can be difficult to achieve without specialized hardware (e.g. secure key storage memory). If credentials are lost or compromised, the operator of the affected devices needs to have procedures to invalidate any access these credentials give and to revoke tokens linked to such credentials. The loss of a credential linked to a specific device MUST NOT lead to a compromise of other credentials not linked to that device, - therefore sharing secret keys between more than two parties is NOT - RECOMMENDED. + therefore secret keys used for authentication MUST NOT be shared + between more than two parties. - Operators of clients or RS should have procedures in place to replace + Operators of clients or RS SHOULD have procedures in place to replace credentials that are suspected to have been compromised or that have been lost. - Operators also need to have procedures for decommissioning devices, + Operators also SHOULD have procedures for decommissioning devices, that include securely erasing credentials and other security critical material in the devices being decommissioned. 6.4. Unprotected AS Request Creation Hints Initially, no secure channel exists to protect the communication between C and RS. Thus, C cannot determine if the AS Request Creation Hints contained in an unprotected response from RS to an unauthorized request (see Section 5.1.2) are authentic. It is therefore advisable to provide C with a (possibly hard-coded) list of @@ -2038,49 +2038,53 @@ exchanged either a shared secret, or their public keys in order to negotiate a secure communication. Furthermore the RS MUST be able to determine whether an AS has the authority to issue access tokens itself. This is usually configured out of band, but could also be performed through an online lookup mechanism provided that it is also secured in the same way. C-RS The initial communication between the client and the Resource Server can not be secured in general, since the RS is not in possession of on access token for that client, which would carry - the necessary parameters. Certain security mechanisms (e.g. DTLS - with server-side authentication via a certificate or a raw public - key) can be possible and are RECOMMEND if supported by both - parties. After the client has successfully transmitted the access - token to the RS, a secure communication protocol MUST be - established between client and RS for the actual resource request. - This protocol MUST provide confidentiality, integrity and replay - protection as well as a binding between requests and responses. - This requires that the client learned either the RS's public key - or received a symmetric proof-of-possession key bound to the - access token from the AS. The RS must have learned either the - client's public key or a shared symmetric key from the claims in - the token or an introspection request. Since ACE does not provide - profile negotiation between C and RS, the client MUST have learned - what profile the RS supports (e.g. from the AS or pre-configured) - and initiate the communication accordingly. + the necessary parameters. If both parties support DTLS without + client authentication it is RECOMMEND to use this mechanism for + protecting the initial communication. After the client has + successfully transmitted the access token to the RS, a secure + communication protocol MUST be established between client and RS + for the actual resource request. This protocol MUST provide + confidentiality, integrity and replay protection as well as a + binding between requests and responses. This requires that the + client learned either the RS's public key or received a symmetric + proof-of-possession key bound to the access token from the AS. + The RS must have learned either the client's public key or a + shared symmetric key from the claims in the token or an + introspection request. Since ACE does not provide profile + negotiation between C and RS, the client MUST have learned what + profile the RS supports (e.g. from the AS or pre-configured) and + initiate the communication accordingly. 6.6. Token Freshness and Expiration An RS that is offline faces the problem of clock drift. Since it cannot synchronize its clock with the AS, it may be tricked into accepting old access tokens that are no longer valid or have been compromised. In order to prevent this, an RS may use the nonce-based mechanism defined in Section 5.1.2 to ensure freshness of an Access Token subsequently presented to this RS. Another problem with clock drift is that evaluating the standard token expiration claim "exp" can give unpredictable results. + Acceptable ranges of clock drift are highly dependent on the concrete + application. Important factors are how long access tokens are valid, + and how critical timely expiration of access token is. + The expiration mechanism implemented by the "exi" claim, based on the first time the RS sees the token was defined to provide a more predictable alternative. The "exi" approach has some drawbacks that need to be considered: A malicious client may hold back tokens with the "exi" claim in order to prolong their lifespan. If an RS loses state (e.g. due to an unscheduled reboot), it may loose the current values of counters tracking the "exi" claims of @@ -2107,22 +2111,23 @@ client and the RS in combination with a CoAP-DTLS profile for interactions between the client and the AS. The security of a profile MUST NOT depend on the assumption that the profile is used for all the different types of interactions in this framework. 6.8. Unprotected Information Communication with the authz-info endpoint, as well as the various error responses defined in this framework, all potentially include sending information over an unprotected channel. These messages may - leak information to an adversary. For example error responses for - requests to the Authorization Information endpoint can reveal + leak information to an adversary, or may be manipulated by active + attackers to induce incorrect behavior. For example error responses + for requests to the Authorization Information endpoint can reveal information about an otherwise opaque access token to an adversary who has intercepted this token. As far as error messages are concerned, this framework is written under the assumption that, in general, the benefits of detailed error messages outweigh the risk due to information leakage. For particular use cases, where this assessment does not apply, detailed error messages can be replaced by more generic ones. In some scenarios it may be possible to protect the communication @@ -2133,25 +2138,26 @@ If the initial unauthorized resource request message (see Section 5.1.1) is used, the client MUST make sure that it is not sending sensitive content in this request. While GET and DELETE requests only reveal the target URI of the resource, POST and PUT requests would reveal the whole payload of the intended operation. Since the client is not authenticated at the point when it is submitting an access token to the authz-info endpoint, attackers may be pretending to be a client and trying to trick an RS to use an - obsole profile that in turn specifies a vulnerable security mechanism - via the authz-info endpoint. Such an attack would require a valid - access token containing a "profile" claim requesting the use of said - obsolete profile. Resource Owners should update the configuration of - their RS's to prevent them from using such obsolete profiles. + obsolete profile that in turn specifies a vulnerable security + mechanism via the authz-info endpoint. Such an attack would require + a valid access token containing an "ace_profile" claim requesting the + use of said obsolete profile. Resource Owners should update the + configuration of their RS's to prevent them from using such obsolete + profiles. 6.9. Identifying audiences The audience claim as defined in [RFC7519] and the equivalent "audience" parameter from [I-D.ietf-oauth-token-exchange] are intentionally vague on how to match the audience value to a specific RS. This is intended to allow application specific semantics to be used. This section attempts to give some general guidance for the use of audiences in constrained environments. @@ -2593,21 +2597,21 @@ Macintosh file type code(s): n/a Person & email address to contact for further information: Intended usage: COMMON Restrictions on usage: None - Author: Ludwig Seitz + Author: Ludwig Seitz Change controller: IESG 8.15. CoAP Content-Format Registry This specification registers the following entry to the "CoAP Content-Formats" registry: Media Type: application/ace+cbor @@ -2627,20 +2631,25 @@ Expert reviewers should take into consideration the following points: o Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered, and that the point is likely to be used in deployments. The zones tagged as private use are intended for testing purposes and closed environments; code points in other ranges should not be assigned for testing. + o Specifications are needed for the first-come, first-serve range if + they are expected to be used outside of closed environments in an + interoperable way. When specifications are not provided, the + description provided needs to have sufficient information to + identify what the point is being used for. o Experts should take into account the expected usage of fields when approving point assignment. The fact that there is a range for standards track documents does not mean that a standards track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on. o Since a high degree of overlap is expected between these registries and the contents of the OAuth parameters [IANA.OAuthParameters] registries, experts should require new @@ -2692,46 +2701,46 @@ in Constrained Environments (ACE)", draft-ietf-ace-oauth- params-06 (work in progress), November 2019. [I-D.ietf-oauth-token-exchange] Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", draft-ietf-oauth- token-exchange-19 (work in progress), July 2019. [IANA.CborWebTokenClaims] IANA, "CBOR Web Token (CWT) Claims", - . + . [IANA.JsonWebTokenClaims] IANA, "JSON Web Token Claims", . [IANA.OAuthAccessTokenTypes] IANA, "OAuth Access Token Types", - . + . [IANA.OAuthExtensionsErrorRegistry] IANA, "OAuth Extensions Error Registry", - . + . [IANA.OAuthParameters] IANA, "OAuth Parameters", - . + . [IANA.TokenIntrospectionResponse] IANA, "OAuth Token Introspection Response", - . + . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . @@ -2794,51 +2803,51 @@ May 2017, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . 10.2. Informative References [BLE] Bluetooth SIG, "Bluetooth Core Specification v5.1", Section 4.4, January 2019, - . + . [I-D.erdtman-ace-rpcc] Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared- Key as OAuth client credentials", draft-erdtman-ace- rpcc-02 (work in progress), October 2017. [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", draft-ietf-quic-transport-24 (work in progress), November 2019. [I-D.ietf-tls-dtls13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version - 1.3", draft-ietf-tls-dtls13-34 (work in progress), November - 2019. + 1.3", draft-ietf-tls-dtls13-34 (work in progress), + November 2019. [Margi10impact] Margi, C., de Oliveira, B., de Sousa, G., Simplicio Jr, M., Barreto, P., Carvalho, T., Naeslund, M., and R. Gold, "Impact of Operating Systems on Wireless Sensor Networks (Security) Applications and Testbeds", Proceedings of the 19th International Conference on Computer Communications and Networks (ICCCN), August 2010. [MQTT5.0] Banks, A., Briggs, E., Borgendale, K., and R. Gupta, "MQTT Version 5.0", OASIS Standard, March 2019, - . + . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, . @@ -3919,26 +3927,26 @@ o 5.3.2. Defined success and error responses from the RS when receiving an access token. o 5.6.:Added section giving guidance on how to handle token expiration in the absence of reliable time. o Appendix B Added list of roles and responsibilities for C, AS and RS. Authors' Addresses Ludwig Seitz - RISE - Scheelevaegen 17 - Lund 223 70 + Combitech + Djaeknegatan 31 + Malmoe 211 35 Sweden - Email: ludwig.seitz@ri.se + Email: ludwig.seitz@combitech.se Goeran Selander Ericsson Faroegatan 6 Kista 164 80 Sweden Email: goran.selander@ericsson.com Erik Wahlstroem Sweden