Re: TLS document modularity

David P. Kemp wrote:
> 
> > From: Win Treese <treese@OpenMarket.com>
> > Subject: Closing on shared-key authentication
> >
> > At this point, I propose that we adopt the proposed
> > modifications for the TLS draft. As always, I am happy
> > to hear comments either on the list or in direct mail.
> 
> No comments.
> 
> > In addition, if there are other burning issues for substantive
> > changes, please let me know about them now.
> 
> I would like to see the first product of this working group separated
> into two RFC documents, one defining the Record Layer, and the other
> defining the Handshake Protocol.  This follows existing practice of the
> IP Security working group which has separate documents for the security
> transforms (AH and ESP) and for the Internet Key Management Protocol
> (IKMP).  Separating the TLS standard into two components allows a
> useful separation of function, so that issues affecting only one
> component do not hold up progress on the other.  The great shared
> secret debate (although it pales in comparison to the IPsec IKMP
> debate :-) is a case in point.
> 
> The other benefit is that a standard Record Layer format could be
> reused in other applications.  Several come to mind: RADIUS (an
> authentication protocol for Network Access Servers (NASs)) has
> abysmal security between the NAS and the authentication server - the
> ink isn't even dry on RADIUS yet and the WG is already working on
> requirements (including security) for RADIUS-NG.  Cisco just released
> an I-D for TACACS+, a different (and IMO somewhat more mature) protocol
> which addresses the same application space.  A generic TLS record
> format could be used by the NAS market even if their keying requirements
> differ from the Web market.
> 
> Jeff Schiller has also begun a(nother) Telnet security initiative,
> this time driven by a pressing need to enable secure remote
> administration of the Internet infrastructure.  A TLS record component
> could be more easily incorporated into the Telnet authentication/
> encryption framework than could full SSL 3.
> 
> This is, after all, the Transport Layer Security group, not just Web
> Connection Security.  At present, I'm not proposing any changes to the
> SSL 3.0 baseline protocol itself, just proposing that the existing
> protocol be documented in a more modular fashion.  There is some work
> to be done, such as defining the minimum sufficient connection state
> data - server and client random don't belong in connection state, but
> compression, encryption, and MAC methods do, as do byte counts for data
> protected by the current encryption keys and MAC secrets).  But
> cleanly specifying the keying/transform interface now will pay off
> in reduced development effort later.


I do not have a problem with splitting the document to a record layer
protocol and a key management / authentication handshake document
describing the negotiation and other key mgmt issues. There are things
we need to discuss before all multiple authentication methods are
standardized.


On the subject of password authentication I would like to make the
following two remarks. 

First, it is my understanding that the IETF usually puts things in
standards track based on rough consensous and running code (usually at
more than one location). I would like to see this implemented in TLS as
well before we put things on the standards track.

The other issue is that the community has not had a chance to evaluate
the security issues involved with having multiple authentication methods
in a single protocol. I believe that we all need to look at any security
hazard invloved with doing password-based auth using the same shared
secret that generates the encryption keys and MAC secrets. For example,
we should assume that some password is compromised and the effects that
may have on other portions in the sessions that use the same master
secret. I do not believe anyone feels comfortable with that now.


Splitting the TLS protocol document may be a good way to start putting
TLS in the standards track, assuming the record layer is easier to agree
on (from historical experiences).



-- 
Taher Elgamal	    elgamal@netscape.com
Chief Scientist, Netscape Communications
(T) 415 937 2898, (F) 415 428 4054

Received on Monday, 7 October 1996 15:11:31 UTC