Subject: Re: [Rmt] Security scenarios and basic functions

From: George Gross <[email-masked]>
Date: Sun, 2 Jul 2006 11:39:02 -0400 (EDT)

Hi Rex,

I can well appreciate your advocating end-to-end security at the highest
layer possible, especially for the high assurance applications that your
organization likely has in operation.

OTOH, I think you've exposed one of the dilemmas facing the IETF security
community. There have been numerous security protocols developed in the
IETF, but arguely only TLS is widely used and could be labeled successful.
SMIME, which you cited as an example of good end to end security, has
failed to acquire a significant widescale market acceptance.  Training the
end user populace and cost of operating a PKI being among the reasons it
is not used. The IPsec-based VPNs are widely deployed but as you have
pointed out, they are operated by the technical "insiders".  That said, it
still comes down to local security policy to say what is "good enough".

Awhile back I attended the SAG meeting at the San Diego IETF. There was
alot of discussion about how almost all of the IETF security protocols
fail the infamous "grandmother test". The conclusion at that SAG was that
security usually isn't transparent to the end user or at least it isn't
*very easy* to use except by experts. So security does not generally get
used. TLS passed the grandmother test. SMIME and IPsec don't.

Given the above, I could endorse an effort to standardize a "RMTLS" only
if we were confident that it could pass the grandmother test. Also, the
combined RMT and MSEC community has to get energized enough to invest the
3 years effort (the typical time it takes to get an RFC) to develop
transport layer security for the RMT protocols. I happen to think we're
closer than 3 years effort for an MSEC IPsec-based solution.

It would be valuable to get the RMT consensus one way or the other on this
question: IPsec at network layer or RMT transport layer security?

br,
	George

 On Fri, 30 Jun 2006, Rex Buddenberg wrote:

> > 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:
> > my 2 cents:
> >
> > On 6/30/06, Rex Buddenberg <[email-masked]> wrote:
> >         On Fri, 2006-06-30 at 07:11 -0400, George Gross wrote:
> >         > > 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.
> >         >
> >
> > -- 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).
> >
> >         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).
> >
> > -- 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: Magnus Westerlund <[email-masked]>
Date: Mon, 03 Jul 2006 11:09:10 +0200

Hi,

Great that a discussion has started.

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

At least for FLUTE it is quite clear that you can provide security for 
the file objects being delivered using for example SMIME. The question 
with such a solution for FLUTE is the leakage of information about what 
you are transporting due to the FDT and the protocol headers.

When it comes to a RMTTLS I think it misses the goal. I think it is 
quite clear that RMT will need packet integrity and authentication to 
protect against some serious attacks. Especially important when RMT PIs 
are used in ASM networks when spoofing and insert attacks become way to 
easy. Having something on payload level may not be sufficient in these 
cases. You need to bind the protocol information to a particular payload.

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]

---

From: Vincent Roca <[email-masked]>
Date: Mon, 03 Jul 2006 11:44:38 +0200

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