Network Working Group Gonzalo Salgueiro Internet Draft Cisco Systems Intended status: Standards Track Paul E. Jones Expires: August 20, 2012 Cisco Systems February 20, 2012 Securing HTTP State Management Information draft-salgueiro-secure-state-management-06.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 20, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Salgueiro, et al. Expires August 20, 2012 [Page 1] Internet-Draft Secure State Management February 2012 Abstract Virtually every application on the web today that allows a user to log in or manipulate information stored on a server maintains some form of state management information. Usually, the session context is established through the use of a Uniform Resource Locator (URL) parameter or a Hypertext Transfer Protocol (HTTP) cookie that identifies the session. Without the use of Transport Layer Security (TLS), such an information exchange introduces a security risk. For a variety of reasons, TLS may not be desired or preferred in all situations and, in those cases, users are left vulnerable. This memo provides a simple method for enabling secure exchange of state management information through HTTP in situations where TLS is not employed. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................4 3. Capability Advertisement.......................................4 4. Security Associations..........................................5 4.1. Establishing a Security Association.......................5 4.2. Establishing a Security Association over HTTPS............6 4.3. Establishing a Security Association using Diffie-Hellman..8 5. Transmitting Information from the User Agent..................10 6. Transmitting Information from the Server......................13 7. Example Usage to Log into a Social Network Service............13 8. Security Considerations.......................................16 9. IANA Considerations...........................................16 10. References...................................................16 10.1. Normative References....................................16 10.2. Informative References..................................17 11. Acknowledgments..............................................17 1. Introduction Though we have HTTPS (HTTP over TLS) [2] for securing communication between HTTP [3] user agents (i.e., web browsers) and web servers, there are many web applications and web sites that rely on insecure connections to exchange state management information in the form of HTTP URL parameters or cookies [4] that could allow rogue entities to gain access to protected resources. Even in environments where secure connections are used for initially authenticating users, the sessions established and associated with the User Agent often use a simple cookie exchange over an insecure connection for subsequent information exchanges, thus securing only the user's password, but not the session itself. This allows HTTP sessions to be hijacked by any entity that can observe the state management information. This Salgueiro, et al. Expires August 20, 2012 [Page 2] Internet-Draft Secure State Management February 2012 memo provides a simple method for enabling secure exchange of state management information through HTTP in situations where TLS [5] is not employed. One could use HTTPS everywhere on the Internet, but there are reasons why that is not always desired or preferred: 1. In practice, the use of HTTPS requires a unique IP address per URL (i.e., https://www1.example.com and https://www2.example.com would have to have two different IP addresses, even if these are on the same physical machines). While Section 3 of RFC 4366 [6] does address this concern, widespread adoption is slow and does not address the other concerns listed below. 2. Using HTTPS consumes more processing time and resources, an issue that is only compounded when there are several small transactions over separate connections. 3. Using HTTPS on the Internet requires the purchase of digital certificates and, depending on one's environment, this can be costly. It is understood that private networks can use self- signed certificates, but that does not address the more general Internet use cases. 4. Installing and updating digital certificates takes time, thus increasing Total Cost of Ownership (TCO). 5. Expired certificates drive visitors away in fear due to security warnings presented by web browsers. 6. Encrypting the entire session is not needed in many instances, especially when communicating with web sites that only exchange publicly available information (e.g., bulletin boards and blogs). Even though encryption is not critical for some applications, most would agree that proper state management is nonetheless important. 7. Encrypting the entire session prevents routers or other devices from efficiently compressing otherwise highly compressible plain ASCII text over low bit-rate links. For one or more of these stated reasons, many web applications exchange state management information that should be secured over insecure connections. Therefore, application developers need a method of providing an acceptable level of security for selected state management information that does not require the use of HTTPS. In our previous draft, we proposed the use of "Secure Cookies". This was met with mixed reactions. Some supported the idea of Salgueiro, et al. Expires August 20, 2012 [Page 3] Internet-Draft Secure State Management February 2012 introducing a cookie that could be secured, but some rightfully argued that cookies themselves could be encrypted at the server and so there was no need to secure the cookie. Rather, we need to focus only on securing the session. Our previous draft still enabled a Man-In-The-Middle attack when using HTTP, even when security credentials were exchanged over a secure connection. In this draft, we allow the client and server to establish one or more security associations over HTTP or, preferably, HTTPS. For the purpose of this memo, a security association is defined by use of a specific Message Authentication Code (MAC) function along with a shared secret. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 3. Capability Advertisement In every request from the user agent to the server, the user agent MUST advertise its support for the Secure State Management procedures defined in this document. This is necessary in order to establish the initial security association, but is also necessary in order to force a client to re-establish a security association that is no longer valid or no longer recognized by the server. The capability advertisement comes in the form of a header that enumerates the Message Authentication Code (MAC) functions supported by the user agent. The syntax of the new header, like other headers introduced in this memo, follows the syntax of other headers in HTTP and is: SSM-Functions = "SSM-Functions" ":" MAC-Function *["," *SP MAC-Function] MAC-Function = "hmac-md5" | "hmac-sha-1" | "hmac-sha-256" | "hmac-sha-512" | 1*token Note that the comparison of MAC functions names MUST be case insensitive. In this document, the MAC functions all utilize the HMAC [11] specification, though clients and servers MAY support other MAC functions. Clients MAY support any number of MAC functions, but MUST support either HMAC with MD5 [10] ("hmac-md5") or HMAC with SHA-1 [9] ("hmac-sha-1"). Servers MUST support both hmac-md5 and hmac-sha-1 and SHOULD support a wide variety of popular MAC functions. Salgueiro, et al. Expires August 20, 2012 [Page 4] Internet-Draft Secure State Management February 2012 Using the above syntax, the following is an example header transmitted by a user agent: SSM-Functions: hmac-md5, hmac-sha-1 Note that the server always selects the MAC function to employ from among those offered by the client. 4. Security Associations In order to provide a means of exchanging information securely in a session, the client and server must establish one or more security association(s). The association defines the MAC function and shared secret to be used when transmitting information between the client and server. The security association is assigned a handle by the server and is used in subsequent requests from the client. The format of that association handle is discussed in Sections 5 and 6. In order to allow for multiple concurrent requests, a client MAY establish multiple security associations with the server. For example, each tab on a web browser MAY establish its own client/server security association. Additionally, a client assigns a session handle for each concurrent session that exists within the scope of the security association. A client MUST NOT issue concurrent requests that utilize the same security association handle and session handle, as the server will not be able to differentiate between legitimate requests and requests that are, in fact, replay attacks. A client MAY issue concurrent requests that utilize the same security association handle and different session handles. Once an association has been established, it MAY be used subsequently over either HTTP or HTTPS when the client issues requests to the server. 4.1. Establishing a Security Association To issue a request that allows for the possibility of establishing a new security association, the user agent sends a message to the server with a SSM-Functions header, such as the following: GET / HTTP/1.1 SSM-Functions: hmac-md5, hmac-sha-1 In the following two sections, we discuss how a security association is established using HTTPS or HTTP (with Diffie-Hellman). Salgueiro, et al. Expires August 20, 2012 [Page 5] Internet-Draft Secure State Management February 2012 4.2. Establishing a Security Association over HTTPS The server SHOULD use HTTPS as the means of establishing the security association. By using HTTPS, the encryption key is transmitted as plaintext over the encrypted HTTPS connection from the server to the client. Once the security association is created via HTTPS, the client may be directed to use HTTP for subsequent requests. SSM-Parameters header may then be used to transmit requests over HTTP and be assured that the important parts of the request or response will not be manipulated. When using HTTPS and establishing a new security association, the server MUST reply to requests that contain the SSM-Functions header and that do not demonstrate having a valid security association with a 401 Unauthorized as shown below: HTTP/1.1 401 Unauthorized WWW-Authenticate: SSM assoc=12345, func=hmac-sha-1, secret=yyyy In the above, there are several parameters that are introduced that need discussion. They are: assoc This is an association handle assigned by the web server. This handle is comprised of ASCII characters constrained to upper or lowercase letters and digits (ALPHA and/or DIGIT as defined in 2.2 of [3]). The length of this handle MUST NOT exceed 64 octets. func This is the MAC function selected by the server. The server MUST specify exactly one MAC function. secret This parameter contains the Base64-encoded shared secret in network byte order that will be used when computing the MAC transmitted from or to the server. The number of octets that comprise the secret MUST be equal to or greater than the number of octets produced by the MAC function or, if applicable, the underlying hash function, whichever is greater. However, the number of octets that comprise the secret should not be more than two times the number of octets produced by the selected function. (For example, HMAC-SHA-1 produces a 20-octet MAC. Therefore, the shared secret should Salgueiro, et al. Expires August 20, 2012 [Page 6] Internet-Draft Secure State Management February 2012 be between 20 and 40 octets, inclusive.) Note that the secret must be Base64-decoded prior to consumption by the MAC function. The reason for replying with a 401 rather than returning a 200 response to the request along with a security key is that the client may wish to transmit state management information, but does not have a valid security association that it can utilize. The 401 response allows the server to reject the request and establish a security association that may then be used subsequently in requests from the client. Once the client has received this information, it MAY re-issue the request as in the following example: GET / HTTP/1.1 SSM-Functions: hmac-md5, hmac-sha-1 SSM-Parameters: assoc=12345; session=1; nonce=1; components=Request-Line; mac=2aae6c35c94fcfb415dbe95f408b9ce91ee846ed As shown in this example, the User Agent continues to advertise the supported MAC functions. This is necessary in case the association expires between requests, prompting the server to return a 401 Unauthorized to facilitate the establishment of a new association. Note that the length of time that a server wishes to allow an association to remain valid is outside the scope of this memo. In cases where the client and server are communicating using HTTP and the server wishes to force the client to switch transports to HTTPS to transmit a shared secret, the server rejects the HTTP request as shown below: HTTP/1.1 401 Unauthorized WWW-Authenticate: SSM transport=https, port=443 In the above, there is a single case-insensitive parameter called "transport" and an optional "port" parameter that defaults to port 443. The only value presently defined for transport is "https". When the client receives this response, it re-issues the request using HTTPS. This will result in a subsequent 401 similar to the first example in this section wherein the server provides the shared secret to the client. Once the client has the shared secret in hand, it then re-issues the request using HTTP (not HTTPS). Salgueiro, et al. Expires August 20, 2012 [Page 7] Internet-Draft Secure State Management February 2012 4.3. Establishing a Security Association using Diffie-Hellman HTTP servers MAY use a Diffie-Hellman (DH) key exchange [7] to establish a security association that will be used to encrypt sensitive state management information. It is a well-known fact that use of Diffie-Hellman is subject to a Man-in-the-Middle attack. While this security vulnerability exists, it is nonetheless better than the situation we have today where anyone can easily grab state management information and hijack a session. Further, a Man-in-the-Middle attack requires an active attacker, whereas session stealing is a much easier passive attack. In situations where transmitted information is sensitive or the risk of a Man-in-the-Middle attack is significant, HTTPS SHOULD be used to establish security associations. When using HTTP to establish a new security association, the server MUST reply to requests that do not contain a security association with a 401 Unauthorized as shown below: HTTP/1.1 401 Unauthorized WWW-Authenticate: SSM assoc=12345, g=2, p=yyyy, A=xxxx, func=hmac-sha-1 In the above, there are several parameters that facilitate the DH key exchange and establishment of an association. They are: assoc This is an association handle assigned by the web server. This handle is comprised of ASCII characters constrained to upper or lowercase letters and digits (ALPHA and/or DIGIT as defined in 2.2 of [3]). The length of this handle MUST NOT exceed 64 octets. g The value "g" is a primitive root mod "p" as defined by the DH key exchange algorithm. This parameter is OPTIONAL and, when absent, the value 0x02 MUST be assumed. p This is a large prime number that MUST be used by the client and server as a part of the DH key exchange algorithm. This parameters is OPTIONAL and, if absent, the value used MUST be 0xDCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866 E61EF75A2E27898B057F9891C2E27A639C3F29B60814581CD3B2CA3986D268 Salgueiro, et al. Expires August 20, 2012 [Page 8] Internet-Draft Secure State Management February 2012 3705577D45C2E7E52DC81C7A171876E5CEA74B1448BFDFAF18828EFD2519F1 4E45E3826634AF1949E5B535CC829A483B8A76223E5D490A257F05BDFF16F2 FB22C583AB. A This is the result computed by the server A=g^a mod p, where "a" is a secret large integer not transmitted over the network. func This is the MAC function selected by the server. The server MUST specify exactly one MAC function. Once the client has received this information, it MUST complete the DH key exchange and association establishment by re-issuing the request as in the following example: GET / HTTP/1.1 SSM-Functions: hmac-md5, hmac-sha-1 SSM-Parameters: assoc=12345; nonce=1; components=Request-Line; B=zzzz; mac=2aae6c35c94fcfb415dbe95f408b9ce91ee846ed As shown in this example, the User Agent continues to advertise the supported MAC functions. This is necessary in case the association expires or otherwise becomes invalid between requests, prompting the server to return a 401 Unauthorized to facilitate the establishment of a new association. Note that the length of time that a server wishes to allow an association to remain valid is outside the scope of this memo. Included in the above request is the header SSM-Parameters, which completes the association. It includes several parameters that are included in all requests from the client when exchanging secure state management information. We will cover the majority of the parameters in Section 5, but we will discuss the B parameter here since it applies only when initially establishing a security association using Diffie-Hellman: B This is the result computed by the client B=g^b mod p, where "b" is a secret large integer not transmitted over the network. Subsequent requests from the client to the server need not include the "B" parameter as a part of the SSM-Parameters header, since the Salgueiro, et al. Expires August 20, 2012 [Page 9] Internet-Draft Secure State Management February 2012 association would have been fully formed and SHOULD be ignore by the server when received. Per the Diffie-Hellman algorithm, a shared secret is derived from the values created locally and received over the network from the peer. The shared secret, K, is an integer that MUST be consumed by both the client and server in the same way. Therefore, the value K MUST be converted into a string of octets in network byte order. The shared secret is the n least significant bits, where n is the number of bits equal to two times the number of bits generated by the selected MAC function or, if applicable, the underlying hash function, whichever is greater. If the integer is too small to yield enough bits, then the most significant bits of the shared secret MUST be zero-filled until the length is n bits long. Integers defined in this section that are transmitted in messages (i.e., A, B, g, and p) MUST be represented in network byte order, zero-filling the most significant bits in order to fit the integer into an integral number of octets, then Base64-encoded. Note that all integers are positive numbers and care should be taken to ensure that the most significant bit is not misinterpreted to be a sign bit. 5. Transmitting Information from the User Agent When issuing requests to the server and having what it believes to be a valid association handle, the user agent MUST include the SSM- Functions and SSM-Parameters headers in the request. The following example shows such a request: GET / HTTP/1.1 SSM-Functions: hmac-md5, hmac-sha-1 SSM-Parameters: assoc=12345; session=1; nonce=1; components=Request-Line; mac=2aae6c35c94fcfb415dbe95f408b9ce91ee846ed There are several parameters included in the SSM-Parameters header as described below: assoc This is an association handle assigned by the web server and MUST be provided exactly as it was received. The client MUST NOT assume this handle is encoded in any particular way. session Salgueiro, et al. Expires August 20, 2012 [Page 10] Internet-Draft Secure State Management February 2012 This is an optional session handle created by the user agent to enable it to issue concurrent requests using the same security association. This handle is comprised of ASCII characters constrained to upper or lowercase letters and digits (ALPHA and/or DIGIT as defined in 2.2 of [3]). The length of this handle MUST NOT exceed 64 octets. If this handle is absent, the server MUST assume the session handle has the value NULL (i.e., zero-length string). Note that, while a client can generate any number of session handles, the web server is not required to track more than 128 handles per security association. {Editor's note: in order to allow browser windows and JavaScript code to issue requests using the same security association, perhaps a JavaScript function should be provided by the browser to assign a unique session identifier?} nonce The nonce is a monotonically increasing integer in the range from 0 to 2^64 - 1. To enable concurrent requests, each session identified by the session parameter has its own nonce space. It is presented and consumed by the MAC function in ASCII text form. Once this integer reaches 2^64, a new association MUST be created. The user agent selects the initial value for the nonce, which is RECOMMENDED to be a random value in the range of 0 to 2^32 -1. components This optional parameter contains a comma-separated list of message components that are included in the message over which a MAC is computed. Those components MAY be any one of these components defined in [3]: Request-Line Status-Line message-header message-body If used, the message-body MUST be consumed by the MAC function without modification. All other components MUST be consumed by the MAC function as-is (including all whitespace and the colon that separates the header from its value), except that any CR or LF characters MUST NOT be consumed. Each of the components is consumed by the MAC function in the order in which they are presented in the components parameter. Headers used to generate the MAC MAY appear more than once in the message. In such a case, all headers with the same name Salgueiro, et al. Expires August 20, 2012 [Page 11] Internet-Draft Secure State Management February 2012 must be consumed in the order transmitted on the wire. It is ill-advised to include headers that are intended to be modified my intermediaries, such as the Via header, as doing so will likely result in errors computing the MAC. mac The mac parameter is a case-insensitive hex representation of the Message Authentication Code generated by the MAC function in use with this security association, presented in network byte order. The mac is computed as follows: mac = message_authentication_function(secret,message); where message = (Request-Line || Status-Line || message-header || message-body || assoc || session || nonce); The value of secret is the octets obtained from decoding the Base64-encoded secret parameter in the WWW-Authenticate header (when using HTTPS) or the n least significant bits of K when using Diffie-Hellman as explained in Section 4.3. It is permissible to indicate in the components that a non- existent header or a zero-length message body is used as a part of the "message". In that case, there is nothing to concatenate and there is no impact on the "message" over which the MAC is generated, but does add to the integrity of the request or response. For example, indicating that the message-body is a part of the "message" when a message-body does not exist prevents an intermediary from altering or fabricating the message-body. The server is able to associate the client using the association handle. It is able to validate the request by computing the MAC following the same recipe and comparing the computed MAC value with that received from the client. If the server is unable to verify the MAC, the server MUST return a 401 prompting the client to attempt to create a new association. However, the server MUST NOT invalidate the association handle, since the reason the MAC may have failed to compare properly is Salgueiro, et al. Expires August 20, 2012 [Page 12] Internet-Draft Secure State Management February 2012 because a rogue user agent is attempting to use a handle not assigned to it. If the server receives a request from a client using a nonce value that is less than a nonce value already presented by a trusted user agent, then the server MUST return a 401 error. The server MUST NOT invalidate the association, since a rogue user agent may attempt to re-use a previously used nonce value. 6. Transmitting Information from the Server When a client send a request message to the server as described in Section 5, the server MUST include in the response an SSM-Parameters header as shown in this example: HTTP/1.1 200 OK SSM-Parameters: assoc=12345; session=1; nonce=1; components=Status-Line,Set-Cookie,message-body; mac=3931ff3e9a70d77c6b677b95d9ab7c6aed80d610 The parameters are identical to those defined in Section 5. One important point to note is that the nonce value in the response MUST match the nonce value used in the request. If the client receives a response from the server containing a MAC that it cannot validate, then it must treat the response as invalid. There are only three possible reasons why the MAC does not validate, which include a software logic error, modification of the message as it passed through the network, or data corruption (either on the wire or at the remote server). Assuming the latter, the client MAY re-issue the request, but repeated failure to validate the MAC would suggest messages are being altered. 7. Example Usage to Log into a Social Network Service In this section, we will discuss a typical exchange where a user visits a social network service and logs in. The initial request from the client is a typical request to get the main page of the site. At the outset, there are no security associations nor a need for one. A user agent might transmit the following request: GET / HTTP/1.1 Host: social.example.com SSM-Functions: hmac-md5, hmac-sha-1 In response, the server will return a web page that introduces the social site: Salgueiro, et al. Expires August 20, 2012 [Page 13] Internet-Draft Secure State Management February 2012 HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Included in the response would be the message body containing HTML with various link, including a link to a "login" page. Note that, up to this point, no security association has been established with the server. The user then clicks on the button to log into the service. This link directs the user agent to a login page served over an HTTPS connection. The initial user agent request might look like this: GET /login/ HTTP/1.1 Host: social.example.com SSM-Functions: hmac-md5, hmac-sha-1 At this point, the server returns a response to form the security association: HTTP/1.1 401 Unauthorized WWW-Authenticate: SSM assoc=12345, func=hmac-sha-1, secret=Y3VwaWQ= The user agent then re-issues the request to the server, but this time including the information to demonstrate that the security association has been formed: GET /login/ HTTP/1.1 Host: social.example.com SSM-Functions: hmac-md5, hmac-sha-1 SSM-Parameters: assoc=12345; nonce=1; components=Request-Line; mac=f1784693e4bdefa9b5a1a0348fdc0791c307ed9a Note that since a "session" parameter was not provided, the server assumes the value of "session" is NULL. The server can then validate the MAC to ensure that the client has formed the association. The server will then respond to the request with a new HTML page that prompts the user for a login and password, like this: HTTP/1.1 200 OK SSM-Parameters: assoc=12345; nonce=1; components=Status-Line; mac=2b5cb730dac7e93e3c991918c503c8e87bd7cc82 Content-Type: text/html; charset=UTF-8 The user enters his username and password and click a button on the browser that results in a POST to the web server, like this: Salgueiro, et al. Expires August 20, 2012 [Page 14] Internet-Draft Secure State Management February 2012 POST /login/process/ HTTP/1.1 Host: social.example.com SSM-Functions: hmac-md5, hmac-sha-1 SSM-Parameters: assoc=12345; nonce=2; components=Request-Line,message-body; mac=d632e1b7bc895fc2ce7752bade188b85f5d1c93a Content-Type: application/x-www-form-urlencoded Content-Length: 32 user=someuserid+password=abcd123 Upon receiving this request and successfully validating the MAC and authenticating the user, the web server might then redirect the user agent to an HTTP-accessible page (versus HTTPS) where the user can then interact with the social network service. This redirection might look like this: HTTP/1.1 302 Found Location: http://social.example.com/home/ SSM-Parameters: assoc=12345; nonce=2; components=Status-Line; mac=27283a874b10b9d86b50d3fa7426dd275afaeb02 Content-Length: 0 Note that the 302, while not a final response to the original HTTP request, is considered as such for the purposes of this memo. The next request to the same host, security association, and session MUST use a different nonce in order to avoid a replay attack. Since the host did not change, the user agent may assume that the security association is still valid. It then issues the following request: GET /home/ HTTP/1.1 Host: social.example.com SSM-Functions: hmac-md5, hmac-sha-1 SSM-Parameters: assoc=12345; nonce=3; components=Request-Line; mac=4e51022cb7c25cc1706056d85f34a095e4a6e4e5 Knowing that user "someuserid" logged in and was associated on the server with the association handle "12345" and validating the MAC, the server may then serve the content that it should provide to that user. It does so with a normal 200 response that includes the HTML or other content. While the user is interacting with the server, additional tabs or background threads may be launched that perform parallel requests to the server. Each of these separate windows or threads must use a different and unique "session" attribute. The following request, Salgueiro, et al. Expires August 20, 2012 [Page 15] Internet-Draft Secure State Management February 2012 for example, might be issued by a background thread that polls a user's message inbox: GET /inbox/ HTTP/1.1 Host: social.example.com SSM-Functions: hmac-md5, hmac-sha-1 SSM-Parameters: assoc=12345; session=ajax-thread-6; nonce=346353; components=Request-Line; mac=fbeb80b87dd8f03c418d44e4129006dca6a42dd7 8. Security Considerations Some procedures defined in this memo rely on the Diffie-Hellman key exchange algorithm, which are subject to a Man-in-the-Middle attack. Users should be aware of this fact and utilize HTTPS to establish a security association as per Section 4.2 whenever one needs to guard against such attacks. Note that traditionally, HTTP cookies are used to associate a user with a user agent. The procedures defined in this memo allow the server to identify the user via an association handle. If HTTP cookies are used in conjunction with the Secure State Management procedure defined herein, then the server should verify that the cookie(s) used to identify a user map to the same user identified by the association handle. The procedures defined in this memo are not a replacement for HTTPS and merely serve to strengthen the use of HTTP over insecure connections that wish to provide for exchange of secure state management information. 9. IANA Considerations TBD. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Salgueiro, et al. Expires August 20, 2012 [Page 16] Internet-Draft Secure State Management February 2012 [4] Barth, A., "HTTP State Management Mechanism", draft-ietf- httpstate-cookie-22, February 2011. [5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [6] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011. [7] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [9] Eastlake, D., Jones, P., "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. [10] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [11] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. 10.2. Informative References None. 11. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Gonzalo Salgueiro Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA Phone: +1 919 392 3266 Email: gsalguei@cisco.com Salgueiro, et al. Expires August 20, 2012 [Page 17] Internet-Draft Secure State Management February 2012 Paul E. Jones Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 Phone: +1 919 476 2048 Email: paulej@packetizer.com Salgueiro, et al. Expires August 20, 2012 [Page 18]