Re: Security scenarios and basic functions

Hi Magnus,

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

On Fri, 30 Jun 2006, Magnus Westerlund wrote:

> 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

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.

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

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

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

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

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;
> - Which security models are going to be mandatory to implement for
> Internet usage?

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

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

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?

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

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

br,
	George

>
>
> 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 protected]
>
> _______________________________________________
> Rmt mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rmt
>