idnits 2.17.1 draft-erdtman-ace-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 (May 10, 2017) is 2543 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-00 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: November 11, 2017 Spotify AB 6 May 10, 2017 8 Raw-Public-Key and Pre-Shared-Key as OAuth client credentials 9 draft-erdtman-ace-rpcc-00 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 http://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 November 11, 2017. 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 (http://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 . . . . . . . . . . 2 55 3. Raw-Public-Key for Client Authentication . . . . . . . . . . 3 56 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 5.1. Token Endpoint Authentication Method Registration . . . . 4 59 5.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 4 60 5.1.2. Registry Contents . . . . . . . . . . . . . . . . . . 4 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 64 7.2. Informative References . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 This document describes Transport Layer Security (TLS) authentication 70 using Raw-Public-Key and Pre-Shared-Key as the mechanism for OAuth 71 client authentication. Examples of endpoint requiering client 72 authentication are token and introspection. 74 The OAuth 2.0 Authorization Framework [RFC6749] defines a shared 75 secret method of client authentication but also allows for the 76 definition and use of additional client authentication mechanisms 77 when interacting with the authorization server's token endpoint. 78 This document describes two additional mechanisms of client 79 authentication utilizing Raw-Public-Key [RFC7250] and Pre-Shared-Key 80 TLS [RFC4279], which provide better security characteristics than 81 shared secrets. 83 1.1. Requirements Language 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119]. 89 2. Pre-Shared-Key for Client Authentication 91 The following section defines, as an extension of OAuth 2.0, 92 Section 2.3 [RFC6749], using Pre-Shared-Key with TLS [RFC4279] to 93 authenticate the client. This method is registered as 94 'tls_client_psk' in "OAuth Token Endpoint Authentication Methods" 95 registry. 97 The (D)TLS handshake MUST be done according to [RFC4279], with the 98 client indicating support for one or more Pre-Shared-Key cipher 99 suites and authorization server selecting a Pre-Shared-Key cipher 100 suite. In order to enable authorization server to select the correct 101 pre-shared-key the client MUST send its client identifier in the psk- 102 identity field of the ClientKeyExchange message. How the 103 authorization server maps a client identifier to the pre-shared-key 104 is out of scope for this specification. 106 Note that the client identity MUST be 2^16 bytes or shorter, in order 107 to fit into the psk-identity field. 109 3. Raw-Public-Key for Client Authentication 111 The following section defines, as an extension of OAuth 2.0, 112 Section 2.3 [RFC6749], the use of Raw-Public-Key with (D)TLS 113 [RFC7250] to authenticate the client. This method is registered 114 as'tls_client_rpk' in "OAuth Token Endpoint Authentication Methods" 115 registry. 117 The (D)TLS handshake MUST be done according to [RFC7250], with the 118 client indicating support for Raw-Public-Key certificates and the 119 authorization server asking client send its Raw Public Key 120 certificate. To enable authorization server to validate the client 121 RPK it MUST send its client identifier in the ClientHello or 122 ClientKeyExchange message. 124 Authorization servers MAY use the following method to map a Raw 125 Public Key to a client identifier: The client identifier is generated 126 from the Raw Public Key using the procedure specified in section 3 of 127 [RFC6920]. The digest is calculated on the Raw Public Key only (not 128 on the SubjectPublicKeyInfo used in the handshake). An example is 129 shown in Figure 1. 131 Raw Public Key (Base64 encoded): 132 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEtboxNKPgxEKV9JTNzy 133 tUvAbxEfkCTVB9kOzheF5wRAoOz2NKP+ln+XLVAQSp1D6jfo09tppvN 134 poQA1nnBNH6A=="; 136 Encoding: 137 ni:///sha-256;xzLa24yOBeCkos3VFzD2gd83Urohr9TsXqY9nhdDN0 139 Figure 1: Example encoding of a raw public key in the Named 140 Information URI Format 142 4. Acknowledgements 144 This document is highly inspired by [I-D.ietf-oauth-mtls] written by 145 B. Campbell, J. Bradley, N. Sakimura and T. Lodderstedt. 147 5. IANA Considerations 149 5.1. Token Endpoint Authentication Method Registration 151 This specification requests registration of the following value in 152 the IANA "OAuth Token Endpoint Authentication Methods" registry 153 [IANA.OAuth.Parameters] established by [RFC7591]. 155 5.1.1. Registry Contents 157 o Token Endpoint Authentication Method Name: "tls_client_rpk" 158 o Change Controller: IESG 159 o Specification Document(s): [[ this specification ]] 161 5.1.2. Registry Contents 163 o Token Endpoint Authentication Method Name: "tls_client_psk" 164 o Change Controller: IESG 165 o Specification Document(s): [[ this specification ]] 167 6. Security Considerations 169 TBD 171 7. References 173 7.1. Normative References 175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 176 Requirement Levels", BCP 14, RFC 2119, 177 DOI 10.17487/RFC2119, March 1997, 178 . 180 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 181 Ciphersuites for Transport Layer Security (TLS)", 182 RFC 4279, DOI 10.17487/RFC4279, December 2005, 183 . 185 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 186 RFC 6749, DOI 10.17487/RFC6749, October 2012, 187 . 189 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 190 Keranen, A., and P. Hallam-Baker, "Naming Things with 191 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 192 . 194 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 195 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 196 Transport Layer Security (TLS) and Datagram Transport 197 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 198 June 2014, . 200 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 201 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 202 RFC 7591, DOI 10.17487/RFC7591, July 2015, 203 . 205 7.2. Informative References 207 [I-D.ietf-oauth-mtls] 208 Campbell, B., Bradley, J., Sakimura, N., and T. 209 Lodderstedt, "Mutual TLS Profiles for OAuth Clients", 210 draft-ietf-oauth-mtls-00 (work in progress), May 2017. 212 [IANA.OAuth.Parameters] 213 IANA, "OAuth Parameters", 214 . 216 Authors' Addresses 218 Ludwig Seitz 219 RISE SICS 220 Scheelevaegen 17 221 Lund 223 70 222 SWEDEN 224 Email: ludwig@ri.se 226 Samuel Erdtman 227 Spotify AB 228 Birger Jarlsgatan 61, 4tr 229 Stockholm 113 56 230 Sweden 232 Email: erdtman@spotify.com