idnits 2.17.1 draft-erdtman-oauth-rpcc-00.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 (November 20, 2017) is 2350 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-05 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Web Authorization Protocol L. Seitz 3 Internet-Draft RISE SICS 4 Intended status: Informational S. Erdtman 5 Expires: May 24, 2018 Spotify AB 6 M. Tiloca 7 RISE SICS AB 8 November 20, 2017 10 Raw-Public-Key and Pre-Shared-Key as OAuth client credentials 11 draft-erdtman-oauth-rpcc-00 13 Abstract 15 This document describes Transport Layer Security (TLS) authentication 16 using Raw-Public-Key and Pre-Shared-Key as new mechanisms for OAuth 17 client authentication. Although defined for TLS the mechanisms are 18 equally applicable for DTLS. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 24, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 56 2. Pre-Shared-Key for Client Authentication . . . . . . . . . . 2 57 3. Raw-Public-Key for Client Authentication . . . . . . . . . . 3 58 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 5.1. Token Endpoint Authentication Method Registration . . . . 4 61 5.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 4 62 5.1.2. Registry Contents . . . . . . . . . . . . . . . . . . 4 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 66 7.2. Informative References . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 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 1.1. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 2. Pre-Shared-Key for Client Authentication 93 The following section defines, as an extension of OAuth 2.0, 94 Section 2.3 [RFC6749], using Pre-Shared-Key with TLS [RFC4279] to 95 authenticate the client. This method is registered as 96 'tls_client_psk' in "OAuth Token Endpoint Authentication Methods" 97 registry. If this method is to be used, the client and the 98 Authorization Server MUST share a secret key, and they MUST agree on 99 an identifier for this key. 101 The (D)TLS handshake MUST be done according to [RFC4279], with the 102 client indicating support for one or more Pre-Shared-Key cipher 103 suites and authorization server selecting a Pre-Shared-Key cipher 104 suite. In order to enable authorization server to select the correct 105 pre-shared-key the client MUST send the key identifier in the psk- 106 identity field of the ClientKeyExchange message. How the 107 authorization server maps an identifier to a pre-shared-key, and to a 108 client identity is out of scope for this specification. 110 Note that the client identity MUST be 2^16 bytes or shorter, in order 111 to fit into the psk-identity field. 113 3. Raw-Public-Key for Client Authentication 115 The following section defines, as an extension of OAuth 2.0, 116 Section 2.3 [RFC6749], the use of Raw-Public-Key with (D)TLS 117 [RFC7250] to authenticate the client. This method is registered as 118 'tls_client_rpk' in "OAuth Token Endpoint Authentication Methods" 119 registry. 121 The (D)TLS handshake MUST be done according to [RFC7250], with the 122 client indicating support for Raw-Public-Key certificates and the 123 authorization server asking client send its Raw Public Key 124 certificate. Since the client cannot send an explicit client 125 identifier in the handshake, the authorization server MUST the derive 126 a client identifier from RPK that the client uses. 128 Note to implementers: Authorization servers can use the following 129 method to map a Raw Public Key to a client identifier: The client 130 identifier is generated from the Raw Public Key using the procedure 131 specified in section 3 of [RFC6920]. The digest is calculated on the 132 Raw Public Key only (not on the SubjectPublicKeyInfo used in the 133 handshake). An example is shown in Figure 1. 135 Raw Public Key (Base64 encoded): 136 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEtboxNKPgxEKV9JTNzy 137 tUvAbxEfkCTVB9kOzheF5wRAoOz2NKP+ln+XLVAQSp1D6jfo09tppvN 138 poQA1nnBNH6A=="; 140 Encoding: 141 ni:///sha-256;xzLa24yOBeCkos3VFzD2gd83Urohr9TsXqY9nhdDN0 143 Figure 1: Example encoding of a raw public key in the Named 144 Information URI Format 146 4. Acknowledgements 148 This document is highly inspired by [I-D.ietf-oauth-mtls] written by 149 B. Campbell, J. Bradley, N. Sakimura and T. Lodderstedt. 151 5. IANA Considerations 153 5.1. Token Endpoint Authentication Method Registration 155 This specification requests registration of the following value in 156 the IANA "OAuth Token Endpoint Authentication Methods" registry 157 [IANA.OAuth.Parameters] established by [RFC7591]. 159 5.1.1. Registry Contents 161 o Token Endpoint Authentication Method Name: "tls_client_rpk" 162 o Change Controller: IESG 163 o Specification Document(s): [[ this specification ]] 165 5.1.2. Registry Contents 167 o Token Endpoint Authentication Method Name: "tls_client_psk" 168 o Change Controller: IESG 169 o Specification Document(s): [[ this specification ]] 171 6. Security Considerations 173 TBD 175 7. References 177 7.1. Normative References 179 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 180 Requirement Levels", BCP 14, RFC 2119, 181 DOI 10.17487/RFC2119, March 1997, 182 . 184 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 185 Ciphersuites for Transport Layer Security (TLS)", 186 RFC 4279, DOI 10.17487/RFC4279, December 2005, 187 . 189 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 190 RFC 6749, DOI 10.17487/RFC6749, October 2012, 191 . 193 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 194 Keranen, A., and P. Hallam-Baker, "Naming Things with 195 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 196 . 198 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 199 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 200 Transport Layer Security (TLS) and Datagram Transport 201 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 202 June 2014, . 204 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 205 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 206 RFC 7591, DOI 10.17487/RFC7591, July 2015, 207 . 209 7.2. Informative References 211 [I-D.ietf-oauth-mtls] 212 Campbell, B., Bradley, J., Sakimura, N., and T. 213 Lodderstedt, "Mutual TLS Profile for OAuth 2.0", draft- 214 ietf-oauth-mtls-05 (work in progress), November 2017. 216 [IANA.OAuth.Parameters] 217 IANA, "OAuth Parameters", 218 . 220 Authors' Addresses 222 Ludwig Seitz 223 RISE SICS 224 Scheelevaegen 17 225 Lund 223 70 226 SWEDEN 228 Email: ludwig.seitz@ri.se 230 Samuel Erdtman 231 Spotify AB 232 Birger Jarlsgatan 61, 4tr 233 Stockholm 113 56 234 Sweden 236 Email: erdtman@spotify.com 237 Marco Tiloca 238 RISE SICS AB 239 Isafjordsgatan 22 240 Stockholm 164 29 241 Sweden 243 Email: marco.tiloca@ri.se