RE: [netlmm] Question on security model

["Alper Yegin" <[e-mail]>]

There are two types of components to security space for PMIP (so far)...

Security mechanism: IPsec, Auth Option, etc...
Security association: MAG-LMA, per-MN MAG-LMA


All combinations are possible between the two components.

While recommending support for one combination (IPsec with MAG-LMA SA) is
necessary for interop, we shall not prevent use of other combinations in the
base spec.  

I'm fine with the current recommendation, as long as we weed out text that
unnecessarily or accidentally bars other combinations. This is better than
having to enter a beauty contest and try to pick a winner.

Alper 

> -----Original Message-----
> From: Julien Laganier [mailto:[e-mail]]
> Sent: Tuesday, September 11, 2007 5:48 PM
> To: [e-mail]
> Cc: 'DE JUAN HUARTE FEDERICO'
> Subject: Re: [netlmm] Question on security model
> 
> On Tuesday 11 September 2007, Sri Gundavelli wrote:
> > Hi Federico,
> >
> > I dont want to reopen this thread or enter any discussions. But, let
> > me quickly make these points.
> >
> >
> > 1. The security model, Configuring a MAG with all the MN's SA's does
> > not offer any greater security than the other security model. Even in
> > the Per-Node security model, there could be multiple SA's between the
> > LMA and MAG, and different SA's can be used for different flows.
> >
> > 2. If a MAG is compromised, so are all the MN SA's. The damage is the
> >    same. If we argue that the MAG will not be allowed to create a BCE
> >    for a MN, that it does not have SA for, the same authorization can
> >    be achieved in the other model, by requiring the LMA to authorize
> > the MAG before it creates BCE for a given MN.
> >
> > There is no advantage using Per-MN security model. Its just a false
> > sense of security, IMHO.
> 
> Trying to be more precise here.
> 
> The "Per-MN security model" reffered to is actually one in which the a
> LMA and a given MAG have a different security association for each MN
> attached to that MAG.
> 
> I think it is more precise to denote this model as "Per-MN LMA-MAG
> Security Association" model.
> 
> In this model, even though there's one security association per MN, the
> security association is still established between the _MAG_ and LMA.
> Thus, if the _MAG_ is compromised, the per-MN LMA-MAG SA cannot prevent
> the MAG to issue undue signalling on behalf of a MN attached to it
> since it has the corresponding per-MN LMA-MAG security association. On
> the other hand, it would prevent a compromised MAG to issue undue
> signalling on behalf of a MN which is not attached to it _if_ it has no
> per-MN LMA-MAG SA for that MN.
> 
> The draft currently specifies a "Per-MAG LMA-MAG Security Association"
> model with no mechanisms in place to prevent a compromized MAG to issue
> undue signalling for any MN (both attached and not attached to it). The
> draft does however call in it security considerations section for such
> a mechanism to be present, but as part of another, unspecified,
> protocol:
> 
>    To eliminate the threats related to a compromised mobile access
>    gateway, this specification recommends that the local mobility anchor
>    before accepting a Proxy Binding Update message for a given mobile
>    node, should ensure the mobile node is definitively attached to the
>    mobile access gateway that sent the binding registration request.
> 
> Thus, the "Per-MN LMA-MAG Security Association" model can be more secure
> than the "per-MAG LMA-MAG Security Association" against MAG
> compromission only if is guaranteed that establishment of the "Per-MN
> LMA-MAG Security Association" cannot happen with a MAG to which the MN
> is not attached. That might be ensured by tying this SA establishment
> to network access control, but this would be, as for the "Per-MAG
> LMA-MAG Security Association", a mechanism implemented as part of
> another, unspecified, protocol.
> 
> In conclusion, without another mechanism realizing what's being called
> for in the security considerations, both security models are IMHO
> equivalent.
> 
> --julien
> 
> _______________________________________________
> netlmm mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/netlmm


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