Re: [netlmm] Question on security model

Julien Laganier <julien.IETF@laposte.net> Tue, 11 September 2007 14:48 UTC

Return-path: <netlmm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV72S-0004dc-Iv; Tue, 11 Sep 2007 10:48:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV72R-0004dP-O7 for netlmm@ietf.org; Tue, 11 Sep 2007 10:48:27 -0400
Received: from hu-out-0506.google.com ([72.14.214.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV72P-0004yF-Pn for netlmm@ietf.org; Tue, 11 Sep 2007 10:48:27 -0400
Received: by hu-out-0506.google.com with SMTP id 31so598088huc for <netlmm@ietf.org>; Tue, 11 Sep 2007 07:48:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=+05l+CYdnjVpvH4SCdDAKj8I3GLbLum+lqdrg+E9v9M=; b=sRyz9KsEyd6KyZMX8+o6iXCj+N7GKeBqBYI4m+2TU7WUYTa3rwMyjEvUSk2yoDpWx8U7sKlUW79VDn5TEEfflrKYFch9mJUPrMDmSch/Lb+lqg2D8UA1Rv1Eienc1rbJLVEUV9ft3LvFVdhZzruTJxILJzATuQzwKdurutwS6ZI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=YjqLIK1G192gClCT4DG3/PauEXOdwadjLoYRM2NGc0ZbOGuaf9DVEvcdR6jklXs3ulHgzAVzqDIECdlNtLvPoDQ89Em6zUwdm8VWoWJKv/LU1mXtrFLheR6IKvZ4jlo1hlFmnN+hnIQRN9sCvL/i47Ef2KthW5zpt40EayMPoTY=
Received: by 10.67.106.19 with SMTP id i19mr760806ugm.1189522104602; Tue, 11 Sep 2007 07:48:24 -0700 (PDT)
Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id j1sm1178995ugf.2007.09.11.07.48.22 (version=SSLv3 cipher=OTHER); Tue, 11 Sep 2007 07:48:23 -0700 (PDT)
From: Julien Laganier <julien.IETF@laposte.net>
To: netlmm@ietf.org
Subject: Re: [netlmm] Question on security model
Date: Tue, 11 Sep 2007 16:48:19 +0200
User-Agent: KMail/1.9.6
References: <Pine.GSO.4.63.0708070000100.13701@irp-view13.cisco.com> <319D54578EAC3147BA8CC78DAB5467A501399A24@FRVELSMBS12.ad2.ad.alcatel.com> <00de01c7f47e$643e0030$37a36b80@amer.cisco.com>
In-Reply-To: <00de01c7f47e$643e0030$37a36b80@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200709111648.19896.julien.IETF@laposte.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: 'DE JUAN HUARTE FEDERICO' <Federico.De_Juan_Huarte@alcatel-lucent.fr>
X-BeenThere: netlmm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NETLMM working group discussion list <netlmm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/netlmm>
List-Post: <mailto:netlmm@ietf.org>
List-Help: <mailto:netlmm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
Errors-To: netlmm-bounces@ietf.org

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
netlmm@ietf.org
https://www1.ietf.org/mailman/listinfo/netlmm