idnits 2.17.1 draft-salgueiro-secure-state-management-06.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 (February 20, 2012) is 4441 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) == Unused Reference: '8' is defined on line 784, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2818 (ref. '2') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2616 (ref. '3') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-23) exists of draft-ietf-httpstate-cookie-22 ** Obsolete normative reference: RFC 5246 (ref. '5') (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. '9') ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '10') ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '11') Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Gonzalo Salgueiro 3 Internet Draft Cisco Systems 4 Intended status: Standards Track Paul E. Jones 5 Expires: August 20, 2012 Cisco Systems 6 February 20, 2012 8 Securing HTTP State Management Information 9 draft-salgueiro-secure-state-management-06.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on August 20, 2012. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. 46 Abstract 48 Virtually every application on the web today that allows a user to 49 log in or manipulate information stored on a server maintains some 50 form of state management information. Usually, the session context 51 is established through the use of a Uniform Resource Locator (URL) 52 parameter or a Hypertext Transfer Protocol (HTTP) cookie that 53 identifies the session. Without the use of Transport Layer Security 54 (TLS), such an information exchange introduces a security risk. For 55 a variety of reasons, TLS may not be desired or preferred in all 56 situations and, in those cases, users are left vulnerable. This 57 memo provides a simple method for enabling secure exchange of state 58 management information through HTTP in situations where TLS is not 59 employed. 61 Table of Contents 63 1. Introduction...................................................2 64 2. Conventions used in this document..............................4 65 3. Capability Advertisement.......................................4 66 4. Security Associations..........................................5 67 4.1. Establishing a Security Association.......................5 68 4.2. Establishing a Security Association over HTTPS............6 69 4.3. Establishing a Security Association using Diffie-Hellman..8 70 5. Transmitting Information from the User Agent..................10 71 6. Transmitting Information from the Server......................13 72 7. Example Usage to Log into a Social Network Service............13 73 8. Security Considerations.......................................16 74 9. IANA Considerations...........................................16 75 10. References...................................................16 76 10.1. Normative References....................................16 77 10.2. Informative References..................................17 78 11. Acknowledgments..............................................17 80 1. Introduction 82 Though we have HTTPS (HTTP over TLS) [2] for securing communication 83 between HTTP [3] user agents (i.e., web browsers) and web servers, 84 there are many web applications and web sites that rely on insecure 85 connections to exchange state management information in the form of 86 HTTP URL parameters or cookies [4] that could allow rogue entities 87 to gain access to protected resources. Even in environments where 88 secure connections are used for initially authenticating users, the 89 sessions established and associated with the User Agent often use a 90 simple cookie exchange over an insecure connection for subsequent 91 information exchanges, thus securing only the user's password, but 92 not the session itself. This allows HTTP sessions to be hijacked by 93 any entity that can observe the state management information. This 94 memo provides a simple method for enabling secure exchange of state 95 management information through HTTP in situations where TLS [5] is 96 not employed. 98 One could use HTTPS everywhere on the Internet, but there are 99 reasons why that is not always desired or preferred: 101 1. In practice, the use of HTTPS requires a unique IP address per 102 URL (i.e., https://www1.example.com and https://www2.example.com 103 would have to have two different IP addresses, even if these are 104 on the same physical machines). While Section 3 of RFC 4366 [6] 105 does address this concern, widespread adoption is slow and does 106 not address the other concerns listed below. 108 2. Using HTTPS consumes more processing time and resources, an issue 109 that is only compounded when there are several small transactions 110 over separate connections. 112 3. Using HTTPS on the Internet requires the purchase of digital 113 certificates and, depending on one's environment, this can be 114 costly. It is understood that private networks can use self- 115 signed certificates, but that does not address the more general 116 Internet use cases. 118 4. Installing and updating digital certificates takes time, thus 119 increasing Total Cost of Ownership (TCO). 121 5. Expired certificates drive visitors away in fear due to security 122 warnings presented by web browsers. 124 6. Encrypting the entire session is not needed in many instances, 125 especially when communicating with web sites that only exchange 126 publicly available information (e.g., bulletin boards and blogs). 127 Even though encryption is not critical for some applications, 128 most would agree that proper state management is nonetheless 129 important. 131 7. Encrypting the entire session prevents routers or other devices 132 from efficiently compressing otherwise highly compressible plain 133 ASCII text over low bit-rate links. 135 For one or more of these stated reasons, many web applications 136 exchange state management information that should be secured over 137 insecure connections. Therefore, application developers need a 138 method of providing an acceptable level of security for selected 139 state management information that does not require the use of HTTPS. 141 In our previous draft, we proposed the use of "Secure Cookies". 142 This was met with mixed reactions. Some supported the idea of 143 introducing a cookie that could be secured, but some rightfully 144 argued that cookies themselves could be encrypted at the server and 145 so there was no need to secure the cookie. Rather, we need to focus 146 only on securing the session. Our previous draft still enabled a 147 Man-In-The-Middle attack when using HTTP, even when security 148 credentials were exchanged over a secure connection. 150 In this draft, we allow the client and server to establish one or 151 more security associations over HTTP or, preferably, HTTPS. For the 152 purpose of this memo, a security association is defined by use of a 153 specific Message Authentication Code (MAC) function along with a 154 shared secret. 156 2. Conventions used in this document 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC 2119 [1]. 162 3. Capability Advertisement 164 In every request from the user agent to the server, the user agent 165 MUST advertise its support for the Secure State Management 166 procedures defined in this document. This is necessary in order to 167 establish the initial security association, but is also necessary in 168 order to force a client to re-establish a security association that 169 is no longer valid or no longer recognized by the server. 171 The capability advertisement comes in the form of a header that 172 enumerates the Message Authentication Code (MAC) functions supported 173 by the user agent. The syntax of the new header, like other headers 174 introduced in this memo, follows the syntax of other headers in HTTP 175 and is: 177 SSM-Functions = "SSM-Functions" ":" MAC-Function 178 *["," *SP MAC-Function] 180 MAC-Function = "hmac-md5" | "hmac-sha-1" | "hmac-sha-256" | 181 "hmac-sha-512" | 1*token 183 Note that the comparison of MAC functions names MUST be case 184 insensitive. In this document, the MAC functions all utilize the 185 HMAC [11] specification, though clients and servers MAY support 186 other MAC functions. 188 Clients MAY support any number of MAC functions, but MUST support 189 either HMAC with MD5 [10] ("hmac-md5") or HMAC with SHA-1 [9] 190 ("hmac-sha-1"). Servers MUST support both hmac-md5 and hmac-sha-1 191 and SHOULD support a wide variety of popular MAC functions. 193 Using the above syntax, the following is an example header 194 transmitted by a user agent: 196 SSM-Functions: hmac-md5, hmac-sha-1 198 Note that the server always selects the MAC function to employ from 199 among those offered by the client. 201 4. Security Associations 203 In order to provide a means of exchanging information securely in a 204 session, the client and server must establish one or more security 205 association(s). The association defines the MAC function and shared 206 secret to be used when transmitting information between the client 207 and server. 209 The security association is assigned a handle by the server and is 210 used in subsequent requests from the client. The format of that 211 association handle is discussed in Sections 5 and 6. 213 In order to allow for multiple concurrent requests, a client MAY 214 establish multiple security associations with the server. For 215 example, each tab on a web browser MAY establish its own 216 client/server security association. Additionally, a client assigns 217 a session handle for each concurrent session that exists within the 218 scope of the security association. A client MUST NOT issue 219 concurrent requests that utilize the same security association 220 handle and session handle, as the server will not be able to 221 differentiate between legitimate requests and requests that are, in 222 fact, replay attacks. A client MAY issue concurrent requests that 223 utilize the same security association handle and different session 224 handles. 226 Once an association has been established, it MAY be used 227 subsequently over either HTTP or HTTPS when the client issues 228 requests to the server. 230 4.1. Establishing a Security Association 232 To issue a request that allows for the possibility of establishing a 233 new security association, the user agent sends a message to the 234 server with a SSM-Functions header, such as the following: 236 GET / HTTP/1.1 237 SSM-Functions: hmac-md5, hmac-sha-1 239 In the following two sections, we discuss how a security association 240 is established using HTTPS or HTTP (with Diffie-Hellman). 242 4.2. Establishing a Security Association over HTTPS 244 The server SHOULD use HTTPS as the means of establishing the 245 security association. By using HTTPS, the encryption key is 246 transmitted as plaintext over the encrypted HTTPS connection from 247 the server to the client. 249 Once the security association is created via HTTPS, the client may 250 be directed to use HTTP for subsequent requests. SSM-Parameters 251 header may then be used to transmit requests over HTTP and be 252 assured that the important parts of the request or response will not 253 be manipulated. 255 When using HTTPS and establishing a new security association, the 256 server MUST reply to requests that contain the SSM-Functions header 257 and that do not demonstrate having a valid security association with 258 a 401 Unauthorized as shown below: 260 HTTP/1.1 401 Unauthorized 261 WWW-Authenticate: SSM assoc=12345, func=hmac-sha-1, secret=yyyy 263 In the above, there are several parameters that are introduced that 264 need discussion. They are: 266 assoc 268 This is an association handle assigned by the web server. 269 This handle is comprised of ASCII characters constrained to 270 upper or lowercase letters and digits (ALPHA and/or DIGIT as 271 defined in 2.2 of [3]). The length of this handle MUST NOT 272 exceed 64 octets. 274 func 276 This is the MAC function selected by the server. The server 277 MUST specify exactly one MAC function. 279 secret 281 This parameter contains the Base64-encoded shared secret in 282 network byte order that will be used when computing the MAC 283 transmitted from or to the server. The number of octets that 284 comprise the secret MUST be equal to or greater than the 285 number of octets produced by the MAC function or, if 286 applicable, the underlying hash function, whichever is 287 greater. However, the number of octets that comprise the 288 secret should not be more than two times the number of octets 289 produced by the selected function. (For example, HMAC-SHA-1 290 produces a 20-octet MAC. Therefore, the shared secret should 291 be between 20 and 40 octets, inclusive.) Note that the secret 292 must be Base64-decoded prior to consumption by the MAC 293 function. 295 The reason for replying with a 401 rather than returning a 200 296 response to the request along with a security key is that the client 297 may wish to transmit state management information, but does not have 298 a valid security association that it can utilize. The 401 response 299 allows the server to reject the request and establish a security 300 association that may then be used subsequently in requests from the 301 client. 303 Once the client has received this information, it MAY re-issue the 304 request as in the following example: 306 GET / HTTP/1.1 307 SSM-Functions: hmac-md5, hmac-sha-1 308 SSM-Parameters: assoc=12345; session=1; nonce=1; 309 components=Request-Line; 310 mac=2aae6c35c94fcfb415dbe95f408b9ce91ee846ed 312 As shown in this example, the User Agent continues to advertise the 313 supported MAC functions. This is necessary in case the association 314 expires between requests, prompting the server to return a 401 315 Unauthorized to facilitate the establishment of a new association. 316 Note that the length of time that a server wishes to allow an 317 association to remain valid is outside the scope of this memo. 319 In cases where the client and server are communicating using HTTP 320 and the server wishes to force the client to switch transports to 321 HTTPS to transmit a shared secret, the server rejects the HTTP 322 request as shown below: 324 HTTP/1.1 401 Unauthorized 325 WWW-Authenticate: SSM transport=https, port=443 327 In the above, there is a single case-insensitive parameter called 328 "transport" and an optional "port" parameter that defaults to port 329 443. The only value presently defined for transport is "https". 330 When the client receives this response, it re-issues the request 331 using HTTPS. This will result in a subsequent 401 similar to the 332 first example in this section wherein the server provides the shared 333 secret to the client. Once the client has the shared secret in hand, 334 it then re-issues the request using HTTP (not HTTPS). 336 4.3. Establishing a Security Association using Diffie-Hellman 338 HTTP servers MAY use a Diffie-Hellman (DH) key exchange [7] to 339 establish a security association that will be used to encrypt 340 sensitive state management information. 342 It is a well-known fact that use of Diffie-Hellman is subject to a 343 Man-in-the-Middle attack. While this security vulnerability exists, 344 it is nonetheless better than the situation we have today where 345 anyone can easily grab state management information and hijack a 346 session. Further, a Man-in-the-Middle attack requires an active 347 attacker, whereas session stealing is a much easier passive attack. 349 In situations where transmitted information is sensitive or the risk 350 of a Man-in-the-Middle attack is significant, HTTPS SHOULD be used 351 to establish security associations. 353 When using HTTP to establish a new security association, the server 354 MUST reply to requests that do not contain a security association 355 with a 401 Unauthorized as shown below: 357 HTTP/1.1 401 Unauthorized 358 WWW-Authenticate: SSM assoc=12345, g=2, p=yyyy, A=xxxx, 359 func=hmac-sha-1 361 In the above, there are several parameters that facilitate the DH 362 key exchange and establishment of an association. They are: 364 assoc 366 This is an association handle assigned by the web server. 367 This handle is comprised of ASCII characters constrained to 368 upper or lowercase letters and digits (ALPHA and/or DIGIT as 369 defined in 2.2 of [3]). The length of this handle MUST NOT 370 exceed 64 octets. 372 g 374 The value "g" is a primitive root mod "p" as defined by the DH 375 key exchange algorithm. This parameter is OPTIONAL and, when 376 absent, the value 0x02 MUST be assumed. 378 p 380 This is a large prime number that MUST be used by the client 381 and server as a part of the DH key exchange algorithm. This 382 parameters is OPTIONAL and, if absent, the value used MUST be 383 0xDCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866 384 E61EF75A2E27898B057F9891C2E27A639C3F29B60814581CD3B2CA3986D268 385 3705577D45C2E7E52DC81C7A171876E5CEA74B1448BFDFAF18828EFD2519F1 386 4E45E3826634AF1949E5B535CC829A483B8A76223E5D490A257F05BDFF16F2 387 FB22C583AB. 389 A 391 This is the result computed by the server A=g^a mod p, where 392 "a" is a secret large integer not transmitted over the 393 network. 395 func 397 This is the MAC function selected by the server. The server 398 MUST specify exactly one MAC function. 400 Once the client has received this information, it MUST complete the 401 DH key exchange and association establishment by re-issuing the 402 request as in the following example: 404 GET / HTTP/1.1 405 SSM-Functions: hmac-md5, hmac-sha-1 406 SSM-Parameters: assoc=12345; nonce=1; components=Request-Line; 407 B=zzzz; mac=2aae6c35c94fcfb415dbe95f408b9ce91ee846ed 409 As shown in this example, the User Agent continues to advertise the 410 supported MAC functions. This is necessary in case the association 411 expires or otherwise becomes invalid between requests, prompting the 412 server to return a 401 Unauthorized to facilitate the establishment 413 of a new association. Note that the length of time that a server 414 wishes to allow an association to remain valid is outside the scope 415 of this memo. 417 Included in the above request is the header SSM-Parameters, which 418 completes the association. It includes several parameters that are 419 included in all requests from the client when exchanging secure 420 state management information. We will cover the majority of the 421 parameters in Section 5, but we will discuss the B parameter here 422 since it applies only when initially establishing a security 423 association using Diffie-Hellman: 425 B 427 This is the result computed by the client B=g^b mod p, where 428 "b" is a secret large integer not transmitted over the 429 network. 431 Subsequent requests from the client to the server need not include 432 the "B" parameter as a part of the SSM-Parameters header, since the 433 association would have been fully formed and SHOULD be ignore by the 434 server when received. 436 Per the Diffie-Hellman algorithm, a shared secret is derived from 437 the values created locally and received over the network from the 438 peer. The shared secret, K, is an integer that MUST be consumed by 439 both the client and server in the same way. Therefore, the value K 440 MUST be converted into a string of octets in network byte order. 441 The shared secret is the n least significant bits, where n is the 442 number of bits equal to two times the number of bits generated by 443 the selected MAC function or, if applicable, the underlying hash 444 function, whichever is greater. If the integer is too small to 445 yield enough bits, then the most significant bits of the shared 446 secret MUST be zero-filled until the length is n bits long. 448 Integers defined in this section that are transmitted in messages 449 (i.e., A, B, g, and p) MUST be represented in network byte order, 450 zero-filling the most significant bits in order to fit the integer 451 into an integral number of octets, then Base64-encoded. 453 Note that all integers are positive numbers and care should be taken 454 to ensure that the most significant bit is not misinterpreted to be 455 a sign bit. 457 5. Transmitting Information from the User Agent 459 When issuing requests to the server and having what it believes to 460 be a valid association handle, the user agent MUST include the SSM- 461 Functions and SSM-Parameters headers in the request. The following 462 example shows such a request: 464 GET / HTTP/1.1 465 SSM-Functions: hmac-md5, hmac-sha-1 466 SSM-Parameters: assoc=12345; session=1; nonce=1; 467 components=Request-Line; 468 mac=2aae6c35c94fcfb415dbe95f408b9ce91ee846ed 470 There are several parameters included in the SSM-Parameters header 471 as described below: 473 assoc 475 This is an association handle assigned by the web server and 476 MUST be provided exactly as it was received. The client MUST 477 NOT assume this handle is encoded in any particular way. 479 session 480 This is an optional session handle created by the user agent 481 to enable it to issue concurrent requests using the same 482 security association. This handle is comprised of ASCII 483 characters constrained to upper or lowercase letters and 484 digits (ALPHA and/or DIGIT as defined in 2.2 of [3]). The 485 length of this handle MUST NOT exceed 64 octets. If this 486 handle is absent, the server MUST assume the session handle 487 has the value NULL (i.e., zero-length string). Note that, 488 while a client can generate any number of session handles, the 489 web server is not required to track more than 128 handles per 490 security association. {Editor's note: in order to allow 491 browser windows and JavaScript code to issue requests using 492 the same security association, perhaps a JavaScript function 493 should be provided by the browser to assign a unique session 494 identifier?} 496 nonce 498 The nonce is a monotonically increasing integer in the range 499 from 0 to 2^64 - 1. To enable concurrent requests, each 500 session identified by the session parameter has its own nonce 501 space. It is presented and consumed by the MAC function in 502 ASCII text form. Once this integer reaches 2^64, a new 503 association MUST be created. The user agent selects the 504 initial value for the nonce, which is RECOMMENDED to be a 505 random value in the range of 0 to 2^32 -1. 507 components 509 This optional parameter contains a comma-separated list of 510 message components that are included in the message over which 511 a MAC is computed. Those components MAY be any one of these 512 components defined in [3]: 514 Request-Line 515 Status-Line 516 message-header 517 message-body 519 If used, the message-body MUST be consumed by the MAC function 520 without modification. All other components MUST be consumed 521 by the MAC function as-is (including all whitespace and the 522 colon that separates the header from its value), except that 523 any CR or LF characters MUST NOT be consumed. Each of the 524 components is consumed by the MAC function in the order in 525 which they are presented in the components parameter. 527 Headers used to generate the MAC MAY appear more than once in 528 the message. In such a case, all headers with the same name 529 must be consumed in the order transmitted on the wire. It is 530 ill-advised to include headers that are intended to be 531 modified my intermediaries, such as the Via header, as doing 532 so will likely result in errors computing the MAC. 534 mac 536 The mac parameter is a case-insensitive hex representation of 537 the Message Authentication Code generated by the MAC function 538 in use with this security association, presented in network 539 byte order. The mac is computed as follows: 541 mac = message_authentication_function(secret,message); 543 where 545 message = (Request-Line || 546 Status-Line || 547 message-header || 548 message-body || 549 assoc || 550 session || 551 nonce); 553 The value of secret is the octets obtained from decoding the 554 Base64-encoded secret parameter in the WWW-Authenticate header 555 (when using HTTPS) or the n least significant bits of K when 556 using Diffie-Hellman as explained in Section 4.3. 558 It is permissible to indicate in the components that a non- 559 existent header or a zero-length message body is used as a 560 part of the "message". In that case, there is nothing to 561 concatenate and there is no impact on the "message" over which 562 the MAC is generated, but does add to the integrity of the 563 request or response. For example, indicating that the 564 message-body is a part of the "message" when a message-body 565 does not exist prevents an intermediary from altering or 566 fabricating the message-body. 568 The server is able to associate the client using the association 569 handle. It is able to validate the request by computing the MAC 570 following the same recipe and comparing the computed MAC value with 571 that received from the client. 573 If the server is unable to verify the MAC, the server MUST return a 574 401 prompting the client to attempt to create a new association. 575 However, the server MUST NOT invalidate the association handle, 576 since the reason the MAC may have failed to compare properly is 577 because a rogue user agent is attempting to use a handle not 578 assigned to it. 580 If the server receives a request from a client using a nonce value 581 that is less than a nonce value already presented by a trusted user 582 agent, then the server MUST return a 401 error. The server MUST NOT 583 invalidate the association, since a rogue user agent may attempt to 584 re-use a previously used nonce value. 586 6. Transmitting Information from the Server 588 When a client send a request message to the server as described in 589 Section 5, the server MUST include in the response an SSM-Parameters 590 header as shown in this example: 592 HTTP/1.1 200 OK 593 SSM-Parameters: assoc=12345; session=1; nonce=1; 594 components=Status-Line,Set-Cookie,message-body; 595 mac=3931ff3e9a70d77c6b677b95d9ab7c6aed80d610 597 The parameters are identical to those defined in Section 5. One 598 important point to note is that the nonce value in the response MUST 599 match the nonce value used in the request. 601 If the client receives a response from the server containing a MAC 602 that it cannot validate, then it must treat the response as invalid. 603 There are only three possible reasons why the MAC does not validate, 604 which include a software logic error, modification of the message as 605 it passed through the network, or data corruption (either on the 606 wire or at the remote server). Assuming the latter, the client MAY 607 re-issue the request, but repeated failure to validate the MAC would 608 suggest messages are being altered. 610 7. Example Usage to Log into a Social Network Service 612 In this section, we will discuss a typical exchange where a user 613 visits a social network service and logs in. 615 The initial request from the client is a typical request to get the 616 main page of the site. At the outset, there are no security 617 associations nor a need for one. A user agent might transmit the 618 following request: 620 GET / HTTP/1.1 621 Host: social.example.com 622 SSM-Functions: hmac-md5, hmac-sha-1 624 In response, the server will return a web page that introduces the 625 social site: 627 HTTP/1.1 200 OK 628 Content-Type: text/html; charset=UTF-8 630 Included in the response would be the message body containing HTML 631 with various link, including a link to a "login" page. Note that, 632 up to this point, no security association has been established with 633 the server. 635 The user then clicks on the button to log into the service. This 636 link directs the user agent to a login page served over an HTTPS 637 connection. The initial user agent request might look like this: 639 GET /login/ HTTP/1.1 640 Host: social.example.com 641 SSM-Functions: hmac-md5, hmac-sha-1 643 At this point, the server returns a response to form the security 644 association: 646 HTTP/1.1 401 Unauthorized 647 WWW-Authenticate: SSM assoc=12345, func=hmac-sha-1, 648 secret=Y3VwaWQ= 650 The user agent then re-issues the request to the server, but this 651 time including the information to demonstrate that the security 652 association has been formed: 654 GET /login/ HTTP/1.1 655 Host: social.example.com 656 SSM-Functions: hmac-md5, hmac-sha-1 657 SSM-Parameters: assoc=12345; nonce=1; components=Request-Line; 658 mac=f1784693e4bdefa9b5a1a0348fdc0791c307ed9a 660 Note that since a "session" parameter was not provided, the server 661 assumes the value of "session" is NULL. 663 The server can then validate the MAC to ensure that the client has 664 formed the association. The server will then respond to the request 665 with a new HTML page that prompts the user for a login and password, 666 like this: 668 HTTP/1.1 200 OK 669 SSM-Parameters: assoc=12345; nonce=1; components=Status-Line; 670 mac=2b5cb730dac7e93e3c991918c503c8e87bd7cc82 671 Content-Type: text/html; charset=UTF-8 673 The user enters his username and password and click a button on the 674 browser that results in a POST to the web server, like this: 676 POST /login/process/ HTTP/1.1 677 Host: social.example.com 678 SSM-Functions: hmac-md5, hmac-sha-1 679 SSM-Parameters: assoc=12345; nonce=2; 680 components=Request-Line,message-body; 681 mac=d632e1b7bc895fc2ce7752bade188b85f5d1c93a 682 Content-Type: application/x-www-form-urlencoded 683 Content-Length: 32 685 user=someuserid+password=abcd123 687 Upon receiving this request and successfully validating the MAC and 688 authenticating the user, the web server might then redirect the user 689 agent to an HTTP-accessible page (versus HTTPS) where the user can 690 then interact with the social network service. This redirection 691 might look like this: 693 HTTP/1.1 302 Found 694 Location: http://social.example.com/home/ 695 SSM-Parameters: assoc=12345; nonce=2; components=Status-Line; 696 mac=27283a874b10b9d86b50d3fa7426dd275afaeb02 697 Content-Length: 0 699 Note that the 302, while not a final response to the original HTTP 700 request, is considered as such for the purposes of this memo. The 701 next request to the same host, security association, and session 702 MUST use a different nonce in order to avoid a replay attack. 704 Since the host did not change, the user agent may assume that the 705 security association is still valid. It then issues the following 706 request: 708 GET /home/ HTTP/1.1 709 Host: social.example.com 710 SSM-Functions: hmac-md5, hmac-sha-1 711 SSM-Parameters: assoc=12345; nonce=3; components=Request-Line; 712 mac=4e51022cb7c25cc1706056d85f34a095e4a6e4e5 714 Knowing that user "someuserid" logged in and was associated on the 715 server with the association handle "12345" and validating the MAC, 716 the server may then serve the content that it should provide to that 717 user. It does so with a normal 200 response that includes the HTML 718 or other content. 720 While the user is interacting with the server, additional tabs or 721 background threads may be launched that perform parallel requests to 722 the server. Each of these separate windows or threads must use a 723 different and unique "session" attribute. The following request, 724 for example, might be issued by a background thread that polls a 725 user's message inbox: 727 GET /inbox/ HTTP/1.1 728 Host: social.example.com 729 SSM-Functions: hmac-md5, hmac-sha-1 730 SSM-Parameters: assoc=12345; session=ajax-thread-6; nonce=346353; 731 components=Request-Line; 732 mac=fbeb80b87dd8f03c418d44e4129006dca6a42dd7 734 8. Security Considerations 736 Some procedures defined in this memo rely on the Diffie-Hellman key 737 exchange algorithm, which are subject to a Man-in-the-Middle attack. 738 Users should be aware of this fact and utilize HTTPS to establish a 739 security association as per Section 4.2 whenever one needs to guard 740 against such attacks. 742 Note that traditionally, HTTP cookies are used to associate a user 743 with a user agent. The procedures defined in this memo allow the 744 server to identify the user via an association handle. If HTTP 745 cookies are used in conjunction with the Secure State Management 746 procedure defined herein, then the server should verify that the 747 cookie(s) used to identify a user map to the same user identified by 748 the association handle. 750 The procedures defined in this memo are not a replacement for HTTPS 751 and merely serve to strengthen the use of HTTP over insecure 752 connections that wish to provide for exchange of secure state 753 management information. 755 9. IANA Considerations 757 TBD. 759 10. References 761 10.1. Normative References 763 [1] Bradner, S., "Key words for use in RFCs to Indicate 764 Requirement Levels", BCP 14, RFC 2119, March 1997. 766 [2] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 768 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 769 L., Leach, P. and T. Berners-Lee, "Hypertext 770 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 772 [4] Barth, A., "HTTP State Management Mechanism", draft-ietf- 773 httpstate-cookie-22, February 2011. 775 [5] Dierks, T. and E. Rescorla, "The Transport Layer Security 776 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 778 [6] Eastlake, D., "Transport Layer Security (TLS) Extensions: 779 Extension Definitions", RFC 6066, January 2011. 781 [7] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 782 2631, June 1999. 784 [8] Josefsson, S., "The Base16, Base32, and Base64 Data 785 Encodings", RFC 4648, October 2006. 787 [9] Eastlake, D., Jones, P., "US Secure Hash Algorithm 1 (SHA1)", 788 RFC 3174, September 2001. 790 [10] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 791 April 1992. 793 [11] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing 794 for Message Authentication", RFC 2104, February 1997. 796 10.2. Informative References 798 None. 800 11. Acknowledgments 802 This document was prepared using 2-Word-v2.0.template.dot. 804 Authors' Addresses 806 Gonzalo Salgueiro 807 Cisco Systems, Inc. 808 7025 Kit Creek Rd. 809 Research Triangle Park, NC 27709 810 USA 812 Phone: +1 919 392 3266 813 Email: gsalguei@cisco.com 814 Paul E. Jones 815 Cisco Systems, Inc. 816 7025 Kit Creek Rd. 817 Research Triangle Park, NC 27709 819 Phone: +1 919 476 2048 820 Email: paulej@packetizer.com