Minutes 1 Nov 94

On 1 Nov 1994, a meeting was held at MIT/LCS on security extensions for HTTP, in the context of the W3 Consortium. The meeting was formed to address an urgent need for members and prospective members, even though the first general consortium meeting had not yet been called, some companies still being in the process of formalizing their membership.

(I was half way through transcribing these when Win's notes arrived so I didn't complete mine where his are more complete - Tim)

Present

Marc Andreessen: Mosaic Communications Corp, marca@mcom.com
Alan Schiffman: EIT, ams@eit.com
Jeff Hostetler: Spyglass Inc, jeff@spyglass.com
Alan Cain: NCSA acain@ncsa.uiuc.edu
John Klensin: klensin@reston.mci.net
Phill Hallam-Baker: CERN, hallam@axcern.cern.ch
Win Treese: OpenMarket, treese@openmarket.com
Danny Mayer: Digital Equipment
Tim Berners-Lee: MIT, chair, timbl@w3.org

Apologies received from

Ron Rivest MIT/LCS could not come due to illness
Vint Cerf: sent three points for consideration: Back compatability, Exportability, and Modularity of architecture.

The discussion started with a brainstorming on requirements, resulting in the following list.

Use of security to encapsulate any TCP/IP session toallow rapid retrofit to other protocols, e.g. NNTP and X.
Use in which control is passed to a non-TCP protocol such as RTP for real time applicatins
Ability to encrypt objects at any level in a nested structure
Ability to interwork between current HTTP clients and servers in some way (-Vint).
Ability to include security information from external sources such as previously established security associations, or information within reference.
The ability for an application to determine on an object-by-object basis the level of security required, implying QOS control if the software architecture is layered.
The minimizing of buffer sizes, to allow pipelined code design and minimum response time. This precludes some tradition methods used in store-and forward systems.
The ability to exchange security modules, so that different sites can use different levels of security according to technical, application and political constraints. (-Vint).
The ability to export code which allows politically correct security levels, and the existence of some way of operating securely across national boundaries. (-Vint).
Simplicity
Defined levels of conforance in the spec (levels, flags or some simple notation).

Random points made iduring this process included:

Currently, HTTP rule is that unknown features in protocol may be ignored. security requires mandatory features which should not be ignored if not understood. HTTP needs a generic way of specifying mandatory parts of a message for future extension.
An ex-ARPA working group is grawing up a resecurity model for the internet with reference to the OSI reference model, a 300 page document. The Introduction was just released as an Internet Draft. The IETF security area is involved.

Presentations

Various people explained the work they had been doing, and three documents were distributed.

SSL

Marc Andreessen presented the SSL, "Secure Sockets Layer" protocol, distributing "The SSL protocol" by Kipp Hickman/MCom dated Oct 31, 1994.

SSL uses a binary encoding of security parameters. A variable number of round trips are used depending on the security required and whether keys are known in advance. After the dialogue, the TCP socket is turned over to whatever protocol isto use it. The API for future use of the socket is equivalent to the socket interface, to make software conversion simple.

S-HTTP

Alan Schiffmann presented the "Secure HTTP" proposal and sistributed "The secure hypertext transfer protocol", Rescvoria and Schiffman, June 1994.

S-HTTP is based on PEM with more flexibility but the same basic RFC822 header style. S-HTTP assumed a binary channel. It allows negotiation of many features, both for security level and security mechanisms. The S-HTTP message envelops any otehr message which inthe HTTP context would be an HTTP message (request or reply).

TR-105

Jeff Hostetler presnted his TR-105 proposal for a highest level negotiation of security and payment protocols. He distributed "An architecture for Security in LibWWW for WWW clients (TR105)". This was designed to fitabove everything else, and have the greatest level of flexibility.

Shen

Phill Hallam-Baker presented the differences between Shen and S-HTTP, which is most closely resembles. He discussed the problems and solutions when proxy gateways cache encrypted documents.

Model>

The model developped for security applied to web transfers separated a security dialogue from the "Payload" transfer.

The initial dialogue (which may consist in simple cases only of headers on request and reply data) negotiates the level of security to be used and the methods to be used. This phase may make use of already established secuity information, and may leave behind more security information in a cache for later use. Information may come from the URL, from URCs, as well as from parties accessed over the net during this phase.

The payload was used to describe the actual data of the secure operation, which may vary from being a data unit which is relatively smnall, to the entire length of a session running over what is left of a TCP/IP connection.

Proposal

It was proposed that the S-HTTP protocol be extended if necessary so that its dialogue phase could be used to set up an SSL-style secure connection. This would create a protocol which would fulfil the needs of both SHTTP and SSL. The Shen additions which address proper operation with proxy gateways would be included.

It was decided that EIT and MCom would work togther to produce a combined protocol in this style, with MCom focussing on the payload transfer and EIT on the initial dialogue. MCom's Kipp ___ and EIT's Alan Schiffman would meet to achieve this off line.

A future meeting would be held during the IETF if not agreed in email to hold one before that.

TimBL