W3C home > Mailing lists > Public > ietf-tls@w3.org > April to June 1996

Missing requirements

From: Charles Watt <watt@sware.com>
Date: Mon, 20 May 1996 11:46:06 -0400 (EDT)
Message-Id: <9605201546.AA01595@mordred.sware.com>
To: ietf-tls@w3.org
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822

Although I've reread the archives, I appear to have missed this group's
discussion on the requirements for a standard transport layer security 
protocol.  The group's focus seems to be "let's slam something together 
ASAP so all of our browsers will interoperate, and maybe what we wind up 
with will also be useful to other applications".  Although I too would 
like to see security deployed ASAP, I find this approach short sighted.  
In order to truly support electronic commerce applications, we shall 
need secure systems, not just secure applications.  

As an admittedly biased example, SecureWare's Hannah product 
(see http://www.secureware.com/papers for a white paper and protocol
specifications) creates a secure system by providing transport 
layer security for ALL network communications in a manner that is 
transparent to the applications -- i.e., existing applications are 
secured without modification.  It then controls access to transport 
layer networking (who can access which applications, what security 
services must be enforced, which algorithms and key sizes must be 
used, etc...) through ties to the system's underlying security policy.  
Although a security-aware user or application can request specific 
security services and algorithms, such requests cannot override 
security policy.

In order to provide such pervasive security, Hannah implements
transport security services within the protocol stack.  This can best 
be achieved when there is clean separation between the actual transport
layer security protocol and its supporting key management and 
authentication -- the approach taken by SDNS's SP4, OSI's TLSP, and 
other previous attempts to "standardize" transport layer security.

I believe that a simple set of requirements can easily reconcile these
different approaches to transport security such that they can be 

- - Specification of two independent protocols:

	1) A transport layer security protocol that provides for security-
	   enhancement of network communications above the transport layer
	   using a set of cryptographic keys supplied by some outside
	   mechanism.  This should be designed such that it is independent
	   of (2) allowing for the potential replacement of (2) at some
	   future date.

	2) A key management and authentication protocol to support (1).
	   This protocol need not be generic for supporting other IETF
	   efforts such as IPSEC.  It is hoped that a unified IETF key 
	   management protocol will eventually emerge to supercede this 

- - Although initial default algorithms should be specified, the design of the 
  protocols should be independent of any specific cryptographic algorithms 
  to permit potential future upgrade.

- - The design of the two protocols should permit two possible modes of 

	1) intermixed over a single communications channel (in-band key 
	   management) similar to the current operation of SSL and PCT.

	2) over independent communications channels (out-of-band key
	   management) as suggested by existing transport security

Hannah's protocols (public domain, available at previously mentioned URL)
meet these requirements today.  Both SSL and PCT can be easily modified 
to meet them as well.

Charles Watt
Chief Scientist
SecureWare, Inc.

Received on Monday, 20 May 1996 11:46:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:58 UTC