Subject: [Rmt] Security scenarios and basic functions

From: Magnus Westerlund <[email-masked]>
Date: Fri, 30 Jun 2006 13:40:44 +0200

Hi,

I think there the basic security issues with the RMT PIs and the BBs 
they use are common for a transport protocol.

1. Source authentication, i.e. the capability to determine and verify 
who is sending the packets

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.

The above are all cases that applies in the direction of the sender -> 
receivers. To my understanding there are also cases of the above when 
some or all of these functions needs to exist also in the direction 
receiver to sender, or maybe even receiver to receiver. I think 
congestion control mechanisms are such a case where the this may occur.

The usage of the above security mechanisms can vary and I think one of 
the more fundamental ones are in regards to the association between the 
entities in the transport session. In many cases the receivers will 
create some kind of relationship. This will be especially true for the 
confidentiality protection where the transmitter will need the identity 
of the receiver before giving them keys necessary for decrypting to 
ensure only intended receivers see the content. This is certainly a 
model that can be used in many applications however maybe not all.

In applications where the identity of the receiver is irrelevant (or 
possible intended to allow for anonymous participation), but the 
integrity and commonly the source identify is the data important another 
model is needed.

To my understanding a extended IPsec solution could cover the first use 
cases, while the second can be covered by the TESLA BB. Both under 
development in MSEC. Or is integrity protecton plus object 
confidentiality a more interesting model? My big questions here are;
- Which security models are going to be mandatory to implement for 
Internet usage?
- does the necessary key management exist for that solution?
- are there anything in the protocols and BBs that prevents this from 
working?
- are there other issues that should be considered when defining how one 
per default secures the different PIs?

This is only a start, or rather a reminder about the need for continuing 
the work on the security solutions. I would appreciate some discussion 
on how to secure the present existing PIs.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: George Gross <[email-masked]>
Date: Fri, 30 Jun 2006 07:11:13 -0400 (EDT)

Hi Magnus,

I tend to agree that a discussion of RMT protocol suite security is
overdue. more observations inline below...

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

> case even seeing what is happening within the protocol itself.

some use cases may optionally add anti-replay protection as another
security option.

> congestion control mechanisms are such a case where the this may occur.

Yup, the congestion control and NACK repair request messages in NORM come
to mind.

> cases, while the second can be covered by the TESLA BB.
> Both under development in MSEC.

The MSEC IPsec extensions draft certainly aspires to solve the first set
of use cases. we'd be interested to hear from the folks at RMT if that
draft falls short of what they expect ;o) perhaps start by taking a look
at its appendix A for the service models.  There is also a recently
published individual submission draft for IPsec using TESLA
authentication.

> 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?

> My big questions here are;

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.

I suppose you could conjure up a transport layer "multicast TLS", but
would you end with anything much different than the ESP over UDP
encapsulation that exists as RFC3948? (BTW, RFC3948 refers to a unicast SA
so the MSEC IPsec draft may add an interpretation for a group SA)

> - does the necessary key management exist for that solution?

GSAKMP transitioned to RFC4535 this past week, along with the group
security policy token spec (RFC4534). A mapping of the policy token to
MSEC IPsec has yet to be published. GSAKMP is an extensible framework, so
it could alternatively provide a transport or application layer security
solution.

If one prefers IKE oriented solutions, the GDOI v2 is based on IKE-v1 and
RFC2401. It is not clear to me yet how well it aligns with the enhanced
semantics found in RFC4301 and the MSEC IPsec draft. The GDKP protocol is
based on IKE-v2/RFC4301, however, that work has just started.

So, there is work in progress within MSEC, it is simply a matter of folks
focusing enough energy to get them across the finish line...

> per default secures the different PIs?

The unidirectional traffic flow congestion control mechanisms (i.e.
LCT/ALC) are intriguing. As I understand it, the Group Speaker sends the
same FEC protected data in parallel at different flow rates, and the Group
Receivers pick some set of one or more data flows to assemble the sent
object. I assume each of those parallel flows has its own multicast IP
address. Therefore, I infer it may be a useful optimization to have Group
Receivers do a single MSEC group registration, yet setup multiple group
data SAs. If this is the case, then MSEC IPsec draft should mention this
use case.

comments?

> on how to secure the present existing PIs.

folks in RMT are also welcome to contribute or comment over at MSEC...

br,
	George

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 30 Jun 2006 10:03:05 -0700

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

> > case even seeing what is happening within the protocol itself.
Good analysis.

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

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

---

From: "Baoqing Ye" <[email-masked]>
Date: Fri, 30 Jun 2006 16:38:54 -0400

my 2 cents:

> > > case even seeing what is happening within the protocol itself.

-- I'd suggest to leave confidentiality as optional, or at least to be
really careful about the algorithms to be proposed, considering the overhead
the encryption of all payload it brings to the picture which will inevitably
reduce overall performance (significantly).

> blocks at layers 4 and 7).

-- I agree with the statement above. I also wonder if there has been any
analysis work done from performance perspective for layer 3 solution v.s.
layer 4/7 solutions.

-Baoqing Ye-
Verizon Lab, LAOMS59, 40 Sylvan Road, Waltham, MA 02451, USA
_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 30 Jun 2006 13:53:25 -0700

> I also wonder if there has been any analysis work done from
performance perspective for layer 3 solution v.s. layer 4/7 solutions.

The 'analysis' I do when I teach the class is to sketch box/wires
solutions on the board and then have the students count the insiders.
While reminding them that 'insider' is the first word in the term
'insider attack'.  (I replay the Walker case in the process of this
analysis).

One of the other case studies to analyze is the 'credit card loss'
scenario.  And it doesn't seem to matter which specific one you choose.
None of them seem to trace back to SSL breakage; a good share of them
trace to unauthorized access to the database or outright theft of the
drive.  Where the data is stored as plaintext.  SSL is end to end _only_
in the network, not the total information system.  (S/MIME
implementations, btw, are true end-to-end -- an encrypted body part will
be stored on the recipients hard drive in the same form that it was
transmitted.  You can check your UA by sending yourself encrypted
e-mail, storing it, and then retrieving it -- the UA should ask for your
private key again).  

There are two easily discerned trends here:
	- the lower in the ISO model that you attack a security problem the
poorer your interoperability quotient will be.  
	- the higher in the model that you attack a security problem the fewer
the number of non-essential insiders there are.  

On Fri, 2006-06-30 at 16:38 -0400, Baoqing Ye wrote:
> really careful about the algorithms to be proposed, considering the
> overhead the encryption of all payload it brings to the picture which
> will inevitably reduce overall performance (significantly).  
> 
> -- I agree with the statement above. I also wonder if there has
> been any analysis work done from performance perspective for layer 3
> solution v.s. layer 4/7 solutions.
>  
> -Baoqing Ye-