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]