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
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
 MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG
 A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj
 dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw
 MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl
 Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT
 DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB
 AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf
 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA
 A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK
 aTxjgASxqHhzkx7PkOnL4JrN+Q==
MIC-Info: RSA-MD5,RSA,
 BkrFKtDKMVnLUVZoapN3XfYzFFDupOYQW4tL4iEqptTl3oDCYD1lATrdWNfa6F+R
 OHpgEo/zCQB9RUH/70wod+Y=

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 
interoperable:

- - 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 
	   protocol.

- - 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 
  operation:

	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
	   standards.

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.

-----END PRIVACY-ENHANCED MESSAGE-----
Received on Monday, 20 May 1996 11:46:09 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:34:48 EDT