Subject: Re: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05)

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 28 Sep 2007 09:42:10 -0700 (PDT)

Ahmad and all,
  I saw postings in the list saying let's move on which contradicts with statements suggesting creation of another thread .
  Should we move on or keep spawning new threads?

Regards,

Behcet

----- Original Message ----
From: Ahmad Muhanna <[email-masked]>
To: Wassim Haddad <[email-masked]>; DE JUAN HUARTE FEDERICO <[email-masked]>
Cc: netlmm <[email-masked]>
Sent: Friday, September 28, 2007 11:31:17 AM
Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05)

Hi Wassim,

Please see comment below.

Regards,
Ahmad

> Subject: RE: Text Proposal for Compromised MAG issue (was 
> [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05)
> 
> On Fri, 28 Sep 2007, DE JUAN HUARTE FEDERICO wrote:
> 
> > One final comment, if the MN can only be attached to one MAG at a 
> > given time, and if the LMA is going to validate the BU with the AAA 
> > Server and the AAA server is capable of tracking the 
> location of the MAG ... then do we still need timestamps for 
> message ordering?
> 
> => It is not only this feature which may be questionable.
 
[Ahmad]
May be you can help us understand how this feature is questionable with the proposed text hint?

> In 
> fact, what Ahmad is proposing about AAA (which btw is 
> interesting) can significantly enhance the protocol in many ways:
> If the AAA is able to tell the LMA where the MN is located 
> (i.e., the MAG),
 
[Ahmad]
So, can I read this that you think it is impossible and does not make sense?

> then you can simply let the LMA updates the 
> MAG (instead of the opposite) 

[Ahmad]
I am not experienced with those reverse logic mechanisms but I am willing to listen to your theory in a separate thread!

> and also let the LMA sends to 
> the MAG a temporary key to provide all SeND features without 
> the need for CGA. So basically, you can address the MAG 
> compromise problem together with the CGA problem...

[Ahmad]
Just FYI: 
1. A detailed solution for the so called compromised MAG is out-of-scope.
2. The text hint including the AAA has been proposed several times before on the ml by different people.
Finally, if you have a different text to propose (with the above 1 & 2 in mind) that would be great!

> 
> 
> Regards,
> 
> Wassim H.
> 
> 
> 
> > -----Message d'origine-----
> > De : Sri Gundavelli [mailto:[email-masked]] Envoyé : 
> vendredi 28 
> > septembre 2007 16:29 À : Ahmad Muhanna Cc : DE JUAN HUARTE 
> FEDERICO; 
> > netlmm Objet : RE: Text Proposal for Compromised MAG issue (was 
> > [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05)
> >
> > Hi Federico,
> >
> > We need to provide some guidance on how LMA implementations 
> can esnure the presence of a MN at a given MAG in a 
> deterministic fashion. One possible way is that the 
> Authentication infrastructure such as AAA that generated the 
> keys for the mobile node session would know the current point 
> of attachment. The LMA can query the same.
> >
> >       These entire arguments on MAG compromise ..etc, are 
> loosing arguments. Unfortunately, we have to agree, there may 
> not be access authentication, but, at the same time we have 
> to provide all the guidance on how to prevent MAG compromise. 
> These are all killer arguments. So, these issues just delay 
> the work. So, lets try to find some text and put a closure to 
> this work. By adding a reference to AAA, does not imply, we 
> have mandatory requirement on AAA, or we are  making AAA 
> stateful. Just any reasonable guidance with/without AAA 
> should be fine.
> >
> > Sri
> >
> >
> >
> >
> >
> > On Fri, 28 Sep 2007, Ahmad Muhanna wrote:
> >
> >> Hi Federico,
> >>
> >> It is very nice to know that we are getting into the beauty 
> >> context.:)
> >>
> >> Please let us focus on all of the added text:
> >>
> >> "
> >> .... by contacting a trusted entity which tracks the MN 
> current location, e.g. AAA server.
> >> "
> >>
> >> If AAA server is not stateful, then deployment may use 
> another trusted entity and that is granted by the above text.
> >> Originally I am in favor of leaving the whole thing 
> out-of-scope all together, but listing AAA server as an 
> example does not eliminate any other security mechanisms nor 
> require that all deployment have AAA server as stateful.
> >>
> >> Do not you agree?
> >>
> >> Sincerely, If we do not have any serious objection to this 
> text, we need to close the issue and move on.
> >> Thanks.
> >>
> >>
> >> Regards,
> >> Ahmad
> >>
> >>
> >>> -----Original Message-----
> >>> From: DE JUAN HUARTE FEDERICO
> >>> [mailto:[email-masked]]
> >>> Sent: Friday, September 28, 2007 4:23 AM
> >>> To: Muhanna, Ahmad (RICH1:2H10)
> >>> Cc: netlmm
> >>> Subject: RE: Text Proposal for Compromised MAG issue (was 
> [netlmm] 
> >>> Review ofdraft-ietf-netlmm-proxymip6-05)
> >>>
> >>> Hi Ahmad,
> >>>
> >>> in my understanding there's a general motivation to make 
> AAA Servers 
> >>> stateless, so the draft should not put such a strong "tracking"
> >>> requirement It is clear to me that in some/many 
> deployments the AAA 
> >>> Server is not stateless anyway, so this is a minor 
> comment But then, 
> >>> what the AAA Server actually tracks is the NAS and not really the 
> >>> MAG Somehow you're assuming that the AAA Server is aware of the 
> >>> relationship between NASs and MAGs
> >>>
> >>> With the current text, the security solution was left for 
> >>> deployments to choose With the new text you're trying to 
> close the 
> >>> solution space to one given solution Let's be fair here:
> >>>    - or the security solution is discussed and we do the beauty 
> >>> contest with all of them
> >>>    - or the security solution is not discussed and we leave the 
> >>> discussion for other contexts
> >>>
> >>> Regards
> >>>
> >>> federico
> >>>
> >>>
> >>>
> >>> -----Message d'origine-----
> >>> De : Ahmad Muhanna [mailto:[email-masked]] Envoyé :
> >>> vendredi 28 septembre 2007 07:37 À : Narayanan, Vidya; Vijay 
> >>> Devarapalli; Kilian Weniger Cc : netlmm Objet : RE: Text Proposal 
> >>> for Compromised MAG issue (was [netlmm] Review
> >>> ofdraft-ietf-netlmm-proxymip6-05)
> >>>
> >>>
> >>> All,
> >>>
> >>> I sincerely do not want to debate the use of revocation for 
> >>> compromised MAG at the present time. I am sure that all of us are 
> >>> interested in getting this issue addressed properly and have it 
> >>> closed sooner than later. What about the following text:
> >>>
> >>> Current text under security consideration:
> >>> ==========================================
> >>> "
> >>>    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.
> >>> "
> >>>
> >>> New Text:
> >>> =========
> >>>
> >>> "
> >>>    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
> >>>    by contacting a trusted entity which tracks the MN current 
> >>> location,
> >>>    e.g. AAA server.
> >>> "
> >>>
> >>> Regards,
> >>> Ahmad
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Narayanan, Vidya [mailto:[email-masked]]
> >>>> Sent: Wednesday, September 26, 2007 7:41 PM
> >>>> To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli; 
> Kilian Weniger
> >>>> Cc: [email-masked]
> >>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of
> >>>> draft-ietf-netlmm-proxymip6-05)
> >>>>
> >>>> Hi Ahmad,
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Ahmad Muhanna [mailto:[email-masked]]
> >>>>> Sent: Wednesday, September 26, 2007 4:12 PM
> >>>>> To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger
> >>>>> Cc: [email-masked]
> >>>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of
> >>>>> draft-ietf-netlmm-proxymip6-05)
> >>>>>
> >>>>> Hi Vidya,
> >>>>>
> >>>>> Using revocation for the compromised MAG was proposed by
> >>>> Kilian, et.
> >>>>> al.
> >>>>> but I am trying to help closing the issue so please allow
> >>>> me to jump
> >>>>> into this debate.
> >>>>>
> >>>>> In order for the LMA to validate the presence of the MN at
> >>>> a specific
> >>>>> MAG, the LMA needs to do one of the followings:
> >>>>>
> >>>>> 1. Validate the MN identity via a MN signature carried in
> >>>> the P-BU. In
> >>>>> P-MIPv6 this currently is not available since the P-BU is NOT 
> >>>>> initiated by the MN. (the most obvious option)
> >>>>>
> >>>>> 2. Validate the MN presence via another trusted entity that
> >>>>> *ALWAYS* tracks the MN current location, e.g. AAA server.
> >>>>>
> >>>>> 3. Validate the MN presence via another trusted entity that
> >>>> tracks the
> >>>>> current or latest location of the MN, e.g. the previous 
> MAG using 
> >>>>> binding revocation as was suggested by kilian et. al.
> >>>>>
> >>>>
> >>>> The LMA can't assume that the pMAG is trusted while the new
> >>> MAG is the
> >>>
> >>>> one lying.  Perhaps the MN really moved and the pMAG 
> continues to 
> >>>> claim it is there.  Regardless of which MAG tells the LMA
> >>> what, 1 or 2
> >>>
> >>>> needs to occur to conclude where the MN really is and 
> then, the LMA 
> >>>> can determine which of the MAGs was lying.
> >>>>
> >>>> Regards,
> >>>> Vidya
> >>>>
> >>>>> 4. may be there are other ways...
> >>>>>
> >>>>> In case that the MN is still at pMAG and has not moved, the
> >>>> pMAG can
> >>>>> easily indicate that in the binding revocation acknowledgement.
> >>>>>
> >>>>> So do not you think that should work?
> >>>>>
> >>>>> Regards,
> >>>>> Ahmad
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Narayanan, Vidya [mailto:[email-masked]]
> >>>>>> Sent: Wednesday, September 26, 2007 3:49 PM
> >>>>>> To: Vijay Devarapalli; Kilian Weniger
> >>>>>> Cc: [email-masked]
> >>>>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of
> >>>>>> draft-ietf-netlmm-proxymip6-05)
> >>>>>>
> >>>>>>
> >>>>>> A few observations here. I don't believe binding revocation
> >>>>> is going
> >>>>>> to solve anything here.  The fundamental issue is how the LMA
> >>>>>> *identifies* the compromised MAG, not how the
> >>> compromised MAG is
> >>>>>> notified that its binding is no longer valid.  Once the MAG is 
> >>>>>> identified as compromised, a number of remedies may be taken, 
> >>>>>> including, simply blacklisting the MAG and not accepting
> >>>>> PBUs from it.
> >>>>>> It is not critical that the binding be revoked, because,
> >>>>> the LMA has
> >>>>>> already identified where the MN really is and it just
> >>>> needs to use
> >>>>>> that binding for data acceptance/forwarding.
> >>>>>>
> >>>>>>
> >>>>>> The issue of how the LMA identifies a compromised MAG 
> cannot be 
> >>>>>> tackled without an independent verification of the
> >>>> presence of the
> >>>>>> MN at that particular MAG.  So, we need to focus on
> >>>> providing hints
> >>>>>> on how the LMA may go about
> >>>>> achieving that.
> >>>>>>
> >>>>>> Vidya
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Vijay Devarapalli
> >>> [mailto:[email-masked]]
> >>>>>>> Sent: Wednesday, September 26, 2007 11:08 AM
> >>>>>>> To: Kilian Weniger
> >>>>>>> Cc: Narayanan, Vidya; [email-masked]
> >>>>>>> Subject: Re: Compromised MAG issue (was [netlmm] Review of
> >>>>>>> draft-ietf-netlmm-proxymip6-05)
> >>>>>>>
> >>>>>>> Kilian Weniger wrote:
> >>>>>>>> Narayanan, Vidya wrote:
> >>>>>>>>>>> - Security considerations: MAG Compromise:
> >>>>>>>> ...
> >>>>>>>>> If we claim this is an issue in the security
> >>>>>>> considerations section
> >>>>>>>>> and claim that the fix to it is for the LMA to ensure
> >>>>> the MN is
> >>>>>>>>> actually attached to the MAG, we can't quite hand
> >>>> wave on some
> >>>>>>>>> possible ways to do that.  Those are just hints for
> >>>>>>> deployments that
> >>>>>>>>> are concerned about MAG compromise.  But, those hints
> >>>>> need to be
> >>>>>>>>> captured in the security considerations section.
> >>>> The threats
> >>>>>>>>> document captures this threat and it is a valid one - so,
> >>>>>>> I believe
> >>>>>>>>> we need some text here.  The type of "detail" is what
> >>>>> I tried to
> >>>>>>>>> provide with the examples on AAA checks or CGA
> >>>>>> signatures - and, I
> >>>>>>>>> don't think we need a lot of detail here; a few
> >>>>>> sentences would be
> >>>>>>>>> good.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> I had a similar comment a while ago. I think that a draft
> >>>>>>> describing a
> >>>>>>>> severe security issue should at least give hints how this
> >>>>>>> can be solved.
> >>>>>>>>
> >>>>>>>> Recently Sri, Vijay, Kuntal and I had an offline
> >>>>> discussion about
> >>>>>>>> another possible solution to detect a compromised MAGs,
> >>>>>>> which relies
> >>>>>>>> on PMIP signaling only.
> >>>>>>>>
> >>>>>>>> The basic idea is that if two MAGs simultaneously claim
> >>>>>>> that the MN is
> >>>>>>>> attached, one of the MAGs must lie and is probably a
> >>>>>>> compromised MAG.
> >>>>>>>> The assumption is that the MN cannot at the same time be
> >>>>>>> attached to
> >>>>>>>> two MAGs, at least not with the same network interface.
> >>>>>>>>
> >>>>>>>> More specifically, when the LMA accepts a valid PBU from a
> >>>>>>> new MAG, it
> >>>>>>>> changes the BCE (i.e., there is no impact on handover
> >>>>> delay) and
> >>>>>>>> notifies the old MAG (i.e., old address in BCE) about
> >>>>>> this. The old
> >>>>>>>> MAG then checks whether the MN is still attached. If this
> >>>>>>> is the case,
> >>>>>>>> it informs the LMA about this. The LMA then learns that two
> >>>>>>> different
> >>>>>>>> MAGs claim MN attachement, which is not possible under the
> >>>>>>> assumption
> >>>>>>>> stated above. Hence, after receiving one or more such
> >>>>>>> notifications,
> >>>>>>>> the LMA can identify the compromised MAG and stop
> >>>>>> trusting this MAG.
> >>>>>>>>
> >>>>>>>> A remaining problem was which message should be used to
> >>>>>>> inform the old
> >>>>>>>> MAG about the BCE change. PBA and revocation msg were
> >>>>>>> discussed, but
> >>>>>>>> the former is not sent unsolicited according to RFC3775
> >>>>>>> (which could
> >>>>>>>> be overidden by PMIP spec of course) and the latter is not 
> >>>>>>>> standardized yet.
> >>>>>>>
> >>>>>>> As I said in another threat, we really need to
> >>> standardize the
> >>>>>>> revocation message from the LMA to the old MAG ASAP.
> >>>>>>>
> >>>>>>> Vijay
> >>>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> netlmm mailing list
> >>>>>> [email-masked]
> >>>>>> https://www1.ietf.org/mailman/listinfo/netlmm
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> netlmm mailing list
> >>> [email-masked]
> >>> https://www1.ietf.org/mailman/listinfo/netlmm
> >>>
> >>
> >>
> >> _______________________________________________
> >> netlmm mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/netlmm
> >>
> >
> >
> > _______________________________________________
> > netlmm mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/netlmm
> >
> >
> 

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

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 28 Sep 2007 11:44:27 -0500

Hi Behcet,
 
No there is no contradiction. that issue is not related here and if we need to discuss it further we can go ahead and do so in a separate thread. that all what I meant.
 
Cheers.

Regards, 
Ahmad 

________________________________

	From: Behcet Sarikaya [mailto:[email-masked]] 
	Sent: Friday, September 28, 2007 11:42 AM
	To: Muhanna, Ahmad (RICH1:2H10)
	Cc: netlmm
	Subject: Re: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05)

	Ahmad and all,
	  I saw postings in the list saying let's move on which contradicts with statements suggesting creation of another thread  <http://mail.yimg.com/us.yimg.com/i/mesg/tsmileys2/01.gif> .
	  Should we move on or keep spawning new threads?

	Regards,
	
	Behcet

	----- Original Message ----
	From: Ahmad Muhanna <[email-masked]>
	To: Wassim Haddad <[email-masked]>; DE JUAN HUARTE FEDERICO <[email-masked]>
	Cc: netlmm <[email-masked]>
	Sent: Friday, September 28, 2007 11:31:17 AM
	Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05)

	Hi Wassim,

	Regards,
	Ahmad

	[Ahmad]

	[Ahmad]

	[Ahmad]

	[Ahmad]
	Just FYI: