RE: [netlmm] Question on security model

["Sri Gundavelli" <[e-mail]>]

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.

With respect to your other question about when the discussions took place,
when the base draft was chosen, there were proposals that pitched other
security models and they were presented in the WG. The WG chose a specific
proposal that supported Per-Node security model.

Sri
 
   

> -----Original Message-----
> From: DE JUAN HUARTE FEDERICO 
> [mailto:[e-mail]] 
> Sent: Tuesday, September 11, 2007 7:03 AM
> To: Ahmad Muhanna
> Cc: [e-mail]
> Subject: [netlmm] Question on security model
> 
> Hi Ahmad,
> 
> you're right that I was shamelessly abusing of the thread
> I apologize for that: I've changed the subject this time
> 
> As I said, I understand that the security model has already 
> been discussed and the decision has been to go with a per-node SA
> I would appreciate if anybody could send me a pointer to any 
> record capturing the discussion that led to this decision
> 
> More concretely, I would like to find out:
>    - (first and most important) how the threat of a 
> compromised MAG is addressed with the per-node SA model?
>    - did the discussion take into account the fact that MAG 
> and LMA may be located in different administrative domains?
>    - did the discussion take place before or after the 
> decision to move away from DT solution to PMIP?
> 
> Thanks
> 
> federico
> 
> -----Message d'origine-----
> De : Ahmad Muhanna [mailto:[e-mail]] 
> Envoyé : lundi 10 septembre 2007 20:08
> À : DE JUAN HUARTE FEDERICO; Vijay Devarapalli
> Cc : [e-mail]
> Objet : RE: [netlmm] Issue: Auth Option support
> 
> Hi Federico,
> 
> The issue of using a per-Node SA has been discussed long time 
> ago and reached consensus. This thread is not about the use 
> of Per-Node vs. Per-MN SA. It is about relaxing the mandate 
> of the use IPsec to "MUST implement" and SHOULD use"
> That is it.
> 
> I Hope this address your concern.
> 
> Regards,
> Ahmad
>  
> 
> > -----Original Message-----
> > From: DE JUAN HUARTE FEDERICO
> > [mailto:[e-mail]]
> > Sent: Monday, September 10, 2007 12:44 PM
> > To: Vijay Devarapalli; Muhanna, Ahmad (RICH1:2H10)
> > Cc: [e-mail]
> > Subject: RE: [netlmm] Issue: Auth Option support
> > 
> > Hi,
> > 
> > I am slowly catching up with NETLMM and I acknowledge that in some 
> > aspects (e.g. security model) I'm definitely late
> > 
> > I understand from this email that, in this group it has 
> already been 
> > decided to go for a per-node security model I followed the 
> discussion 
> > about the security model in a PMIP solution in a given 
> forum (Wimax) 
> > some years ago, and then it was considered that a per-node security 
> > model was was not sufficient The main argument I remember is the 
> > threat of the MAG being compromised and indiscriminately allocating 
> > resources from the LMA This is especially worrisome when 
> the the MAG 
> > and the LMA belong to 2 different administrative domains Has this 
> > problem been addressed in this group?
> > 
> > Thanks
> > 
> > federico
> > 
> > 
> >  
> > 
> > -----Message d'origine-----
> > De : Vijay Devarapalli [mailto:[e-mail]]
> > Envoyé : lundi 10 septembre 2007 17:03 À : Ahmad Muhanna Cc : 
> > [e-mail] Objet : Re: [netlmm] Issue: Auth Option support
> > 
> > Ahmad,
> > 
> > I don't believe the security model of using just one security 
> > association between the MAG and the LMA for protecting the proxy BU 
> > and Proxy BAck changes irrespective of whether IPsec or RFC 4285 is 
> > used. So
> >   I don't agree with the suggested change.
> > 
> > Vijay
> > 
> > Ahmad Muhanna wrote:
> > >  
> > >> Subject: Re: [netlmm] Issue: Auth Option support
> > >>
> > >> Sri,
> > >>
> > >> I agree with "SHOULD" for using IPsec and "MUST" for
> > supporting IPsec
> > >> on the MAG and the LMA.
> > >>
> > >> If thats the consensus, we need to modify a few sentences in the 
> > >> draft.
> > >>
> > >> In section 4, replace
> > >>
> > >>>    The signaling messages, Proxy Binding Update and 
> Proxy Binding
> > >>>    Acknowledgement, exchanged between the mobile access
> > >> gateway and the
> > >>>    local mobility anchor MUST be protected using IPsec
> > >> [RFC-4301] and
> > >>>    using the established security association between them.  The
> > >>>    security association of the specific mobile node for 
> which the
> > >>>    signaling message is initiated is not required for
> > >> protecting these
> > >>>    messages.
> > >> with
> > >>
> > >>     The signaling messages, Proxy Binding Update and 
> Proxy Binding
> > >>     Acknowledgement, exchanged between the mobile access
> > gateway and
> > >> the
> > >>     local mobility anchor MUST be protected using security 
> > >> associations
> > >>     established between them. The security association of
> > the specific
> > >>     mobile node for which the signaling message is 
> initiated is not
> > >>     required for protecting these messages.
> > >>
> > >> We need the MUST above since we have to say that the 
> proxy BU and 
> > >> proxy BAck must be protected, irrespective of whether
> > IPsec or some
> > >> other mechanism is used.
> > > 
> > > [Ahmad]
> > > Hi Vijay,
> > > 
> > > As far as I remember, the whole security concept of using a
> > per-Node
> > > SA for PMIPv6 was based on the use of IPsec. Although, I
> > see why you
> > > proposed the text but I still see a problem here. For 
> example, the 
> > > above text allows the use of an authentication option
> > similar to FA-HA
> > > AE to secure the P-BU/P-BA.
> > > 
> > > Now, since allowing a per-Node SA to be used in PMIPv6 
> was based on 
> > > the use of IPsec, I believe we clearly need to keep that 
> as part of 
> > > the spec text.
> > > 
> > > What about the following slight modification to what you
> > just proposed:
> > > 
> > >     The signaling messages, Proxy Binding Update and Proxy Binding
> > >     Acknowledgement, exchanged between the mobile access
> > gateway and the
> > >     local mobility anchor MUST be protected using a
> > security association
> > >     established between them. If IPsec is used, the security 
> > > association
> > > 
> > >     of the specific mobile node for which the signaling 
> message is 
> > > initiated
> > >     is not required for protecting these messages.
> > > 
> > > Thanks,
> > > Ahmad
> > > 
> > >> Add one sentence that says
> > >>
> > >>     The mobile access gateway and the local mobility anchor MUST
> > >>     implement IPsec for protecting the Proxy Mobile IPv6 
> signaling
> > >>     messages [RFC-4301].
> > >>
> > >> The paragraph that comes after already uses "SHOULD" for 
> using ESP.
> > >>
> > >>>    IPsec ESP [RFC-4303] in transport mode with 
> mandatory integrity
> > >>>    protection SHOULD be used for protecting the signaling
> > messages.
> > >>>    Confidentiality protection of these messages is not required.
> > >> Hope that is sufficient.
> > >>
> > >> Vijay
> > >>
> > >>
> > >> Sri Gundavelli wrote:
> > >>> I want some comments on this issue raised by Alper.
> > >>>
> > >>>
> > >>> Also, if I interpret Sec 5.1 [3775], the IPSec is being
> > >> mandated, only
> > >>> the use of IPsec ESP is optional.
> > >>>
> > >>> --------
> > >>> 5.1.  Binding Updates to Home Agents
> > >>>
> > >>>    The mobile node and the home agent MUST use an IPsec security
> > >>>    association to protect the integrity and authenticity of
> > >> the Binding
> > >>>    Updates and Acknowledgements.  Both the mobile nodes
> > and the home
> > >>>    agents MUST support and SHOULD use the Encapsulating
> > >> Security Payload
> > >>>    (ESP) [6] header in transport mode and MUST use a
> > >> non-NULL payload
> > >>>    authentication algorithm to provide data origin 
> authentication,
> > >>>    connectionless integrity and optional anti-replay
> > >> protection.  Note
> > >>>    that Authentication Header (AH) [5] is also possible but
> > >> for brevity
> > >>>    not discussed in this specification.
> > >>> -------
> > >>>
> > >>>
> > >>> I'm confused, should the draft say
> > >>>
> > >>> "Both LMA and MAG MUST implement IPsec" and "all the signaling 
> > >>> messages SHOULD be protected using IPSec".
> > >>>
> > >>> Will this ok, when reviewed by the security folks ?
> > >>>
> > >>> or mandate IPsec for this specification and let other draft
> > >> relax this
> > >>> in the presence of an alternative approach ?
> > >>>
> > >>> Please comment.
> > >>>
> > >>>
> > >>> Sri
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>  
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Alper Yegin [mailto:[e-mail]]
> > >>>> Sent: Tuesday, August 07, 2007 1:41 AM
> > >>>> To: 'Sri Gundavelli'; [e-mail]
> > >>>> Subject: RE: [netlmm] Issue: Auth Option support
> > >>>>
> > >>>>> The issue was related to the use of MUST clause in
> > specifying the
> > >>>>> IPSec requirement for Proxy Mobile IPv6 protocol. Alper was 
> > >>>>> suggesting that we relax that requirement and
> > potentially leave a
> > >>>>> room for Auth Option support in future.
> > >>>> Actually, I didn't mean it specifically for Auth Option. 
> > It can be
> > >>>> anything.
> > >>>> Given that the security is handled by a separate protocol,
> > >> why lock
> > >>>> it down to "IPsec", when some other protocol (Auth
> > Option being one
> > >>>> example) cannot
> > >>>> be used.
> > >>>>
> > >>>>> But, as most people agreed and as supported by Jari, this can
> > >>>> My understanding was the opposite, especially about Jari's
> > >> statement.
> > >>>>> always be changed in future when the support for new security 
> > >>>>> mechanisms such as Auth Option are defined for Proxy
> > >> Mobile IPv6 and
> > >>>>> that specific document can always modify this requirement.
> > >>>>> So, no changes will be made to the document on this issue.
> > >>>> What if Auth Option is good enough as written?
> > >>>> What if a document in another SDO defines the
> > alternative security
> > >>>> mechanism?
> > >>>>
> > >>>> For the type of interop we are seeking in IETF, "MUST
> > >> implement" is
> > >>>> good enough. "MUST use" is not necessary.
> > >>>>
> > >>>> Alper
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>> Regards
> > >>>>> Sri
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> netlmm mailing list
> > >>>>> [e-mail]
> > >>>>> https://www1.ietf.org/mailman/listinfo/netlmm
> > >>> _______________________________________________
> > >>> netlmm mailing list
> > >>> [e-mail]
> > >>> https://www1.ietf.org/mailman/listinfo/netlmm
> > >>
> > >> _______________________________________________
> > >> netlmm mailing list
> > >> [e-mail]
> > >> https://www1.ietf.org/mailman/listinfo/netlmm
> > >>
> > 
> > 
> > _______________________________________________
> > netlmm mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/netlmm
> > 
> 
> _______________________________________________
> netlmm mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/netlmm

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