Re: [Rmt] Security scenarios and basic functions

[Vincent Roca <[e-mail]>]

Hello everybody,

My two cents on the security requirements problem raised by Magnus
(sorry it's a bit long, but there are so many things to say on the subject,
even if I'm far from being exhaustive...):

1/ What are the requirements in terms of services?

The sender authentication/content integrity services are clearly the basic
requirements in a context of open networks, where any attacker might
inject spurious traffic in an ongoing NORM or ALC session.
The goal might be to create a DoS attack (quite easy), or in some cases
to alter the objects transmitted (quite easy if the attacker can filter 
packets
and inject new ones).

The need for confidentiality must be clearly defined. As Magnus said, do
we only need to hide the content, or do we also need to hide the protocol
behavior itself? In the firs case (hide the object), the easy solution is to
encrypt it before submitting it the the NORM or ALC session. That's all.
If we want to hide more information, then things are getting more
complex. In that case, a layer 3 solution like IPsec is fine. For instance,
with a VPN between two sites, dumb packets might be exchanged, or
packets be delayed just to prevent a eavesdropper to collect accurate
statistics on what is exchanged. But I'm not sure this is what we need
at the first place in RMT...

The kind of communications sender->receiver, or vice-versa, or even (but
is there any need today?) receiver->receiver. As explained in the TESLA
I-D, only sender->receiver is addressed (which is sufficient for ALC) and
something else needs to be used for receiver->sender auth/integrity (used
by NORM feedback messages). Securing this feedback information might
be a little bit challenging since it should be a light (CPU) process. 
Signing
all packets with asymmetric cryptographic schemes is a door to DoS attacks
against the sender (who already has to make sure that the feedback rate is
not too high).

The dynamics of the receiver set will greatly impact the services that
can be offered. For instance, if the group is dynamic and if we want to
provide forward or backward secrecy (e.g. to hide new content to the
receivers who left the session), then re-keying mechanisms are
required, which is not a simple problem... But MSEC has addressed
the problem, and re-keying protocols are available.


2/ Where should these requirements be addressed?

I too prefer the use of Transport/Application security mechanisms, rather
than a layer 3 solution. Several reasons for that :

- RMT follows a BB approach, and security protocols fit well in this
approach. Provision has already been made to ease their use (see the
EXT_AUTH header extension of LCT and NORM).

- IPsec is nice for VPNs, but IPsec is not always suited to our needs.
There are use-cases (e.g. purely unidirectional networks) where IPsec
won't work at all... IMHO, IPsec could be used for some specific use-cases,
but it MUST NOT be the one and only solution promoted by RMT to address
the security needs.


3/ What about the integration of the security BBs in a real system?

Having BB that provides the needed services is fine, but using it is better,
and to that purpose, we also need additional services. A PKI is probably
one of them, unless receivers have another trusted way to obtain the 
sender's
public key. In some cases, an external scheme is needed to bootstrap the
security BB (this is what was suggested in case of TESLA for SRTP, see
RFC4442, but with TESLA for ALC/NORM we also defined an internal
optional bootstrapping scheme).
If we want to address the forward/backward secrecy needs, then a key
management scheme is needed. If the group is potentially very large, then
scalability will require a hierarchical solution... And the solution 
complexity
will grow accordingly. Etc.


IMHO, we first need to clearly define what are our goals (i.e. the desired
security services). This list should be done carefully, because everything
designed will depend on it. When preparing this list, one must take into
account that the target use cases are numerous and largely differ.

Then, in a second step, we can try to put in front of each situation, 
what is
the best (or most probably a list of) security mechanism(s) to fulfill the
needs. Even if some situations will be fairly complex to address, there are
others that can be easily solved (e.g. when there's a bidirectional 
connection
and if the number of receivers is "reasonable", a FLUTE/ALC session can
benefit from an auth/integrity service easily, even with high rate flows,
thanks to TESLA in direct mode time synchronization).

All in all, I think there's an interesting I-D to write on the subject, 
I mean
a joint document between MSEC and RMT of course since this is clearly
a document that need experts on both subjects.

Regards,

     Vincent


NB: I've just realized that I forgot to announce the new version of our
TESLA I-D to this list (it's now an MSEC document hence the mistake).

http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-for-alc-norm-00.txt

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