Subject: [Rserpool] RE: Erik Guttman's comments on Rserpool threats for review and comment

From: "Stillman Maureen (NVO-NIC/Ithaca)" <[email-masked]>
Date: Tue, 4 Sep 2001 09:31:10 -0500

Erik,

Sorry for the delay in my response.   I took an end of the summer
vacation.  Thank you for your insightful comments.  My comments below
are included with your original message preceeded and followed by ***.

Maureen,

I have a few general notes.  I regret I don't have time to directly 
participate in the security design team, but I hope my remarks will 
be of use to that group. 

I believe the most important class of security risks are not addressed 
in this document.  I see RSERPOOL as a session layer protocol. 

Consider how this interacts with existing security protocols. 

   7 APP           <--------------> APP  
                    custom ciphered data 

   6 PESENTATION   <--------------> PRESENTATION 
                    S/MIME, PGP 

   5 SESSION       <--------------> SESSION 
                    ? 

   4 TRANSPORT     <--------------> TRANSPORT 
                    TLS, SASL 

   3 NETWORK       <--------------> NETWORK 
                    IPSec 

   2 LINK          <--------------> LINK 
                    WEP, EAP 

RSERPOOL will eliminate the correspondence between client and server. 
That is, in the middle of a series of exchanged messages, the client 
may actually correspond to a different server instance. 

Implications, per layer: 

7: Cipher state must be shared among PE instances, or else apps 
   will no longer be able to communicate.  As long as state sharing 
   exists, and the state isn't less secure due to its being shared, 
   app layer security is not compromised. 

6: Presentation layer security is not compromised.  Consider the 
   keying material required for processing S/MIME encrypted messages 
   is distributed between a set of PEs. 

4: Transport layer security is compromised by session layer 
   redirection of transport between divergent parties.  Consider 
   SASL based authentication used for IMAP, LDAP, etc.  A TCP 
   connection is initially authenticated through an exchange of 
   messages and constitutes a 'session.'  This would clearly be 
   broken by RSERPOOL.  TLS would also be broken.  I don't believe 
   this state can be shared and connections reestablished.  Doesn't 
   SSL use IP identifiers in the protocol? 

*** No, SSL/TLS do not use IP identifiers in the protocol.  In addition,
there is a new internet draft by Michael Tuexen entitled "TLS over SCTP"

draft-tuexen-tsvwg-tls-over-sctp-00.txt which describes how to use TLS
over SCTP.  Here is the summary in the document.

"This document describes the usage of the Transport Layer Security (TLS)
protocol, as defined in [RFC2246], over the Stream Control Transmission
Protocol (SCTP), as defined in [RFC2960].

TLS is designed to run on top of a byte-stream oriented transport
protocol providing a reliable, in-sequence delivery.  Thus, TLS is
currently mainly being used on top of the Transmission Control Protocol
(TCP), as defined in [RFC793].

Comparing TCP and SCTP, the latter provides additional features and this
document shows how TLS should be used with SCTP to provide some of these
additional features to the TLS user.

This document defines

     -    how to use the multiple streams feature of SCTP.

     -    how to handle the message oriented nature of SCTP.

It should be noted that the TLS user can take advantage of the multi-
homing support of SCTP. The dynamic reconfiguration of IP-addresses as
described in [SCTPEXT] can also be used with the described solution.

The method described in this document does not require any changes of
TLS or SCTP. It is only required that SCTP implementations support the
optional feature of fragmentation of SCTP user messages."

During the security conference call, Michael Tuexen reported on the
status of this internet-draft.  He said that the draft is being made a
working group item by the TSV working group and the goal is to make it
RFC standards track.

We talked about this TLS and SCTP extensively during the security
conference call.  It might be helpful for you to receive the minutes for
the conference calls even if you can't attend them.  Would you like to
receive the minutes? ***

3: IPsec security associations between IP endpoints would clearly be 
   broken by redirection of traffic at the session layer. 

*** Agreed. ***

etc. 

The point is that security mechanisms and properties of higher layers 
can be supported transparently by a session layer which redirects or 
restarts communication (though this may have some state sharing 
assumptions which itself has security implications).  The security 
mechanism and properties of lower layers will be broken by a session 
layer which effectively reroutes communication arbitrarily across them. 
This does not imply that lower layer security is inappropriate or 
ineffective when used in conjunction with RSERPOOL, only that it has 
completely different implications. 

If an application relies on IPSec for security, RSERPOOL will 
break this.  

However, RSERPOOL itself could rely upon IPsec for *its* security. 
The idea being that if the application can be made to rely upon layer 
5 for its security, layer 5 can in turn support that through lower 
layer services. 

Note that no existing application today uses L5 security, since it 
doesn't yet exist in the Internet protocol suite - we are talking about 
new applications.  The only legacy applications which could be supported

with existing security mechanisms and properties using RSERPOOL are
those 
which use 'object-based' security as opposed to 'transport-based' 
security, that is, for example S/MIME, PGP secured messages. 

*** Note that the document we are currently writing focuses on threats.
It does not describe security solutions.  Once we have identified the
threats, the next step is to discuss solutions.  However, your points on
security for legacy versus new applications are important.  We are going
to have to discuss solutions for both. ***

*** I will send another message concerning your comments on the text of
the document. Thank you for your comments.   
***

-- maureen

Mobile: (607)227-2933

_______________________________________________
rserpool mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/rserpool