Network Working Group Gonzalo Salgueiro Internet Draft Cisco Systems Intended status: Standards Track Paul E. Jones Expires: August 18, 2010 Cisco Systems February 18, 2010 Securing HTTP State Management Information draft-salgueiro-secure-state-management-01.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 18, 2010. Copyright Notice Copyright (c) 2010 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 18, 2010 [Page 1] Internet-Draft Secure Session Management February 2010 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 providing a reasonable level of security when exchanging 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. Use of Diffie-Hellman to Create an Association and Key.........4 4. Use of Symmetric Key Encryption Algorithms.....................4 5. Establishing an Association....................................5 6. Encoding Large Integers........................................7 7. Transmitting Secure Information from the Server................7 8. Transmitting Secure Information from the User Agent............8 9. Security Considerations........................................9 10. IANA Considerations...........................................9 11. References...................................................10 11.1. Normative References....................................10 11.2. Informative References..................................10 12. Acknowledgments..............................................10 1. Introduction In spite of the fact that 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 memo provides a simple method for providing a reasonable level of security when exchanging state Salgueiro, et al. Expires August 18, 2010 [Page 2] Internet-Draft Secure Session Management February 2010 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.1 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. Salgueiro, et al. Expires August 18, 2010 [Page 3] Internet-Draft Secure Session Management February 2010 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. Use of Diffie-Hellman to Create an Association and Key To secure state management information, HTTP User Agents (clients) and servers use a Diffie-Hellman (DH) key exchange [7] to establish an encryption key that will be used to encrypt sensitive state management information. In establishing this encryption key, there is an explicit association established between the client and the server referenced by an identifier assigned by the server. In order to allow for multiple concurrent requests and to thwart the possibility of a replay attack, a client MAY establish multiple associations with a web server. For example, each tab on a web browser MAY establish its own client/server association. A client MUST NOT issue concurrent requests that utilize the same association identifier. It is a well-known fact that use of Diffie-Hellman is subject to a Man-in-the-Middle (MiM) attack. While this security vulnerability exists, it is better than the situation we have today where anyone can easily grab state management information and hijack a session. In situations where transmitted information is sensitive or the risk of a MiM attack is significant, HTTPS SHOULD be used rather than the procedures described in this memo. 4. Use of Symmetric Key Encryption Algorithms Once an encryption key is established for an association, sensitive state management information is encrypted using a symmetric key encryption algorithm. The particular encryption algorithm, strength, and mode of operation are negotiated between the client and server. Specifically, the client MUST advertise supported encryption methods and the server will select which method to use for all encrypted information for a given association. The supported encryption methods MUST be advertised by the client in every request. They will appear in an HTTP header of the form DH-Crypto: alg1,alg2,alg3 Salgueiro, et al. Expires August 18, 2010 [Page 4] Internet-Draft Secure Session Management February 2010 In this example, "alg1", "alg2", and "alg3" would represent three different encryption methods that specify the algorithms, strengths (i.e., key sizes), and/or modes. The syntax for the DH-Crypto header follows the standard syntax for all HTTP headers as defined in Section 4.2 of RFC 2616 [3] with a comma-separated list of tokens that MAY include whitespace between tokens. This memo specifies three standard encryption methods: 3des-3x56-cbc Triple DES using three independent 56-bit encryption keys and cipher-block chaining mode. aes-128-cbc Advanced Encryption Standard using a 128-bit encryption key and cipher-block chaining mode. aes-256-cbc Advanced Encryption Standard using a 256-bit encryption key and cipher-block chaining mode. All User Agents and servers MUST support aes-128-cbc and MAY support any number of additional algorithms and modes. Non-standard encryption methods MUST begin with "x-". Any additional encryption standard methods MUST be published in an RFC and registered with IANA. 5. Establishing an Association To issue a request that allows for the possibility of establishing a new association, the User Agent sends a message to the server with a DH-Crypto header, such as the following: GET / HTTP/1.1 DH-Crypto: aes-128-cbc, aes-256-cbc In some instances, a request MAY be for information that does not require receiving state management information (e.g., company logos, JavaScript code, or other public content). In those instances, the web server MAY reply as it normally would without any encrypted information included and without requiring authentication. Salgueiro, et al. Expires August 18, 2010 [Page 5] Internet-Draft Secure Session Management February 2010 In cases where the request or response requires the use of encrypted state management information, the web server MUST reply with a 401 Unauthorized as shown below: HTTP/1.1 401 Unauthorized WWW-Authenticate: DH assoc=12345, g=2, p=yyyy, A=xxxx, crypto=aes-256-cbc 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 those defined by the Base64 data encoding method (RFC 4648 [8]). 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 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. crypto This is the encryption algorithm and mode of operation selected by the server. 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: Salgueiro, et al. Expires August 18, 2010 [Page 6] Internet-Draft Secure Session Management February 2010 GET / HTTP/1.1 DH-Crypto: aes-128-cbc, aes-256-cbc DH-Assoc: assoc=12345, B=zzzz As shown in this example, the User Agent continues to advertise the supported cryptographic algorithms and modes. 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. Also included in the above request is the header DH-Assoc, which completes the association. It includes two parameters: 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. 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. Note that if the client had previously established communication with the server before and had secure state management information to transmit, it MUST include that information in this request. 6. Encoding Large Integers Integers defined in this memo 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. 7. Transmitting Secure Information from the Server If the server wishes to provide the User Agent with secure state management information, it will do so in a reply once an association is established. Such a reply would look like this: 200 OK DH-Assoc: assoc=12345 Set-DH-Cookie: session=someEncryptedValue; path=/; domain=.example.com Salgueiro, et al. Expires August 18, 2010 [Page 7] Internet-Draft Secure Session Management February 2010 In this example, the server returns the association identifier "12345". It also returns a cookie whose syntax precisely aligns with draft-ietf-httpstate-cookie-03.txt [4]. The difference is that the cookie header is called DH-Cookie and the header for setting the cookie is Set-DH-Cookie. Within the DH-Cookie and Set-DH-Cookie, the cookie-value is encrypted using the algorithm and mode specified for the association. Note that the use of Set-Cookie and Set-DH- Cookie is not mutually exclusive. Likewise, use of Cookie and DH- Cookie is also not mutually exclusive. Set-DH-Cookie and DH-Cookie are only used to transmit encrypted state management information according to this memo. State management information MUST be encrypted and coded as follows: encrypted_value = base64(IV || alg(value)) That is, the plaintext MUST be encrypted using the selected algorithm ("alg"). Since cipher-block chaining mode is specified for use in this memo, an initialization vector (IV) MUST be included. The IV is concatenated with the encrypted data and then base64-encoded. 8. Transmitting Secure Information from the User Agent When issuing subsequent requests to the server and having what it believes to be a valid association identifier, the User Agent MUST include encrypted state management information in a DH-Cookie header. The following example shows such a request: GET / HTTP/1.1 DH-Crypto: aes-128-cbc, aes-256-cbc DH-Nonce: 3 DH-Assoc: assoc=12345 DH-Cookie: session=someEncryptedValue This request includes the encrypted state management information. However, providing a block of encrypted state management information that might be the same from one request to the next creates the possibility for a replay attack. For this reason, the client MUST also include a nonce value. The nonce is a monotonically increasing integer in the range from 0 to 2^64 - 1. Once this integer reaches 2^64, a new association MUST be created. The encrypted information transmitted from the User Agent to the server is encoded as follows: encrypted_value = base64(IV || alg(value || nonce)) Salgueiro, et al. Expires August 18, 2010 [Page 8] Internet-Draft Secure Session Management February 2010 The means of encoding the encrypted information is virtually the same as that used by the server. The only difference is that the nonce is concatenated to the end of the plaintext prior to encryption. When concatenating the nonce to the plaintext, the User Agent MUST first convert the integer into an ASCII string that is not padded in any way. The DH-Nonce header MUST contain precisely the same ASCII character string concatenated with the plaintext. A server that receives a request that includes a nonce value that is less than or equal to the same nonce value already received from the client for a given association MUST reject the request with a 401 Unauthorized response code. The server need not invalidate the association, however, since the apparently invalid request MAY be coming from a rogue entity. 9. Security Considerations Since the procedures defined in this memo rely on the Diffie-Hellman key exchange algorithm, the procedures are subject to a Man-in-the- Middle attack. Users should be aware of this fact and utilize TLS whenever information needs to guard against such attacks. Another form of attack that is possible is one where an entity in the network is able to monitor traffic transmitted from the client to the server and initiate requests in an attempt to reach the server faster than the client. If the rogue endpoint is able to reach the server before the legitimate User Agent, then the request MAY be accepted. In the process, the rogue entity MAY modify some information in the request and access resources on the server that it should not have authorization to access. The risk in this form of attack is clearly not what information the rogue entity can retrieve, since all information is transmitted as plaintext, anyway. The risk is that a rogue entity might introduce information, such as a blog posting, that will appear to have been transmitted by the unsuspecting valid user. If such concerns exist, TLS should be employed. The procedures defined in this memo are not a replacement for TLS and merely serve to strengthen the use of HTTP over insecure connections that wish to securely exchange state management information within the security constraints outlined herein. 10. IANA Considerations TBD. Salgueiro, et al. Expires August 18, 2010 [Page 9] Internet-Draft Secure Session Management February 2010 11. References 11.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. [4] Barth, A., "HTTP State Management Mechanism", draft-ietf- httpstate-cookie-03, February 2010. [5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [6] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. [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. 11.2. Informative References [9] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000. 12. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Salgueiro, et al. Expires August 18, 2010 [Page 10] Internet-Draft Secure Session Management February 2010 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 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 18, 2010 [Page 11]