1-----BEGIN PGP SIGNED MESSAGE----- 2Hash: SHA1 3 4DRAFT VERSION 0.4.2 5 6 7Oliver Vaughn Gould <ver@olix0r.net> 8July 2010 9 10 11 PubKey Access Authentication Scheme, Version 1 12 ---------------------------------------------- 13 14 0 Introduction 15 -------------- 16 17 0.1 Status of this Memo 18 ------------------------ 19 20This document specifies a DRAFT protocol for the Internet community. 21 22 23 0.2 Copyright Notice 24 --------------------- 25 26Copyright (C) Yahoo!, Inc. (2010). All rights reseved. 27 28 29 0.3 Abstract 30 ------------- 31 32HTTP services are a core Internet technology, yet the Digest authentication 33scheme provided by RFC 2617 only describes authentication by way of 34shared-secrets (i.e. passwords). 35 36The PubKey Access Authentication scheme aims to enhance security on the 37World Wide Web by bringing an equivalent of SSH's "publickey" authentication 38method to challenge-based HTTP client authentication. 39 40 41 0.4 Table of Contents 42 ---------------------- 43 44 1 PubKey Access Authentication Scheme, Version 1 45 1.1 Introduction 46 1.1.1 Purpose 47 1.1.2 Overall Operation 48 1.2 Specification of PubKey.v1 Headers 49 1.2.1 The WWW-Authenticate Response Header 50 1.2.2 The Authorize Request Header 51 1.3 Example 52 1.4 Proxy-Authentication and Proxy-Authorization 53 1.5 Operational Considerations 54 1.5.1 Replay Attacks 55 1.5.2 Man-in-the-Middle Attacks 56 1.5.3 Brute Force Attacks 57 1.5.4 Spoofing by Counterfeit Servers 58 2 References 59 A Appendices 60 A.1 Challenge Generation 61 62 63 1 PubKey Access Authentication Scheme, Version 1 64 ------------------------------------------------- 65 66 1.1 Introduction 67 ----------------- 68 69 1.1.1 Purpose 70 -------------- 71 72HTTP services are a core Internet technology, yet the Digest authentication 73scheme provided by RFC 2617 only describes authentication by way of 74shared-secrets (i.e. passwords). This model has operational drawbacks, as 75authenticating services are required to have access to a user's secret (or 76a hash thereof), or retrograde technologies, such as cookies, are employed. 77 78Similarly to SSH's "publickey" authentication method [RFC 4252], the PubKey 79Access Authentication scheme allows an HTTP server to authenticate clients using 80public key credentials. 81 82 83 1.1.2 Overall Operation 84 ------------------------ 85 86Like the Digest Access Authentication Scheme [RFC 2617], the PubKey.v1 87scheme is based on a simple challenge-response paradigm. The PubKey scheme 88responds to unauthorized clients with a challenge value; and a valid 89response contains a cryptographic signature of client's id, the authentication 90realm, and the server's challenge. 91 92The client's secret never leaves the client. The server verifies the 93client's signed authorization request with the client's published public 94keys. 95 96 97 1.2 Specification of PubKey.v1 Headers 98 --------------------------------------- 99 100 1.2.1 The WWW-Authenticate Response Header 101 ------------------------------------------- 102 103If a server receives a request for an access-protected object, and an 104acceptable Authorization header is not sent, the server responds with a 105"401 Unauthorized" status code, and a WWW-Authenticate header as per the 106framework defined above, which for the digest scheme is utilized as 107follows: 108 109 challenge = "PubKey.v1" pubkey-challenge 110 111 pubkey-challenge = 1#( realm | [domain] | challenge ) 112 113 realm = "realm" "=" quoted-string 114 domain = "domain" "=" <"> URI ( 1*SP URI ) <"> 115 URI = absoluteURI | abs_path 116 challenge = "challenge" "=" quoted-string 117 118The meanings of the values of the directives used above are as follows: 119 120 realm 121 A string to be displayed to clients so they know which username and 122 public key to use. This string should contain at least the name of 123 the host performing the authentication and might additionally 124 indicate the collection of users who might have access. An example 125 might be "admin@svc.domain.tld". 126 127 domain 128 An optional quoted, space-separated list of URIs that define the 129 protection space. If a URI is an abs_path, it is relative to the 130 canonical root URL of the server being accessed. An absoluteURI in this 131 list may refer to a different server than the one being accessed. The 132 client can use this list to determine the set of URIs for which the same 133 authentication information may be sent: any URI that has a URI in this 134 list as a prefix (after both have been made absolute) may be assumed to be 135 in the same protection space. If this directive is omitted or its value 136 is empty, the client should assume that the protection space consists of 137 all URIs on the responding server. 138 139 This directive is not meaningful in Proxy-Authenticate headers, for 140 which the protection space is always the entire proxy; if present it 141 should be ignored. 142 143 challenge 144 A quoted string of data, specified by the server, which should be returned 145 by the client unchanged in the Authorization header of subsequent 146 requests with URIs in the same protection space. It is recommended 147 that this string be base 64 or hexadecimal data. 148 149 150 1.2.2 The Authorization Request Header 151 ------------------------------------- 152 153The client is expected to retry the request, passing an Authorization 154header line, which is defined according to the framework above, utilized as 155follows. 156 157 credentials = "PubKey.v1" privkey-credentials 158 159 privkey-credentials = 1#( identifier | realm | challenge | signature ) 160 161 identifier = "id" "=" identifier-value 162 identifier-value = quoted-string 163 challenge = "challenge" "=" challenge-value 164 challenge-value = quoted-string 165 signature = "signature" "=" signature-value 166 signature-value = quoted-string 167 168The values of the challenge and realm fields must be those supplied in the 169WWW-Authenticate response header for the entity being requested. 170 171 identifier 172 The client identifier in the specified realm. I.e. the client's username. 173 174 signature 175 A quoted base 64 encoded string representation of a signature generated 176 with the client's private key as follows. 177 178 signature = BASE64( D^M( authorization )) 179 authorization = identifier-value ";" realm-value ";" challenge-value 180 181If a directive or its value is improper, or required directives are 182missing, the proper response is 400 Bad Request. If the signature is 183invalid, then a login failure should be logged, since repeated login 184failures from a single client may indicate malfeasance. 185 186The client should be able to reuse this Authorization until a 401 187Unauthorized is reached, or an Authentication-Info header provides a new 188challenge. 189 190 191 1.2.3 Authentication-Info Header 192 --------------------------------- 193 194The optional Authentication-Info header may be used by the server to 195communicate some information regarding the successful authentication in the 196response. Specifically, this header can be used to send a new challenge to 197an authorized client. 198 199 AuthenticationInfo = "Authentication-Info" ":" auth-info 200 auth-info = 1#( next-challenge ) 201 next-challenge = "challenge" "=" challenge-value 202 203The meanings of the values used above are as follows: 204 205 next-challenge 206 The following request on this domain should contain an authorization 207 on this challenge value. It should be expected that reissuing the 208 used Authorization header will result in a 401 Unauthorized response. 209 210 211 1.3 Example 212 ------------ 213 214The following example assumes that an access-protected resource is being 215requested from the server via a GET request. The URI of the document is 216"http://svc.domain.tld/object". Both client and server know the public key 217for the user identified as "McFly" in the realm "users@svc.domain.tld". 218 219The first time the client requests the document, no Authorization header is 220sent, so the server responds with: 221 222 401 Unauthorized 223 WWW-Authenticate: PubKey.v1 224 challenge="aKMpP2pkd3qiDnOUAHJ+pB1VdphaR2tFSF4J7wLWODk=;dXNlcnNAc3ZjLmRvbWFpbi50bGQ7MTI3ODExMjc5OTsxMjcuMC4wLjE7bThvK3JUa29rRVFPMFFLRUh2L280dz09", 225 realm="users@svc.domain.tld" 226 227The client's user agent determines the client's identifier and private key 228to use for the realm. The user agent then uses this private key to sign 229the server's challenge, prompting the user as neccessary. Finally, the 230client sends a new request including the Authorization header: 231 232 Authorization: PubKey.v1 233 id="McFly", 234 challenge="aKMpP2pkd3qiDnOUAHJ+pB1VdphaR2tFSF4J7wLWODk=;dXNlcnNAc3ZjLmRvbWFpbi50bGQ7MTI3ODExMjc5OTsxMjcuMC4wLjE7bThvK3JUa29rRVFPMFFLRUh2L280dz09", 235 realm="users@svc.domain.tld", 236 signature="AAAAB3NzaC1yc2EAAAEAWARe6cScN5t0aFy0lBA1EbC/JoyRxsEuPsWtFZ3qw12lXYcmTXuq1v/0lwqcgZQgutQdiavR6O6157uyk0dkfuDXiuOjsngkmgp0oN/kwYxKPVrXMze1tFr8tFBUQU+JeCbvVd+o6LeD7pO29onXqf776N21nX1sRaeT+wX6qNMNEgJ7S3TzwTgMJ4Ub5dMCxXYCX7AW15YzLie213fvU3YiBh1ZHy//ubDb29d/2t941/gAdipjRQiabWK5lpfkmLJWJddlZq3IyFqiXMM1vpaGmiiM5w2fMpuzO8enyRTDtQQwLAxrffxY/n6RbGvUiEU4YzSGLlPE6KUU36dKOw==" 237 238The server verifies the client's signature on the following authorization 239string: 240 241 McFly;users@svc.domain.tld;aKMpP2pkd3qiDnOUAHJ+pB1VdphaR2tFSF4J7wLWODk=;dXNlcnNAc3ZjLmRvbWFpbi50bGQ7MTI3ODExMjc5OTsxMjcuMC4wLjE7bThvK3JUa29rRVFPMFFLRUh2L280dz09 242 243Assuming that the challenge generation algorithm described in section A.1 244is used, the server then verfies its own signature of the challenge by 245decoding the challenge thusly: 246 247 b64-server-signature = "aKMpP2pkd3qiDnOUAHJ+pB1VdphaR2tFSF4J7wLWODk=" 248 b64-challenge = "dXNlcnNAc3ZjLmRvbWFpbi50bGQ7MTI3ODExMjc5OTsxMjcuMC4wLjE7bThvK3JUa29rRVFPMFFLRUh2L280dz09" 249 challenge = "users@svc.domain.tld;1278112799;127.0.0.1;m8o+rTkokEQO0QKEHv/o4w==" 250 251After the server's signature is verified, it checks the realm, expiration, and 252source IP encoded in the challenge to authorize the request. 253 254 255 1.4 Proxy-Authentication and Proxy-Authorization 256 ------------------------------------------------- 257 258The PubKey.v1 authentication scheme may also be used for authenticating 259clients to proxies, proxies to proxies, or proxies to origin servers by use 260of the Proxy-Authenticate and Proxy-Authorization headers. These headers 261are instances of the Proxy-Authenticate and Proxy-Authorization headers 262specified in sections 10.33 and 10.34 of the HTTP/1.1 specification [RFC 2632616] and their behavior is subject to restrictions described there. The 264transactions for proxy authentication are very similar to those already 265described. Upon receiving a request which requires authentication, the 266proxy/server must issue the "407 Proxy Authentication Required" response 267with a "Proxy-Authenticate" header. The pubkey-challenge used in the 268Proxy-Authenticate header is the same as that for the WWW-Authenticate 269header as defined above in section 1.2.1. 270 271The client/proxy must then re-issue the request with a Proxy-Authorization 272header, with directives as specified for the Authorization header in 273section 1.2.2 above. 274 275Note that in principle a client could be asked to authenticate itself to 276both a proxy and an end-server, but never in the same response. 277 278 279 1.5 Operational Considerations 280 ------------------------------- 281 282 1.5.1 Replay Attacks 283 --------------------- 284 285The challenge generation scheme described in section A.1 includes a 286server-signed time, client IP address, and random seed; after verifying its own 287signature, the server verifies that the authorized request is from the expected 288source and within the allowed session time. 289 290The server may preempt the need for an expired transaction by sending a new 291challenge in an AuthorizationInfo header. 292 293 294 1.5.2 Man-in-the-Middle Attacks 295 -------------------------------- 296 297In principal, it is not possible to distinguish untrusted intermediaries 298from trustworthy (e.g. HTTP or SOCKS) proxy servers. Therefore, the 299PubKey.v1 scheme does not attempt to implement any form of server 300authentication or endpoint confidentiality. A client's Authorization token 301may be stolen by intermediary servers. 302 303Some form of socket-or-application-layer cryptography should be utilized to 304establish confidentiality between endpoints. 305 306 307 1.5.3 Brute Force Attacks 308 -------------------------- 309 310Brute force attacks against strong cryptographic keys (currently, RSA 2048 311or stronger) are particularly ineffective, which is a major advantage of this 312authentication scheme over, for instance, the Digest scheme. 313 314The challenge generation algorithm described in section A.1 uses a secret 315value and digest algorithm to verify the returned, signed challenge. If an 316authorized attacker gains access to this value and determine the digest 317algorithm, it can override values encoded in the server's challenge. Note 318that such an attack can only be exploited by sending a manipulated challenge 319value with a valid signature from a client authorized to the given realm. 320 321The randomized seed value in the challenge helps to mitigate cryptanalytic 322attacks on the server's secret by introducing entropy into the signature. 323 324 325 1.5.4 Spoofing by Counterfeit Servers 326 -------------------------------------- 327 328The PubKey.v1 authentication scheme does not provide any means for a client 329to validate a server. 330 331Some form of socket-or-application-layer cryptography should be utilized to 332establish confidentiality between endpoints. 333 334 335 2 References 336 ------------ 337 338[RFC 2222] Simple Authentication and Security Layer (SASL) 339[RFC 2616] Hypertext Transfer Protocol -- HTTP/1.1 340[RFC 2617] HTTP Authentication: Basic and Digest Access Authentication 341[RFC 2818] HTTP Over TLS 342[RFC 2743] Generic Security Service Application Program Interface 343 Version 2, Update 1 344[RFC 4251] The Secure Shell (SSH) Protocol Architecture 345[RFC 4252] The Secure Shell (SSH) Authentication Protocol 346 347 348Portions of this document were based directly on these references: 349 Copyright (C) The Internet Society (1999, 2006). All Rights Reserved. 350 351 352 A Appendices 353 ------------- 354 355 A.1 Challenge Generation 356 ------------------------- 357 358- From a client's perspective, the challenge value is an opaque blob of data 359to be signed. However, the server can encode data into its challenge value 360in order to authenticate clients without maintaining state for all such 361requests. One possible challenge generation scheme is discussed below, but 362it can be replaced with no impact on the protocol. 363 364 challenge-value = server-signature ";" encoded-challenge 365 366 server-signature = BASE64( DIGEST( raw-server-signature ) ) 367 raw-server-signature = raw-challenge ";" server-secret-value 368 369 encoded-challenge = BASE64( raw-challenge ) 370 371 raw-challenge = realm-value ";" ip-address ";" epoch-time ";" seed-value 372 373 epoch-time = integer 374 ip-address = <IPv4 or IPv6 address> 375 seed-value = token [RFC 2616] 376 server-secret-value = token [RFC 2616] 377 378The meanings of the values used above are as follows: 379 380 DIGEST 381 A digest algorithm such as SHA256. 382 383 epoch-time 384 The time at which the challenge was generated. The server may reference 385 this field to determine whether the authorization has expired. 386 387 ip-address 388 The IP address of the client-side of the connection on which the request 389 is being made. 390 391 realm-value 392 The realm-value specified in the WWW-Authenticate. 393 394 seed-value 395 A random value generated by the server to introduce entropy into the 396 server's signatures. 397 398 server-secret-value 399 A secret value that only the server may access. This is used to 400 'sign' a challenge. The client's Authorization is validated by 401 reconstructing the challenge with this secret. 402 403 It would also be possible for a server to use a private key instead 404 of a server-secret-value. 405 406Depending on the server's resources, it may be desirable to use a cipher 407algorithm instead of a digest algorithm. 408 409 410DRAFT VERSION 0.4.2 411-----BEGIN PGP SIGNATURE----- 412Version: GnuPG v2.0.14 (GNU/Linux) 413 414iEYEARECAAYFAkxJEZ0ACgkQkPEZLwKUCCVZeQCfb7zuztnPcEjCBF5CPtwaLJTd 415xrgAoJ4etR3erN/PstMEOJc1mjRR7OXr 416=R8Im 417-----END PGP SIGNATURE----- 418