SEA: A Security Extension Architecture for HTTP/1.x

Rohit Khare (khare@pest.w3.org)
Tue, 9 Jan 96 05:07:24 -0500

Members-only at: http://www.w3.org/member/WWW/Security/Group/960122_Workshop/SEA

Rohit

-------------------------

<!doctype html public "-//IETF//DTD HTML//EN">
SEA: A Security Extension Architecture for HTTP/1.x

SEA: A Security Extension Architecture for HTTP/1.x

by Rohit Khare, khare@w3.org (January 8, 1996)

Status of This Document

This draft is for the Fifth W3C Security WG Meeting on January 22, 1996. Future revisions will be made available as public W3C Working Drafts. Distribution of this draft is restricted to attendees and W3C Member organizations ONLY.

Table of Contents

1. Abstract

This document sketches an architecture for securing HTTP/1.x messages using protocol extensions. We propose three classes of extensions, Signature, Encryption, and Key-Exchange, as well as requirements for their secure combination.

2. Introduction

W3C is interested in developing flexible, evolvable security for the World Wide Web infrastructure. In particular, this means that solutions should incorporate:

Our proposal for a Security Extension Architecture (SEA) identifies just three classes of cryptographic processes, and we show how those can be combined, safely and securely, to meet common requirements.

2.1 Other Web Security Approaches

The first generation of Web security solutions have approached the problem at different layers:

Secure Sockets Layer provides channel security underneath applications, such as FTP, HTTP, etc. Other facilities achieve the same ends: IPsec and GSSAPI preambles to HTTP. Since they are link-level approaches, they are hard-pressed to provide solutions for message security, i.e. the ability to extract messages from the stream as complete, secured documents.

Secured Content is the approach of transporting externally-secured data over oblivious applications, such as PGP encrypted documents over HTTP. This technology is usually implemented with MIME `viewers', which can be deployed successfully {\cite NCSA}.

Secure HTTP is a parallel mechanism to HTTP. It adds hardwired security features to HTTP and HTML to create an outer, enveloping layer for `regular' HTTP/1.x messages. There are no measures for backward compatibility, since SHTTP is essentially a new application. Also, there are several proposed extensions to HTTP that cannot be represented `within' another protocol, such as chunked-transfer-encoding and multiplexing.

In addition, there have been proposals to add secure facilities for state management and authentication. SEA does not address these concerns (except insofar as signed HTTP requests are a strong form of authentication).

3. SEA Elements

We began by adopting the model behind SHTTP, but attempt to render its facilities into a modular architecture atop PEP, W3C's extension proposal for HTTP. From the debate last October at the Fourth WG Meeting, we classified two responses to PEP-based security design. One was a strawman approach to promote each algorithm and feature into a protocol extension, yielding fine-grained negotiation and combination (e.g. separating signature functions from hash functions). At the other end was semi-monolithic approach of describing `SHTTP' as a single extension with many parameters. SEA is a median proposal that identifies three extension classes.

Signature These extensions provide nonrepudiable authentication.
Encryption These extensions provide cryptographically secure privacy.
Key-Exchange These extensions provide for secure reference to keys.

Note that the semantics of these operations are underspecified. There is no assumption of `what assertion' is being signed; of `what security policy' a document is being encrypted under; or `which certificate infrastructure' is used to identify principals.

What is specified, though, is that these three modules can only be used in the exact order specified. Encryption and Key-Exchange may only be used once per message. Encryption writes its key material out to two headers, Session-Key: and Session-Key-Clear:. Key-Exchange reads this material and protects the key for the intended recipient alone. This kind of commonsense simplification was identified as a `recipe' by attendees at the Fourth W3C Security WG Meeting. In combination, we believe SEA is a reasonable security solution.

3.1 Signature

Signature generally is used to denote nonrepudiable claims of authorship or assent. Other kinds of assertions are often bound into the text, as in "I the undersigned believe that...". Thus, we believe for Web-related purposes, we need only use the weakest abstraction of signature: an operation on the entire body of an HTTP message, not involving any assertions bound into the signature or the signing certificate. This reduces signature to an algorithmic transformation, of which several are in common use today: RSA-MD5, DSS-SHA, etc.

Each of these techniques is a protocol extension which can be applied to a message. This maps neatly onto an implementation and negotiation model for PEP modules. In addition, compared with SHTTP or MOSS signatures:

Backward Compatibility Servers can emit `pre-signed' documents that incompatible clients can continue to display. The message body remains clear, unenveloped, so old clients continue to work, paranoid proxies can still scan message contents.

