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