Re: Security scenarios and basic functions

On Fri, 2006-06-30 at 07:11 -0400, George Gross wrote:
> Hi Magnus,
> 
> I tend to agree that a discussion of RMT protocol suite security is
> overdue. more observations inline below...

Hearty second.  Recall that there have been any number of
next-generation transport protocols out there to succeed TCP.  None have
been successful.  And, IMHO, none will be until they clearly show a
better security mousetrap that what we have.


> > 1. Source authentication, i.e. the capability to determine and verify
> > who is sending the packets
> 
> with two main subcases: group-level authentication (i.e. the packet
> verifies as coming from one of the group members) and group speaker
> authentication (i.e. the packet verifies as originating from an individual
> source).
> 
> >
> > 2. Integrity protection, i.e. the capability to verify that the packets
> > has not been tampered with between the sender and the receiver.
> >
> > 3. Confidentiality, i.e. the possibility to prevent someone not
> > authorized to see what is transported within the protocol, and in some
> > case even seeing what is happening within the protocol itself.
> 
Good analysis.

> 
> > Or is integrity protecton plus object
> > confidentiality a more interesting model?
> 
> I'm not sure I understand what you're alluding to here, could you please
> elaborate? do you mean an application layer security mechanism?
> 
I think the key to unraveling this is 'which layer do you want to apply
the security?'  


Connection integrity (1. above) is clearly a transport layer problem
that should be handled directly within the transport protocol.  


The best place to apply data content [confidentiality, authenticity,
integrity, non-repudiation] is usually at layer 7.  So an appropriate
building block solution might be linkage between a transport layer
protocol and a layer 7 protocol that it supports (analogous to the port
linkage between TCP and, say, ssh).  
	Why might you want this flexibility?  Control of the connection
integrity infrastructure is likely to reside in technical support.  But
there are a lot of people there who do not have a content-based need to
know -- many implementations would want to exclude them from the data
content confidentiality enclave.  For that reason, we may want the
flexibility to use a different security building block for the
application-layer security protections.  


> 
> AFAICT, there is no single RMT protocol at the transport layer like we see
> in the unicast world using TCP. At first sight, it seems to me that
> applying IPsec at the network layer is a preferred solution over solving
> the security problem at the transport/application layer multiple times.

IPsec is not a complete solution.  It applies to layer 3 which means you
are protecting infrastructure ... only indirectly protecting the data.
The practical implication is that you have technician-based insiders in
the enclaves.  (I've no objection whatever to reusing IPsec building
blocks at layers 4 and 7).