idnits 2.17.1 draft-hammer-oauth-v2-mac-token-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 9, 2011) is 4828 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-08 == Outdated reference: A later version (-31) exists of draft-ietf-oauth-v2-11 -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST FIPS-180-3' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 5849 (Obsoleted by RFC 6749) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Hammer-Lahav 3 Internet-Draft Yahoo! 4 Intended status: Standards Track January 9, 2011 5 Expires: July 13, 2011 7 OAuth 2.0 MAC Token and Authentication 8 draft-hammer-oauth-v2-mac-token-00 10 Abstract 12 This document specifies the OAuth 2.0 MAC token type and 13 authentication scheme. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on July 13, 2011. 32 Copyright Notice 34 Copyright (c) 2011 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 5 52 2. Issuing MAC-Type Access Tokens . . . . . . . . . . . . . . . . 5 53 3. Making Requests . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.1. The Authorization Request Header . . . . . . . . . . . . . 6 55 3.2. Signature . . . . . . . . . . . . . . . . . . . . . . . . 7 56 3.2.1. Normalized Request String . . . . . . . . . . . . . . 7 57 3.2.2. hmac-sha-1 . . . . . . . . . . . . . . . . . . . . . . 11 58 3.2.3. hmac-sha-256 . . . . . . . . . . . . . . . . . . . . . 12 59 4. Verifying Requests . . . . . . . . . . . . . . . . . . . . . . 12 60 5. Scheme Extensions . . . . . . . . . . . . . . . . . . . . . . 13 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 62 6.1. Secrets Transmission . . . . . . . . . . . . . . . . . . . 13 63 6.2. Confidentiality of Requests . . . . . . . . . . . . . . . 13 64 6.3. Spoofing by Counterfeit Servers . . . . . . . . . . . . . 13 65 6.4. Plaintext Storage of Credentials . . . . . . . . . . . . . 13 66 6.5. Entropy of Secrets . . . . . . . . . . . . . . . . . . . . 14 67 6.6. Denial of Service / Resource Exhaustion Attacks . . . . . 14 68 6.7. Coverage Limitations . . . . . . . . . . . . . . . . . . . 15 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 70 7.1. The "secret" OAuth Parameter . . . . . . . . . . . . . . . 15 71 7.2. The "secret" OAuth Parameter . . . . . . . . . . . . . . . 15 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 73 Appendix A. Document History . . . . . . . . . . . . . . . . . . 16 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 OAuth 2.0 ([I-D.ietf-oauth-v2]) defines a token-based authentication 82 framework in which third-party applications (clients) access 83 protected resources using access tokens. Access tokens are obtained 84 via the resource owners' authorization from an authorization server. 86 This specification defines the MAC token type for use with the OAuth 87 2.0 framework. It defines type-specific token attributes and 88 provides a method for making authenticated HTTP requests with partial 89 cryptographic verification of the request - covering the HTTP method, 90 request URI, host, and in some cases the request body. 92 This specification does not define methods for the client to 93 specifically request a MAC-type token from the authorization server. 94 Additionally, it does not include any discovery facilities for 95 identifying which token types are supported by a resource server or 96 how the client may go about obtaining access tokens. This 97 specification assumes that the authorization server has issued the 98 client a MAC-type token and describes how the client authenticates 99 using that access token. 101 The MAC token type is not compatible with the "HMAC-SHA1" signature 102 method defined in OAuth 1.0 [RFC5849]. 104 This specification is an extension of [I-D.ietf-oauth-v2] and uses 105 its terminology. 107 Please discuss this draft on the oauth@ietf.org [1] mailing list. 109 1.1. Example 111 The client attempts to access a protected resource without 112 authentication, making the following HTTP request to the resource 113 server: 115 GET /resource/1?b=1&a=2 HTTP/1.1 116 Host: example.com 118 The resource server returns the following authentication challenge: 120 HTTP/1.1 401 Unauthorized 121 WWW-Authenticate: OAuth2 122 Date: Thu, 02 Dec 2010 21:39:45 GMT 124 The client has previously obtained a set of token credentials for 125 accessing resources on the "http://example.com/" resource server. 126 The credentials issued to the client by the authorization server 127 included the following attributes: 129 Access token: h480djs93hd8 131 Token type: mac 133 MAC algorithm: hmac-sha-1 135 Token secret: 489dks293j39 137 The client attempts the HTTP request again, this time using the token 138 credentials issued by the authorization server earlier to 139 authenticate. To construct the authentication header, the client 140 calculates the current timestamp and a nonce. The nonce is unique to 141 the timestamp used, typically a random string: 143 Timestamp: 137131200 145 Nonce: dj83hs9s 147 The client normalizes the request and constructs the signature base 148 string (the new line separator character is represented by "\n" for 149 display purposes only): 151 h480djs93hd8\n 152 137131200\n 153 dj83hs9s\n 154 GET\n 155 example.com\n 156 80\n 157 /resource/1\n 158 a=2\n 159 b=1 161 The signature base string is signed using the specified MAC token 162 algorithm "hmac-sha-1" with the signature base string as text and the 163 token secret as key. The resulting digest is base64-encoded to 164 produce the request signature: 166 IdSrHQHTwCPWGrqzGGIR791ZJXE= 168 The client includes the access token, timestamp, nonce, and signature 169 with the request using the "Authorization" request header field: 171 GET /resource/1 HTTP/1.1 172 Host: example.com 173 Authorization: MAC token='h480djs93hd8', 174 timestamp='137131200', 175 nonce='dj83hs9s', 176 signature='IdSrHQHTwCPWGrqzGGIR791ZJXE=' 178 The resource server validates the request by calculating the 179 signature again based on the request received and verifies the 180 validity and scope of the access token. If valid, the resource 181 server responds with the requested protected resource representation. 183 1.2. Notational Conventions 185 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 186 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 187 document are to be interpreted as described in [RFC2119]. 189 This document uses the Augmented Backus-Naur Form (ABNF) notation of 190 [I-D.ietf-httpbis-p1-messaging]. 192 2. Issuing MAC-Type Access Tokens 194 Authorization servers issuing MAC-type access tokens MUST include the 195 following parameters whenever a response includes the "access_token" 196 parameter: 198 secret 199 REQUIRED. The token shared secret used as the MAC algorithm 200 key. 202 algorithm 203 REQUIRED. The MAC algorithm used to calculate the request 204 signature. Value MUST be one of "hmac-sha-1", "hmac-sha-256", 205 or a registered extension algorithm name as described in 206 Section 5. 208 3. Making Requests 210 To make authenticated requests, the client must be in possession of a 211 valid MAC-type access token, issued by an authorization server 212 accepted by the resource server. The client constructs the request 213 by calculating of a set of attributes, and adding them to the HTTP 214 request using the Authorization header field (Section 3.1). 215 Authenticated request can be sent in response to an authentication 216 challenge or directly. 218 3.1. The Authorization Request Header 220 The "Authorization" request header field uses the framework defined 221 by [RFC2617] as follows: 223 credentials = 'MAC' [ RWS 1#param ] 225 param = access-token / 226 timestamp / 227 nonce / 228 signature 230 access-token = 'token' '=' quoted-string 231 timestamp = 'timestamp' '=' <"> 1*DIGIT <"> 232 nonce = 'nonce' '=' quoted-string 233 signature = 'signature' '=' quoted-string 235 The "token" attribute value is set to the access token received from 236 the authorization server. 238 The "timestamp" attribute value is set to the current time expressed 239 in the number of seconds since January 1, 1970 00:00:00 GMT, and MUST 240 be a positive integer. 242 The "nonce" attribute value is set to a random string, uniquely 243 generated by the client to allow the resource server to verify that a 244 request has never been made before and helps prevent replay attacks 245 when requests are made over an insecure channel. The nonce value 246 MUST be unique across all requests with the same timestamp and access 247 token combination. 249 To avoid the need to retain an infinite number of nonce values for 250 future checks, servers MAY choose to restrict the time period after 251 which a request with an old timestamp is rejected. Such a 252 restriction implies a level of synchronization between the client's 253 and server's clocks. The client MAY use the "Date" response header 254 field to synchronize its clock after a failed request. 256 The "signature" attribute value is set as described in Section 3.2. 258 Each of the four attributes MUST appear once, and only once. 260 3.2. Signature 262 The client uses the MAC token algorithm and the access token secret - 263 both provided by the authorization server - to calculate the request 264 signature. This specification defines two algorithms: "hmac-sha-1" 265 and "hmac-sha-256", and provides an extension registry for additional 266 algorithms. 268 3.2.1. Normalized Request String 270 The normalized request string is a consistent, reproducible 271 concatenation of several of the HTTP request elements into a single 272 string. By normalizing the request into a reproducible string, the 273 client and resource server can both sign the same string. The string 274 is constructed by concatenating together, in order, the following 275 HTTP request elements: 277 1. The access token. 279 2. A new line character (ASCII code 10). 281 3. The timestamp value calculated for the request. 283 4. A new line character (ASCII code 10). 285 5. The nonce value generated for the request. 287 6. A new line character (ASCII code 10). 289 7. The HTTP request method in upper case. For example: "HEAD", 290 "GET", "POST", etc. 292 8. A new line character (ASCII code 10). 294 9. The hostname included in the HTTP request using the "Host" 295 request header field in lower case. 297 10. A new line character (ASCII code 10). 299 11. The port as included in the HTTP request using the "Host" 300 request header field. If the header field does not include a 301 port, the default value for the scheme MUST be used (e.g. 80 for 302 HTTP and 443 for HTTPS). 304 12. A new line character (ASCII code 10). 306 13. The path component of the HTTP request URI as defined by 307 [RFC3986] section 3.3. 309 14. A new line character (ASCII code 10). 311 15. The query component of the HTTP request URI as defined by 312 [RFC3986] section 3.4, normalized as described in 313 Section 3.2.1.1. 315 For example, the HTTP request: 317 GET /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b&c2&a3=2+q HTTP/1.1 318 Host: example.com 320 using access token "kkk9d7dh3k39sjv7", timestamp "137131201", and 321 nonce "7d8f3e4a" is normalized into the following string (the new 322 line Separator character is represented by "\n" for display purposes 323 only): 325 kkk9d7dh3k39sjv7\n 326 137131201\n 327 7d8f3e4a\n 328 GET\n 329 example.com\n 330 80\n 331 /request\n 332 a2=r%20b\n 333 a3=2%20q\n 334 a3=a\n 335 b5=%3D%253D\n 336 c%40=\n 337 c2= 339 3.2.1.1. Parameters Normalization 341 The query component is parsed into a list of name/value parameter 342 pairs by treating it as an "application/x-www-form-urlencoded" 343 string, separating the names and values and decoding them as defined 344 by [W3C.REC-html401-19991224] section 17.13.4. 346 Once separated and decoded, the parameters are concatenated back 347 together as follows: 349 1. First, the name and value of each parameter are escaped using the 350 [RFC3986] percent-encoding (%XX) mechanism. Characters in the 351 unreserved character set as defined by [RFC3986] section 2.3 352 (ALPHA, DIGIT, "-", ".", "_", "~") MUST NOT be encoded. All 353 other characters MUST be encoded. The two hexadecimal characters 354 used to represent encoded characters MUST be upper case. 356 2. The parameters are sorted by name, using ascending byte value 357 ordering. If two or more parameters share the same name, they 358 are sorted by their value. 360 3. The name of each parameter is concatenated to its corresponding 361 value using an "=" character (ASCII code 61) as separator, even 362 if the value is empty. 364 4. The sorted name/value pairs are concatenated together into a 365 single string by using an new line character (ASCII code 10) as 366 separator. 368 Note that the percent-encoding method described is different from the 369 encoding scheme used by the "application/x-www-form-urlencoded" 370 content-type (for example, it encodes space characters as "%20" 371 instead of the "+" character). It MAY be different from the percent- 372 encoding functions provided by web development frameworks (e.g. 373 encode different characters, use lower case hexadecimal characters). 375 For example, the HTTP request URI: 377 /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b&c2&a3=2+q 379 Contains the following (fully decoded) parameters used in the 380 signature base sting: 382 +------+-------+ 383 | Name | Value | 384 +------+-------+ 385 | b5 | =%3D | 386 | a3 | a | 387 | c@ | | 388 | a2 | r b | 389 | c2 | | 390 | a3 | 2 q | 391 +------+-------+ 393 Note that the value of "b5" is "=%3D" and not "==". Both "c@" and 394 "c2" have empty values. While the encoding rules specified in this 395 specification for the purpose of constructing the signature base 396 string exclude the use of a "+" character (ASCII code 43) to 397 represent an encoded space character (ASCII code 32), this practice 398 is widely used in "application/x-www-form-urlencoded" encoded values, 399 and MUST be properly decoded, as demonstrated by one of the "a3" 400 parameter instances (the "a3" parameter is used twice in this 401 request). 403 The parsed parameters are normalized as follows: 405 Encoded: 407 +------+----------+ 408 | Name | Value | 409 +------+----------+ 410 | b5 | %3D%253D | 411 | a3 | a | 412 | c%40 | | 413 | a2 | r%20b | 414 | c2 | | 415 | a3 | 2%20q | 416 +------+----------+ 418 Sorted: 420 +------+----------+ 421 | Name | Value | 422 +------+----------+ 423 | a2 | r%20b | 424 | a3 | 2%20q | 425 | a3 | a | 426 | b5 | %3D%253D | 427 | c%40 | | 428 | c2 | | 429 +------+----------+ 430 Concatenated Pairs: 432 +-------------+ 433 | Name=Value | 434 +-------------+ 435 | a2=r%20b | 436 | a3=2%20q | 437 | a3=a | 438 | b5=%3D%253D | 439 | c%40= | 440 | c2= | 441 +-------------+ 443 And concatenated together into a single string (the new line 444 separator character is represented by "\n" for display purposes 445 only): 447 a2=r%20b\n 448 a3=2%20q\n 449 a3=a\n 450 b5=%3D%253D\n 451 c%40=\n 452 c2= 454 3.2.2. hmac-sha-1 456 "hmac-sha-1" uses the HMAC-SHA1 algorithm as defined in [RFC2104]: 458 digest = HMAC-SHA1 (key, text) 460 Where: 462 text 463 is set to the value of the normalize request string as 464 described in Section 3.2.1. 466 key 467 is set to the access token shared-secret provided by the 468 authorization server. 470 digest 471 is used to set the value of the "signature" attribute, after 472 the result octet string is base64-encoded per [RFC2045] section 473 6.8. 475 3.2.3. hmac-sha-256 477 "hmac-sha-1" uses the HMAC algorithm as defined in [RFC2104] together 478 with the SHA-256 hash function defined in [NIST FIPS-180-3]: 480 digest = HMAC-SHA256 (key, text) 482 Where: 484 text 485 is set to the value of the normalize request string as 486 described in Section 3.2.1. 488 key 489 is set to the access token shared-secret provided by the 490 authorization server. 492 digest 493 is used to set the value of the "signature" attribute, after 494 the result octet string is base64-encoded per [RFC2045] section 495 6.8. 497 4. Verifying Requests 499 A servers receiving an authenticated request validates it by 500 performing the following REQUIRED steps: 502 1. Recalculate the request signature as described in Section 3.2 and 503 compare it to the value received from the client via the 504 "signature" attribute. 506 2. Ensure that the combination of nonce, timestamp, and access token 507 received from the client has not been used before in a previous 508 request (the server MAY reject requests with stale timestamps; 509 the determination of staleness is left up to the server to 510 define). 512 3. Verify the scope and status of the access token. 514 If the request fails verification, the server SHOULD respond with an 515 HTTP 401 (unauthorized) status code, and SHOULD include a token 516 scheme authentication challenge using the WWW-Authenticate header 517 field. The server MAY include further details about why the request 518 was rejected using the error attribute. 520 5. Scheme Extensions 522 [[ TBD ]] 524 6. Security Considerations 526 As stated in [RFC2617], the greatest sources of risks are usually 527 found not in the core protocol itself but in policies and procedures 528 surrounding its use. Implementers are strongly encouraged to assess 529 how this protocol addresses their security requirements. 531 6.1. Secrets Transmission 533 This specification does not describe any mechanism for obtaining or 534 transmitting access token secrets. Methods used to obtain tokens 535 should ensure that these transmissions are protected using transport- 536 layer mechanisms such as TLS or SSL. 538 6.2. Confidentiality of Requests 540 While this protocol provides a mechanism for verifying the integrity 541 of requests, it provides no guarantee of request confidentiality. 542 Unless further precautions are taken, eavesdroppers will have full 543 access to request content. Servers should carefully consider the 544 kinds of data likely to be sent as part of such requests, and should 545 employ transport-layer security mechanisms to protect sensitive 546 resources. 548 6.3. Spoofing by Counterfeit Servers 550 This protocol makes no attempt to verify the authenticity of the 551 resource server. A hostile party could take advantage of this by 552 intercepting the client's requests and returning misleading or 553 otherwise incorrect responses. Service providers should consider 554 such attacks when developing services using this protocol, and should 555 require transport-layer security for any requests where the 556 authenticity of the resource server or of request responses is an 557 issue. 559 6.4. Plaintext Storage of Credentials 561 The access token shared-secret functions the same way passwords do in 562 traditional authentication systems. In order to compute the 563 signature, the server must have access to the secret in plaintext 564 form. This is in contrast, for example, to modern operating systems, 565 which store only a one-way hash of user credentials. 567 If an attacker were to gain access to these secrets - or worse, to 568 the server's database of all such secrets - he or she would be able 569 to perform any action on behalf of any resource owner. Accordingly, 570 it is critical that servers protect these secrets from unauthorized 571 access. 573 6.5. Entropy of Secrets 575 Unless a transport-layer security protocol is used, eavesdroppers 576 will have full access to authenticated requests and signatures, and 577 will thus be able to mount offline brute-force attacks to recover the 578 secret used. Authorization servers should be careful to assign 579 shared-secrets which are long enough, and random enough, to resist 580 such attacks for at least the length of time that the shared-secrets 581 are valid. 583 For example, if shared-secrets are valid for two weeks, authorization 584 servers should ensure that it is not possible to mount a brute force 585 attack that recovers the shared-secret in less than two weeks. Of 586 course, authorization servers are urged to err on the side of 587 caution, and use the longest secrets reasonable. 589 It is equally important that the pseudo-random number generator 590 (PRNG) used to generate these secrets be of sufficiently high 591 quality. Many PRNG implementations generate number sequences that 592 may appear to be random, but which nevertheless exhibit patterns or 593 other weaknesses which make cryptanalysis or brute force attacks 594 easier. Implementers should be careful to use cryptographically 595 secure PRNGs to avoid these problems. 597 6.6. Denial of Service / Resource Exhaustion Attacks 599 This specification includes a number of features which may make 600 resource exhaustion attacks against servers possible. For example, 601 this protocol requires servers to track used nonces. If an attacker 602 is able to use many nonces quickly, the resources required to track 603 them may exhaust available capacity. And again, this protocol can 604 require servers to perform potentially expensive computations in 605 order to verify the signature on incoming requests. An attacker may 606 exploit this to perform a denial of service attack by sending a large 607 number of invalid requests to the server. 609 Resource Exhaustion attacks are by no means specific to this 610 specification. However, implementers should be careful to consider 611 the additional avenues of attack that this protocol exposes, and 612 design their implementations accordingly. For example, entropy 613 starvation typically results in either a complete denial of service 614 while the system waits for new entropy or else in weak (easily 615 guessable) secrets. When implementing this protocol, servers should 616 consider which of these presents a more serious risk for their 617 application and design accordingly. 619 6.7. Coverage Limitations 621 The normalized request string has been designed to support the 622 authentication methods defined in this specification. Those 623 designing additional methods, should evaluated the compatibility of 624 the normalized request string with their security requirements. 625 Since the normalized request string does not cover the entire HTTP 626 request, servers should employ additional mechanisms to protect such 627 elements. 629 7. IANA Considerations 631 7.1. The "secret" OAuth Parameter 633 Parameter name: secret 635 Parameter usage location: The end-user authorization endpoint 636 response and the token endpoint response. 638 Change controller: IETF 640 Specification document(s): [[ this document ]] 642 Related information: None 644 7.2. The "secret" OAuth Parameter 646 Parameter name: secret 648 Parameter usage location: The end-user authorization endpoint 649 response and the token endpoint response. 651 Change controller: IETF 653 Specification document(s): [[ this document ]] 655 Related information: None 657 8. Acknowledgments 659 The author would like to thank [[ some people ]] for their 660 suggestions, feedback, and continued support. 662 Appendix A. Document History 664 [[ To be removed by the RFC editor before publication as an RFC. ]] 666 -00 668 o Initial draft. 670 9. References 672 9.1. Normative References 674 [I-D.ietf-httpbis-p1-messaging] 675 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 676 Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, 677 "HTTP/1.1, part 1: URIs, Connections, and Message 678 Parsing", draft-ietf-httpbis-p1-messaging-08 (work in 679 progress), October 2009. 681 [I-D.ietf-oauth-v2] 682 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 683 2.0 Protocol Framework", draft-ietf-oauth-v2-11 (work in 684 progress), November 2010. 686 [NIST FIPS-180-3] 687 National Institute of Standards and Technology, "Secure 688 Hash Standard (SHS). FIPS PUB 180-3, October 2008". 690 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 691 Extensions (MIME) Part One: Format of Internet Message 692 Bodies", RFC 2045, November 1996. 694 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 695 Hashing for Message Authentication", RFC 2104, 696 February 1997. 698 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 699 Requirement Levels", BCP 14, RFC 2119, March 1997. 701 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 702 Leach, P., Luotonen, A., and L. Stewart, "HTTP 703 Authentication: Basic and Digest Access Authentication", 704 RFC 2617, June 1999. 706 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 707 Resource Identifier (URI): Generic Syntax", STD 66, 708 RFC 3986, January 2005. 710 [W3C.REC-html401-19991224] 711 Hors, A., Jacobs, I., and D. Raggett, "HTML 4.01 712 Specification", World Wide Web Consortium 713 Recommendation REC-html401-19991224, December 1999, 714 . 716 9.2. Informative References 718 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 719 April 2010. 721 URIs 723 [1] 725 Author's Address 727 Eran Hammer-Lahav 728 Yahoo! 730 Email: eran@hueniverse.com 731 URI: http://hueniverse.com