idnits 2.17.1 draft-erdtman-ace-rpcc-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2362 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-oauth-mtls-04 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group L. Seitz 3 Internet-Draft RISE SICS 4 Intended status: Informational S. Erdtman 5 Expires: May 3, 2018 Spotify AB 6 October 30, 2017 8 Raw-Public-Key and Pre-Shared-Key as OAuth client credentials 9 draft-erdtman-ace-rpcc-02 11 Abstract 13 This document describes Transport Layer Security (TLS) authentication 14 using Raw-Public-Key and Pre-Shared-Key as new mechanisms for OAuth 15 client authentication. Although defined for TLS the mechanisms are 16 equally applicable for DTLS. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 3, 2018. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 54 2. Pre-Shared-Key for Client Authentication . . . . . . . . . . 3 55 3. Raw-Public-Key for Client Authentication . . . . . . . . . . 3 56 4. Dynamic Registration . . . . . . . . . . . . . . . . . . . . 4 57 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 6.1. OAuth Dynamic Client Registration Metadata Registration . 4 60 6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 5 61 6.2. Token Endpoint Authentication Method Registration . . . . 5 62 6.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 5 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 8.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 This document describes Transport Layer Security (TLS) authentication 72 using Raw-Public-Key and Pre-Shared-Key as the mechanism for OAuth 73 client authentication. Examples of endpoint requiring client 74 authentication are token and introspection. 76 The OAuth 2.0 Authorization Framework [RFC6749] defines a shared 77 secret method of client authentication but also allows for the 78 definition and use of additional client authentication mechanisms 79 when interacting with the authorization server's token endpoint. 80 This document describes two additional mechanisms of client 81 authentication utilizing Raw-Public-Key [RFC7250] and Pre-Shared-Key 82 TLS [RFC4279], which provide better security characteristics than 83 shared secrets. 85 To get most bennefits and improved security with these new client 86 credential types it is recomended to use the 'one credential per 87 Client Software Instance' paradigm. This can be achived by letting 88 the client dynamicly register as described in [RFC7591]. 90 1.1. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 2. Pre-Shared-Key for Client Authentication 98 The following section defines, as an extension of OAuth 2.0, 99 Section 2.3 [RFC6749], using Pre-Shared-Key with TLS [RFC4279] to 100 authenticate the client. This method is registered as 101 'tls_client_psk' in "OAuth Token Endpoint Authentication Methods" 102 registry. If this method is to be used, the client and the 103 Authorization Server MUST share a secret key, and they MUST agree on 104 an identifier for this key. 106 The (D)TLS handshake MUST be done according to [RFC4279], with the 107 client indicating support for one or more Pre-Shared-Key cipher 108 suites and authorization server selecting a Pre-Shared-Key cipher 109 suite. In order to enable the authorization server to select the 110 correct pre-shared-key the client MUST send the key identifier in the 111 psk-identity field of the ClientKeyExchange message. How the 112 authorization server maps the identifier to a pre-shared-key, and to 113 a specific client is out of scope for this specification. 115 Note that the key identifier MUST be 2^16 bytes or shorter, in order 116 to fit into the psk-identity field. 118 3. Raw-Public-Key for Client Authentication 120 The following section defines, as an extension of OAuth 2.0, 121 Section 2.3 [RFC6749], the use of Raw-Public-Key with (D)TLS 122 [RFC7250] to authenticate the client. This method is registered as 123 'tls_client_rpk' in "OAuth Token Endpoint Authentication Methods" 124 registry. 126 The (D)TLS handshake MUST be done according to [RFC7250], with the 127 client indicating support for Raw-Public-Key certificates and the 128 authorization server asking client send its Raw Public Key 129 certificate. Since the client cannot send an explicit client or key 130 identifier in the handshake, the authorization server MUST derive a 131 client identifier from RPK that the client uses. 133 Note to implementers: Authorization servers can use the following 134 method to map a Raw Public Key to a client identifier: The client 135 identifier is generated from the Raw Public Key using the procedure 136 specified in section 3 of [RFC6920]. The digest is calculated on the 137 Raw Public Key only (not on the SubjectPublicKeyInfo used in the 138 handshake). An example is shown in Figure 1. 140 Raw Public Key (Base64 encoded): 141 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEtboxNKPgxEKV9JTNzy 142 tUvAbxEfkCTVB9kOzheF5wRAoOz2NKP+ln+XLVAQSp1D6jfo09tppvN 143 poQA1nnBNH6A=="; 145 Encoding: 146 ni:///sha-256;xzLa24yOBeCkos3VFzD2gd83Urohr9TsXqY9nhdDN0 148 Figure 1: Example encoding of a raw public key in the Named 149 Information URI Format 151 4. Dynamic Registration 153 For dynamic registration of a RPK this specification registers the 154 new parameter 'rpk' to the Client Registration Metadata Registry. 155 When used this parameter MUST contain a JSON Web Key representing the 156 public key of the client. When 'rpk' is present in the registration 157 request 'token_endpoint_auth_method' MUST include 'tls_client_rpk'. 159 For dynamic registration of a PSK this specification registers the 160 new parameter 'psk' to the Client Registration Metadata Registry. 161 When used this parameter MUST contain a JSON Web Key representing the 162 key of the client. When registering the client can include the key 163 in the registrations request or the authorisation can generate the 164 key and return it. If the 'psk' attribute is present in a request 165 'token_endpoint_auth_method' MUST include 'tls_client_psk'. To 166 request the authorisation server to generate the key the client 167 includes 'tls_client_psk' in 'token_endpoint_auth_method' but does 168 not send 'psk' attribute. 170 The 'jwks' and 'jwks_uri' is not used to avoid conflict and confusion 171 with application layer keys. 173 5. Acknowledgements 175 This document is highly inspired by [I-D.ietf-oauth-mtls] written by 176 B. Campbell, J. Bradley, N. Sakimura and T. Lodderstedt. 178 6. IANA Considerations 180 6.1. OAuth Dynamic Client Registration Metadata Registration 182 This specification requests registration of the following value in 183 the IANA "OAuth Dynamic Client Registration Metadata" registry 184 [IANA.OAuth.Parameters] established by [RFC7591]. 186 6.1.1. Registry Contents 188 o Client Metadata Name: "rpk" 189 o Client Metadata Description: JWK for client Raw-Public-Key, can be 190 included in request. 191 o Change Controller: IESG 192 o Specification Document(s): [[ this specification ]] 194 o Client Metadata Name: "psk" 195 o Client Metadata Description: JWK for client Pre-Shared-Key, can be 196 included both in request and response. 197 o Change Controller: IESG 198 o Specification Document(s): [[ this specification ]] 200 6.2. Token Endpoint Authentication Method Registration 202 This specification requests registration of the following value in 203 the IANA "OAuth Token Endpoint Authentication Methods" registry 204 [IANA.OAuth.Parameters] established by [RFC7591]. 206 6.2.1. Registry Contents 208 o Token Endpoint Authentication Method Name: "tls_client_rpk" 209 o Change Controller: IESG 210 o Specification Document(s): [[ this specification ]] 212 o Token Endpoint Authentication Method Name: "tls_client_psk" 213 o Change Controller: IESG 214 o Specification Document(s): [[ this specification ]] 216 7. Security Considerations 218 TBD 220 8. References 222 8.1. Normative References 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, 226 DOI 10.17487/RFC2119, March 1997, 227 . 229 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 230 Ciphersuites for Transport Layer Security (TLS)", 231 RFC 4279, DOI 10.17487/RFC4279, December 2005, 232 . 234 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 235 RFC 6749, DOI 10.17487/RFC6749, October 2012, 236 . 238 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 239 Keranen, A., and P. Hallam-Baker, "Naming Things with 240 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 241 . 243 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 244 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 245 Transport Layer Security (TLS) and Datagram Transport 246 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 247 June 2014, . 249 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 250 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 251 RFC 7591, DOI 10.17487/RFC7591, July 2015, 252 . 254 8.2. Informative References 256 [I-D.ietf-oauth-mtls] 257 Campbell, B., Bradley, J., Sakimura, N., and T. 258 Lodderstedt, "Mutual TLS Profile for OAuth 2.0", draft- 259 ietf-oauth-mtls-04 (work in progress), October 2017. 261 [IANA.OAuth.Parameters] 262 IANA, "OAuth Parameters", 263 . 265 Authors' Addresses 267 Ludwig Seitz 268 RISE SICS 269 Scheelevaegen 17 270 Lund 223 70 271 SWEDEN 273 Email: ludwig.seitz@ri.se 274 Samuel Erdtman 275 Spotify AB 276 Birger Jarlsgatan 61, 4tr 277 Stockholm 113 56 278 Sweden 280 Email: erdtman@spotify.com