Unmodified Body The HTTP message body can be compared directly against disk, since there is no intervening encapsulation or canonicalization. This also means that it can sign any data, not just HTML.

Minimal Footprint The actual signature data is in HTTP headers, so clients can simply key off of their presence. No multipart or ASN.1 parser is called for; the signature can be attached by CGI programs and verified by simple client hooks.

Protocol: http://w3.org/SEA/Signature

Protocol: http://w3.org/SEA/Signature/RSA-MD5

In the same manner, one can specify Signature modules for a few other well-known approaches, such as DSS-SHA. In each case, proper attention should be paid to existing standards in the arena for encoding values and algorithms, such as the PKCS-1 packings and PEM/MOSS names.

It is only appropriate to sign cleartext {\cite Anderson}, but multiple parties may sign a document using different techniques, so the recipe allows for multiple application of Signature-class extensions.

3.2 Encryption

Encryption is a process that protects the entity-body, and places the a complete copy of the key in "Session-Key:" and optionally a partial copy in "Session-Key-Clear:". A message cannot be encrypted twice (because of the header collisions). This is an abstraction that provides the necessary decoupling between this phase and the next, Key-Exchange.

The general approach of putting all keying material, in any appropriate packing, in one header and optionally divulging additional amounts in a parallel header, seems reasonable. This mechanism does not allow for key-escrow, though; additional LEAF-style fields (Clipper's Law Enforcement Access Field) can be generated by Encryption and Key-Exchange modules, though.

The initial set of reasonable encryption algorithm can be taken from SHTTP's selection. The inclusion of additional ciphers, such as IDEA, should be carefully weighed before being placed in the "/SEA/" namespace, but can still be readily deployed for experimental purposes.

Protocol: http://w3.org/SEA/Encryption

Protocol: http://w3.org/SEA/Encryption/DES

Triple-DES can be added as an option to this protocol, or by proposing a separate Triple-DES extension. The encoding of other bulk ciphers will be fairly similar. Nevertheless, this kind of exercise is vulnerable to the `sole-instance bug' of designing around what we know rather than what might also solve the problem. We posit, though, that even more exotic ciphers, e.g. with key-vectors &c, will still follow the form of a single chunk of keying material that can be partially exposed. Now, there may be cryptographic risks particular to various ciphers, such as their vulnerability to known, structured plaintext (as is common with HTTP) that constitute challenges to extensibility, but that is solved by the naming authority and recipe.

There is an implicit statement in all Encryption extensions that it is incorrect to use Encryption without a succeeding Key-Exchange phase.

3.3 Key-Exchange

Key-Exchange is the trickiest protocol of the three, since it covers both the cryptographic algorithms for doing so and the cryptographic policy for identifying keys and using them appropriately.

In general K-E protocol extensions replace the "Session-Key" with some protected material — either the "name" of the key (for secret-key systems), the session key under some public-key cryptosystem, or the data for a Diffie-Hellman style exchange. Note that an implementation model might in practice join particular Encryption and Key-Exchange extensions into a single piece of code, e.g. a single-step DES-based secret key system.

Protocol: http://w3.org/SEA/Key-Exchange

Protocol: http://w3.org/SEA/Key-Exchange/Outband

Protocol: http://w3.org/SEA/Key-Exchange/RSA

The implementation model is that these Key-Exchange processes are reversible; that a corresponding extension on the opposite end can regenerate the Session-Key: header, which, in turn, is all that the corresponding Encryption process needs.

3.4 Certification

While the balance of SEA is moot on this point, there is a need to specify a certificate chain within a secure HTTP message. A possible hook to do so, separately from the cryptographic processing, is to define a suite of certification protocols that define the contents of associated headers. For example, both PGP signed-keys and X509 certificates are appropriate name-PK bindings. How/Whether an agent chooses to trust such assertions, and exchange such knowledge is beyond the scope of an SEA spec.

Protocol: http://w3.org/SEA/Certificate

Protocol: http://w3.org/SEA/Certificate/X509

4. Examples

With SEA, we can address many common security requirements: we can sign documents, sign and encrypt, or encrypt for integrity alone. SEA also supports a measure of backward compatibility and implementation flexibility.

In these examples, user U running client C accesses Candidate A's server S. On S, A has prepared some documents about Candidate B's sworn statements.

4.1 Requesting a Signed Document

U asks S for a signed platform statement from A. 

C->S:	GET /Platform.html HTTP/1.1
		Accept-Protocol: {http://w3.org/SEA/Signature {str req}}
S->C:	200 OK
		Protocol: {http://w3.org/SEA/Signature/RSA-MD5
				{params {pk Base64(A's PK)} {name "A@S"}} 
				{headers Signature-37}}
		Signature-37: Base64(the signature of the reply, PKCS-1 packed)
		...

In this exchange, U assumes C implements all the known Signature algorithms, so instead of sending a few specific preferences, U requests the generic "Signature" and hopes S replies with a specific algorithm C knows. If not, U can always try again with more detailed instructions. Note that the response contains unmodified text/html, and no Content-Encoding: information, since the signature is implicitly checked only after all the unwrapping and decoding.

The same mechanism could be used by U to sign the user's requests for information, by wrapping a GET message. Suppose U wanted to access A's records of U's campaign contributions, and U wanted to ensure the response was encrypted to U's taste: 

C->S:	WRAPPED * HTTP/1.1
		Protocol: {http://w3.org/SEA/Signature/RSA-MD5
				{params {pk Base64(U's PK)} {name "U@C"}} 
				{headers Signature-54}}
		Signature-54: Base64(the signature of the request, PKCS-1 packed)
		Content-Type: message/http
		GET /Contributions/U HTTP/1.1
		Accept-Protocol: {http://w3.org/SEA/Signature/RSA-MD5 {str req}}
		Accept-Protocol: {http://w3.org/SEA/Encryption/DES {str req}
					{params {keylen [40-56]}}}
		Accept-Protocol: {http://w3.org/SEA/Key-Exchange/Outband {str req}
					{params {keyname  
"TopSecret" "DonationKey"}}}

4.2 Encrypted Conversation

[The following design discussion is meant to provoke thinking about what kind of key-management controls need to be accommodated in the initial releases of SEA.]

Suppose instead that we have the "typical" encrypted-channel scenario: U has no well-known public key, and wishes to browse a secure site Y. One solution is an initial round-trip where Y sends its certificate and key; then U can then choose a session key and encrypt for Y its chosen keypair. This is akin to the `Assign-Key' functionality of SHTTP. Typically, though, a server may wish to assign a session-key to a client, not the other way around. SEA has no exact analogue for this role-reversal, though one could be created.

In summary, SEA works unmodified if the client has a keypair, whether certified or not. If a client wishes only to use a session key, there is no direct facility to name that session key and reuse it. A solution may be to, within the separate Encryption extensions, define some names like "LastKey", or add a new attribute, keyname, to the generation and use of keys. The latter would be: 

C->Y:	GET / HTTP/1.1
Y->C:	200 OK
		Accept-Protocol: {http://w3.org/SEA/Key-Exchange/RSA
					{params {pk Base64(Y's PK)} {name  
"Y's PK"}}}
C->Y:	WRAPPED * HTTP/1.1
		Protocol: {http://w3.org/SEA/Encryption/DES {str req}
				{params {IV Base64(iv)} {keylen 56} {pad n}  
{mode cfb}
					{keyname "C's New Key"}}}
		Protocol: {http://w3.org/SEA/Key-Exchange/RSA {str req}
				{params {pad n}} {headers DEK-Info-15}}
		DEK-Info-15: Base64(C's New Key encrypted by Y's PK)
		Content-Type: text/html
		Content-Encoding: rsa, des
		
	E	GET /SensitiveData HTTP/1.1

Notes: The line marked `E' in the margin is encrypted. C can elide Y's PK in the RSA protocol line. The keyname attribute has been added to DES; presumably, a response from Y to C could use that keyname in an outband key-exchange.

This hypothetical exchange highlights an additional difference from SHTTP's Assign-Key design: in SEA, only keys used to encrypt can be named. There is no syntax for referring to keys not used in the present message and not already known to both sides. The /Certificate/ facilities only allow advertising of public-keys (although it also possible to envision `Assign-Key' as a type of Key-Name certificate only valid within encrypted messages).

4.3 Detailed Negotiation

While SEA is designed so that many agents can compactly state they have or offer one of the three core SEA protocols, there are many scenarios where agents will have to perform detailed negotiations because one end supports only a subset.

Consider an export-only client F. Rather than stating "Accept-Protocol: {.../Encryption}", F would state specifically "Accept-Protocol: {.../DES {params {keylen 40}}}, {.../RC4 {params {keylen [40-48]}}}" or state just one and mark it "{str req}".

There is a separate, as yet unsolved, syntactic question about client G, which supports precisely two of the three most popular signature protocols: there is no PEP syntax to say G supports X and Y, and that the server is required to respond using one of X or Y. The only reliable solution is for G to try both separately, or choose from the list the server chooses to advertise.

5. SEA Features in HTML

At the October meeting and in several ERB discussions, W3C was asked to investigate proposals for security markup in HTML. In SHTTP, for example, the CRYPTOPTS facility allows authors to label links with a fixed set of security features to be expected when dereferencing a link. Using a proposed HTML facility for labeling resources, we demonstrate how SEA attributes might be encoded in a similar manner.

5.1 Motivation

The logic behind security markup for hypertext is as follows:

  1. A source document should be able to include assertions about a target resource
  2. Assertions can be limited to the set of link types {REL, REV, etc...} and HTTP entity headers {Content-Type, Content-Length, Content-MD5, etc...}
  3. Security properties of a resource can be expressed using PEP/SEA

This would imply that the PEP headers, of the entity or of the transmission, would suffice, if embeddable in HTML. The first question, then, is `Which kind of PEP header? Offers (Accept-Protocol:) or particular instances (Protocol:)?'.

The scenario: Candidate A has a statement on her server attacking an authentic statement of B's. Her staff wants to prepare a page citing the exact passage of B so that user U knows what to expect (say an MD5, a length, and a signature).

Note that A wants to make a binding statements: `U must ask for signatures and they must match what A believes'; if U chooses to disregard A (by not asking B for signed copies, for example), it contradicts A's beliefs, but it is not a protocol violation.

This sets the scene for the following discussion: A can choose to copy B's signature in her document (Protocol:) or direct U to request its own signed copy from B.

5.2 RESOURCE Tag

The Resource tag is a mechanism separate from the <INSERT> proposal. Essentially, wherever you use a link (HREF, SRC, ACTION), you can use a pointer to a "resource description" in the same file (usually stored in the HEAD, where old browsers won't display it). Within the Resource, an author can use the META tag to indicate headers present when accessing the resource, or use predefined shortcuts for many entity headers. 

	<A HREF="http://B.org/B-doc">CandidateA believes  
B-doc may change</A>
	...
	<RESOURCE="http://B.org/B-doc"  
Content-MD5="hex(MD5)">
		<META NAME="Protocol" VALUE="{.../RSA-MD5  
{params {name "B's PK"}
					{pk Base64(B's PK)}} {headers  
Signature-9}">
		<META NAME="Signature-9" VALUE="Base64(B's  
sig of B-doc)">
	</RESOURCE>

The syntax above shows A copying over headers she got when she accessed B-doc. Alternatively, she could specify headers she used to access B-doc: 

	<A HREF="http://B.org/B-doc"> A says, `make B sign  
his promises' </A>
	...
	<RESOURCE="http://B.org/B-doc"  
Content-MD5="hex(MD5)">
		<META NAME="Protocol-Offer"  
VALUE="{.../Signature {str req}}">
	</RESOURCE>

Since RESOURCE can be used to annotate any link, it can be use to solve several problems:

  1. It can be used to prevent a FORM from being posted as cleartext
  2. It can be used to prevent an initial round-trip to a secure server to acquire public keys, negotiable set, etc.
  3. It can be used to make assertions about any protocol extension at any resource

This mechanism is not a solution for all secure markup problems, though. For example, a facility to selectively encrypt only certain fields of a form can only be provided by developing a new ENCTYPE, a multipart to replace text/x-www-form-url-encoded. A new multipart could selectively apply SEA extensions to each part, achieving the desired effect.

Another kind of "secure markup" request is to sign or encrypt HTML documents, etc, in advance. It is worth noting that instead of storing such data within opaque PKCS-7 envelopes, PEP/SEA messages can be stored whole, as message/http; the data remains intact, while a few headers can be precomputed (Signature, Encryption — only Key-Exchange has to be done for each connection).

6. PEP/SEA Security Considerations

SEA provides implementors a lot of rope — it is easy to envision unsafe combinations of modules. There are several additional considerations to building secure solutions with SEA. Recipes are a technique for restricting the order in which protocols are evaluated. Implementation considerations address some PEP-related vulnerabilities of special note. Finally, as SEA evolves, there is the potential for cryptographic vulnerability among combinations, as well.

6.1 Recipes

Apparently first named by Mark Manasse and Martin Abadi at last October's meetings, recipes codify intuition about restricting the eligible order or application for certain extensions. For example, all safe SEA combinations match the following type-expression:

(.../SEA/Signature)* , [.../SEA/Encryption , .../SEA/Key-Exchange]

Note that Certificates are not allowed in the Encoding, so they are only processed at the end, in unspecified order. Note that Encryption and Key-Exchange are optional, but must be used together.

For a particular Content-Encoding: line, verification must follow the "Conforms To:" declarations of each protocol specification. Note that the W3C and the W3C Security ERB, in this example, control the http://w3.org/SEA/ name space and all conformance assertions.

6.2 Implementation Considerations

It is particularly worth noting that the information passed between SEA modules is sensitive information. The information being signed must be tamper-proof, and the channel passing the Session-Key: must be private. This means that some platforms will have to pay special attention to the security of available IPC idioms. It may be appropriate to implement some or all of these SEA protocols within a single program, reducing the possibility of compromise.

Implementations will have to go beyond PEP compliance to verify recipes and provide a user-interface channel for reporting security status. Implementations will also have to be careful about the trust categories of various extensions; after a message has been decrypted, it is likely inappropriate to invoke the MailACopyToEve extension.

PEP also exposes clients to negotiation attacks, where two parties are convinced by a man-in-the-middle to use weaker security than desired. In practical fact, this sort of attack can be forestalled by:

  1. Signing requests and responses.
  2. Indicating security capabilities in some other, trusted medium (PEP-HTML on CD-ROM, separate port numbers).
  3. Servers being careful to never vend document with weaker-than-appropriate security.

6.3 Cryptographic Considerations

It is possible that certain cryptosystems may interact poorly with certain applications, especially one in such broad use as the Web. Particular SEA extensions will likely have to be accompanied by usage restrictions. Some ciphers may be inappropriate for structured, highly regular plaintext like HTTP messages. Some may be inappropriate for sequential (predicted-plaintext) messages, like counters and status messages.

All of this means that naming authorities must exercise care in adding methods to the SEA repertoire. One must consider not only interactions between the cryptosystem and Web applications, but also with existing SEA facilities.

7. Development Path

The SEA proposal is the culmination of several months'SEA: A Security Extension Architecture for HTTP/1.x effort at the W3C into designing an extensible security architecture. Member organizations will have to come forward to help define and realize these ideas now. We believe this is a reasonable path to Web security at the application layer, and want to take the Consortium further along this path. Please direct comments and questions to Rohit Khare, khare@w3.org.

8. References

[Anderson]
R. Anderson and R. Needham. "Robustness principles for public key protocols." ftp://ftp.cl.cam.ac.uk/users/rja14/robustness.ps.Z [in proceedings of Crypto '95], Cambridge University Computer Laboratory, 1995.

[PEP]
R. Khare. "PEP: An Extension Mechanism for HTTP" W3C Working Draft , W3 Consortium, November 1995 (Work In Progress).

[MOSS]
S. Crocker, N. Freed, J. Galvin & S. Murphy "MIME Object Security Services." RFC 1848, October 1995.

[NCSA]
J. D. Weeks, A. Cain, & B. Sanderson. "CCI-Based Web Security: A Design Using PGP" In proceedings of the Fourth International World Wide Web Conference , NCSA, December 1995 (Work In Progress).

[SHTTP]
E. Rescorla, and A. Schiffman, "The Secure Hypertext Transfer Protocol", Internet Draft, July 1995 (Work in Progress).