[netlmm] RE: Question on security model

["Ahmad Muhanna" <[e-mail]>]

Hi Federico,
No problem.

I agree with Sri on this point too, I do not support Re-opening this topic again.

However, I would like to emphasize one point that Sri mentioned in his reply, if compromised MAG is a real threat, then LMA may optionally choose to authorize the MN PMIP service at initial attach. I guess that takes care of the threat you have in mind.

Regards,
Ahmad
 

> -----Original Message-----
> From: DE JUAN HUARTE FEDERICO 
> [mailto:[e-mail]] 
> Sent: Tuesday, September 11, 2007 9:03 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: [e-mail]
> Subject: 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