Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm] Review of draft-ietf-netlmm-proxymip6-05)

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 28 Sep 2007 00:36:35 -0500

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

---

From: "Premec, Domagoj" <[email-masked]>
Date: Fri, 28 Sep 2007 08:33:38 +0200

Hi Ahmad,

If we have context transfer mechanism in place between MAGs, then the MN may move to a new MAG without authentication and the AAA  would not know about the new MAG. I don't think we can assume that the AAA has an accurate info on the MS location.

domagoj

> Sent: 28. rujan 2007 07:37
> Cc: netlmm
> Subject: 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:
>

---

From: "Jong-Hyouk Lee" <[email-masked]>
Date: Fri, 28 Sep 2007 16:07:45 +0900

Hi Domagoj.

I'd like to be the side of AAA. As you mentioned, the context transfer
mechanism may provide a reduced authentication time or procedure in the
handoff procedure. But, I think that AAA has to recognize the state
information of mobile node including the accurate location information.
Why? For instance, for an accurate accounting for the mobile node.

So, I agree with Ahmad Muhanna's text. (Using AAA mechanism is natural, why
not?)

Cheers.

On 9/28/07, Premec, Domagoj <[email-masked]> wrote:
>
> Hi Ahmad,
>
> If we have context transfer mechanism in place between MAGs, then the MN
> may move to a new MAG without authentication and the AAA  would not know
> about the new MAG. I don't think we can assume that the AAA has an accurate
> info on the MS location.
>
> domagoj
>
>

-- 
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org
_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Fri, 28 Sep 2007 11:22:30 +0200

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:

New Text:
=========

"

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 28 Sep 2007 08:09:06 -0500

Hi Domagoj,

Any mechanism which is not currently defined and can not be referenced
in the base PMIPv6 protocol is not to be considered a default for the
PMIPv6 base protocol. Context transfer is one example. Therefore, when
documenting a high level solution (hint) we need to consider the basic
default scenario.

Having said that and keeping it in mind, the provided text is accurate.
On the other hand, we do not need to list all possible trusted entities
which may have the current location of the MN in all different
deployments. Again, that is out-of-scope. AAA server was listed as an
example only.

I hope that is good enough to close this thread and move on.
Thanks.

Regards,
Ahmad

> From: Premec, Domagoj [mailto:[email-masked]] 
> Sent: Friday, September 28, 2007 1:34 AM
> To: Muhanna, Ahmad (RICH1:2H10); Narayanan, Vidya; Vijay 
> Devarapalli; Kilian Weniger
> Cc: netlmm
> If we have context transfer mechanism in place between MAGs, 
> then the MN may move to a new MAG without authentication and 
> the AAA  would not know about the new MAG. I don't think we 
> can assume that the AAA has an accurate info on the MS location.
> 
> domagoj
> 
> 
> > Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm] 
> > Review ofdraft-ietf-netlmm-proxymip6-05)
> > 
> > 
> > All,
> > 
> > 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:
> >

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 28 Sep 2007 08:19:10 -0500

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

> From: DE JUAN HUARTE FEDERICO 
> [mailto:[email-masked]] 
> Sent: Friday, September 28, 2007 4:23 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: netlmm
> 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:
> 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,
>

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 28 Sep 2007 07:29:25 -0700 (PDT)

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 28 Sep 2007 07:49:17 -0700

Hi Jong-Hyouk,

I'd like to be the side of AAA. As you mentioned, the context transfer
mechanism may provide a reduced authentication time or procedure in the
handoff procedure. But, I think that AAA has to recognize the state
information of mobile node including the accurate location information. Why?
For instance, for an accurate accounting for the mobile node. 

OK
 
Thanks
Sri

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Fri, 28 Sep 2007 17:30:41 +0200

Hi Sri, Ahmad

I was fine with the original text
If addressing the security concern is necessary because of IESG or whatever and you're going to hint at possible solutions, then I would add as an alternative that the MAG may add a per-MN signature to the PBU.

> .... by contacting a trusted entity which tracks the MN current location, e.g. AAA server.
it's also fine for me, except that the AAA Server is not a good example because it only tracks the NAS (not the user nor the MAG)

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 sems to me that the solution for a "compromised MAG" problem and for BU ordering are actually part of the same package, since solving the "compormised MAG" problem leads to the certainty of having only 1 MAG serving the user and then a SQN per MAG and per MN is sufficient (no need for context transfer)

Regards

federico

-----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:

>> 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 
>> 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:
>> Devarapalli; Kilian Weniger Cc : netlmm Objet : RE: Text Proposal for 
>> Compromised MAG issue (was [netlmm] Review
>> interested in getting this issue addressed properly and have it 
>> closed sooner than later. What about the following text:
>>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 28 Sep 2007 10:42:04 -0500

> If addressing the security concern is necessary because of 
> IESG or whatever and you're going to hint at possible 
> solutions, then I would add as an alternative that the MAG 
> may add a per-MN signature to the PBU.

[Ahmad]
This also falls under the proposed text. 
Again, AAA is given as an example nothing else. Let us forget about the AAA server for a second.

Apparently you do not have a problem with the proposed text but with listing AAA as an example. Is that right?

> it's also fine for me, except that the AAA Server is not a 
> good example because it only tracks the NAS (not the user nor the MAG)
> 
> 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 sems to me that the solution for a "compromised MAG" 
> problem and for BU ordering are actually part of the same 
> package, since solving the "compormised MAG" problem leads to 
> the certainty of having only 1 MAG serving the user and then 
> a SQN per MAG and per MN is sufficient (no need for context transfer)
> 
> Regards
> 
> federico
> 
> 
> 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 
> 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
> 
> 
> 
> 
> 
> > 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
> >
> >
> deployments 
> Proposal for

---

From: Wassim Haddad <[email-masked]>
Date: Fri, 28 Sep 2007 18:56:56 +0300 (EEST)

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. 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),
then you can simply let the LMA updates the MAG (instead of the opposite)
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...

Regards,

Wassim H.

---

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

Hi Wassim,

Please see comment below.

Regards,
Ahmad

> > 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 
> => 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:
 
[Ahmad]
So, can I read this that you think it is impossible and does not make sense?

> 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 

[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!

> vendredi 28 
> > septembre 2007 16:29 À : Ahmad Muhanna Cc : DE JUAN HUARTE 
> FEDERICO; 
> > netlmm Objet : RE: Text Proposal for Compromised MAG issue (was 
> >>> 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
> >>>
> close the 
> >>> solution space to one given solution Let's be fair here:
> >>> Devarapalli; Kilian Weniger Cc : netlmm Objet : RE: Text Proposal 
> >>> for Compromised MAG issue (was [netlmm] Review

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Fri, 28 Sep 2007 18:36:30 +0200

Hi Ahmad,

please see inline
Regards

federico 

-----Message d'origine-----
De : Ahmad Muhanna [mailto:[email-masked]] 
Envoyé : vendredi 28 septembre 2007 17:42
À : DE JUAN HUARTE FEDERICO; Sri Gundavelli
Cc : netlmm
Objet : RE: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05)

> If addressing the security concern is necessary because of IESG or 
> whatever and you're going to hint at possible solutions, then I would 
> add as an alternative that the MAG may add a per-MN signature to the 
> PBU.

[Ahmad]
This also falls under the proposed text. 
[FDJ] How does "per-MN signature added by MAG in BU" fall under the text "by contacting a trusted entity which tracks the MN current location"?
Or I didn't express myself well or I am missing something

Apparently you do not have a problem with the proposed text but with listing AAA as an example. Is that right?
[FDJ] As far as I'm concerned you can list the AAA Server as an example
I give more relevance to the fact that if one solution is hinted, that we also hint the "per-MN signature" solution

> it's also fine for me, except that the AAA Server is not a good 
> example because it only tracks the NAS (not the user nor the MAG)
> 
> Server and the AAA server is capable of tracking the location of the 
> MAG ... then do we still need timestamps for message ordering?
> problem and for BU ordering are actually part of the same package, 
> since solving the "compormised MAG" problem leads to the certainty of 
> having only 1 MAG serving the user and then a SQN per MAG and per MN 
> is sufficient (no need for context transfer)
> 
> Regards
> 
> federico
> 
> 
> 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
> 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.
> 
> 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
> 
> 
> 
> 
> 
> 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?
> >

---

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

> [FDJ] How does "per-MN signature added by MAG in BU" fall 
> under the text "by contacting a trusted entity which tracks 
> the MN current location"?

[Ahmad]
Federico,

I assume that MAG is getting that signature or the material to derive it from somewhere. Right?
In order for the LMA to validate that signature, it needs to get the needed information from somewhere too. Is there still a problem? That also does not necessarily means that LMA needs to contact a trusted entity every time it receives a P-BU for the MN. But all of this are details that we do not need to go through.

> Apparently you do not have a problem with the proposed text 
> but with listing AAA as an example. Is that right?
> [FDJ] As far as I'm concerned you can list the AAA Server as 
> an example I give more relevance to the fact that if one 
> solution is hinted, that we also hint the "per-MN signature" solution

[Ahmad]
Then why do not we list all possible hints? 
And if we have to do that, we need to get into the details of all of these proposed hints. In that case I am afraid that the issue will no longer become an out-of-scope.

Personally, I do not mind removing the AAA server hint and leave the rest of the text.

> location of the 
> JUAN HUARTE 
> can esnure 
> the work. 
> example does 
> > >>    gateway, this specification recommends that the local 
> mobility 
> > >> anchor
> > >>    gateway, this specification recommends that the local 
> mobility 
> > >> anchor

---

From: Wassim Haddad <[email-masked]>
Date: Fri, 28 Sep 2007 20:31:06 +0300 (EEST)

Hi Ahmad,

> So, can I read this that you think it is impossible and does not make sense?

=> Not at all!  Am saying that having the AAA involved to tell the LMA 
about the MN's whereabouts paves the way to provide other features.

> but I am willing to listen to your theory in a separate thread!

=> Yes sure. But let summarize it again in few words:
the AAA can tell the LMA where the MN is following a successful 
authentication, i.e., at a very early stage, which in turn enables the LMA 
to send a PBU to the MAG and updates it with what the MAG needs to know.

In the same PBU, the LMA can include a secret which can be used by the MAG 
to provide SeND features to the MN without CGA (so you don't need CGA).

> 1. A detailed solution for the so called compromised MAG is out-of-scope.

=> Agree. But from the above you can see that we don't need to create such 
problem from the beginning and then claim that it is out of scope...

> on the ml by different people.

=> which I also agree with and am trying to strech its impact on other 
features.

Wassim H.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 28 Sep 2007 12:51:15 -0500

Hi Wassim,

To be honest, the least to be said about all of this compromised MAG
discussion/issue is: May be not necessary and probably a lot of time is
wasted:-( I am sorry I misunderstood what you were trying to say
earlier, But yes, I see it much clearer now.

One more comment inline.

Cheers:)

Regards,
Ahmad

> From: Wassim Haddad [mailto:[email-masked]] 
> Sent: Friday, September 28, 2007 12:31 PM
> Cc: DE JUAN HUARTE FEDERICO; Sri Gundavelli; netlmm
> => Not at all!  Am saying that having the AAA involved to 
> tell the LMA about the MN's whereabouts paves the way to 
> provide other features.
> 
> the AAA can tell the LMA where the MN is following a 
> successful authentication, i.e., at a very early stage, which 
> in turn enables the LMA to send a PBU to the MAG and updates 
> it with what the MAG needs to know.

[Ahmad]
Very interesting!

> 
> In the same PBU, the LMA can include a secret which can be 
> used by the MAG to provide SeND features to the MN without 
> CGA (so you don't need CGA).
> 
> > [Ahmad]
> > Just FYI:
> => Agree. But from the above you can see that we don't need 
> to create such problem from the beginning and then claim that 
> it is out of scope...
> 
> => which I also agree with and am trying to strech its impact 
> on other features.
> 
> 
> Wassim H.
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 28 Sep 2007 17:02:59 -0700

All,
The text proposed by Ahmad mostly looks fine to me, although it may be
worthwhile providing a hint for how one may do it in a non-AAA based
system.  How about the following (I've taken Ahmad's text and made some
minor changes/additions): 

"To deal with threats related to a compromised mobile access gateway,
the local mobility anchor, before accepting a Proxy Binding Update
message for a given mobile node, may choose to ensure that the mobile
node is definitively attached to the   mobile access gateway that sent
the binding registration request.  This may be done by contacting a
trusted entity which tracks the MN current point of attachment, e.g. a
AAA server (as a result of an authentication exchange with the MN).
This may also be accomplished by verification of a live signature from
the MN, e.g., a CGA signature.  Details of how such verification of the
MN's point of attachment is done is outside the scope of this
specification." 

I've tried to stay away from any normative language in the text,
indicating that we are merely providing examples. 

Thanks,
Vidya

> Sent: Friday, September 28, 2007 10:51 AM
> To: Wassim Haddad
> Cc: DE JUAN HUARTE FEDERICO; netlmm
> [netlmm] Reviewofdraft-ietf-netlmm-proxymip6-05)
> 
> Hi Wassim,
> 
> To be honest, the least to be said about all of this 
> compromised MAG discussion/issue is: May be not necessary and 
> probably a lot of time is wasted:-( I am sorry I 
> misunderstood what you were trying to say earlier, But yes, I 
> see it much clearer now.
> 
> One more comment inline.
> 
> Cheers:)
> 
> Regards,
> Ahmad
>  
> 
> tell the LMA 
> > authentication, i.e., at a very early stage, which in turn 
> enables the 
> > LMA to send a PBU to the MAG and updates it with what the 
> MAG needs to 
> > know.
> 
> [Ahmad]
> Very interesting!
> 
> > 
> used by the 
> > MAG to provide SeND features to the MN without CGA (so you 
> don't need 
> > CGA).
> > 
> > > [Ahmad]
> > > Just FYI:
> to create 
> > such problem from the beginning and then claim that it is out of 
> > scope...
> > 
> > > 2. The text hint including the AAA has been proposed 
> several times 
> > > before on the ml by different people.
> >

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 28 Sep 2007 18:46:46 -0700

It looks fine, except for the CGA part. The CGA generation
requires the IPv6 subnet prefix and that the mobile node in
a Proxy Mobile IPv6 domain would not have it before the
signaling is complete. So, the mobile node would not be able
to assert the address ownership or infact even generate an
address until the MAG completes the signaling. This may work
for subsequent registrations, but not during initial attachment
in Proxy Mobile IPv6 domain. So, I suggest taking out the CGA
part and close this issue. 

Thanks Ahmad for the text.

Sri

> Sent: Friday, September 28, 2007 5:03 PM
> To: Ahmad Muhanna; Wassim Haddad
> [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05)
> 
> All,

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 29 Sep 2007 09:20:41 -0500

Sri/Vidya and All,

I believe that we need to stay away from details of how this compromised
MAG issue can be solved. The reason behind this is that, in the future,
and after a thorough investigation of this issue, the final solution may
contradict with the proposed details. Having said that I would recommend
removing all examples and keep enough informative text which does the
following:

1. Acknowledge the problem
2. Recognize that this issue is not a show stopper and can be addressed
by future work item if at all necessary.
3. Provide informative text which capture the high level indication of a
possible solution.

Based on this, I would recommend the following text:

"
   To eliminate the threats related to a compromised mobile access
   gateway, the local mobility anchor, before accepting a Proxy Binding
   Update message for a given mobile node, may ensure that the mobile
   node is definitely attached to the mobile access gateway that sent
   the proxy binding registration request. This may be accomplished by
   contacting a trusted entity which is able to track the mobile node
   current point of attachment or validate the provided mobile node
   signature.
"

Thanks.

Regards,
Ahmad

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Friday, September 28, 2007 8:47 PM
> To: 'Narayanan, Vidya'; Muhanna, Ahmad (RICH1:2H10); 'Wassim Haddad'
> Cc: 'DE JUAN HUARTE FEDERICO'; 'netlmm'
> requires the IPv6 subnet prefix and that the mobile node in a 
> Proxy Mobile IPv6 domain would not have it before the 
> for subsequent registrations, but not during initial 
> attachment in Proxy Mobile IPv6 domain. So, I suggest taking 
> out the CGA part and close this issue. 
> 
> > system.  How about the following (I've taken Ahmad's text and made 
> > some minor changes/additions):
> > 
> > the MN, e.g., a CGA signature.  Details of how such verification of 
> > the MN's point of attachment is done is outside the scope of this 
> > specification."
> > 
> compromised MAG 
> > > discussion/issue is: May be not necessary and probably a 
> lot of time 
> > > is wasted:-( I am sorry I misunderstood what you were 
> trying to say 
> > > > >> then you can simply let the LMA updates the MAG 
> (instead of the
> > > > >> opposite)
> > > >

---

From: Wassim Haddad <[email-masked]>
Date: Sat, 29 Sep 2007 17:47:09 +0300 (EEST)

Hi Ahmad,

Looks fine to me. Hopefully in the future, "another" final solution will
mitigate/eliminate the attack itself!

Thanks,
Wassim H.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sat, 29 Sep 2007 09:08:00 -0700

Hi Ahmad,
This text is fine with me. I'd still like to explicitly state the actual
mechanisms are out of scope.  One more minor nit in the text:
s/eliminate the threat/deal with the threat - I don't believe we are
eliminating the threat itself.. We are talking about mitigating the
impact of the threat. 

Thanks,
Vidya

> Sent: Saturday, September 29, 2007 7:21 AM
> To: Sri Gundavelli; Narayanan, Vidya; Wassim Haddad
> I believe that we need to stay away from details of how this 
> compromised MAG issue can be solved. The reason behind this 
> is that, in the future, and after a thorough investigation of 
> this issue, the final solution may contradict with the 
> proposed details. Having said that I would recommend removing 
> all examples and keep enough informative text which does the
> following:
> 
> 2. Recognize that this issue is not a show stopper and can be 
> addressed by future work item if at all necessary.
> 3. Provide informative text which capture the high level 
> indication of a possible solution.
> 
> > It looks fine, except for the CGA part. The CGA generation requires 
> > the IPv6 subnet prefix and that the mobile node in a Proxy 
> Mobile IPv6 
> > domain would not have it before the signaling is complete. So, the 
> > mobile node would not be able to assert the address ownership or 
> > infact even generate an address until the MAG completes the 
> signaling. 
> > This may work for subsequent registrations, but not during initial 
> > attachment in Proxy Mobile IPv6 domain. So, I suggest 
> taking out the 
> > CGA part and close this issue.
> > 
> successful

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 29 Sep 2007 11:45:34 -0500

Hi Vidya,

I do not see any problem in an explicit out-of-scope text. Here is the
updated text:

"
   To address the threat related to a compromised mobile access gateway,
   the local mobility anchor, before accepting a Proxy Binding Update
   message for a given mobile node, may ensure that the mobile node is
   definitely attached to the mobile access gateway that sent the proxy
   binding registration request.  This may be accomplished by contacting
   a trusted entity which is able to track the mobile node current point
   of attachment or validate the provided mobile node signature.
   However, the details of actual mechanisms are out of scope.
"

Regards,
Ahmad

> Sent: Saturday, September 29, 2007 11:08 AM
> To: Muhanna, Ahmad (RICH1:2H10); Sri Gundavelli; Wassim Haddad
> This text is fine with me. I'd still like to explicitly state 
> the actual mechanisms are out of scope.  One more minor nit 
> in the text:
> s/eliminate the threat/deal with the threat - I don't believe 
> we are eliminating the threat itself.. We are talking about 
> mitigating the impact of the threat. 
> 
> Thanks,
> Vidya
> 
> is that, 
> > in the future, and after a thorough investigation of this 
> issue, the 
> > final solution may contradict with the proposed details. 
> Having said 
> > that I would recommend removing all examples and keep enough 
> > informative text which does the
> > following:
> > 
> > > > > > > 1. A detailed solution for the so called 
> compromised MAG is
> > > > > > out-of-scope.
> > > > > >

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sat, 29 Sep 2007 10:12:04 -0700

Thanks, Ahmad. 

Regards,
Vidya 

> Sent: Saturday, September 29, 2007 9:46 AM
> To: Narayanan, Vidya; Sri Gundavelli; Wassim Haddad
> I do not see any problem in an explicit out-of-scope text. 
> Here is the updated text:
> 
> "
> > This text is fine with me. I'd still like to explicitly state the 
> > actual mechanisms are out of scope.  One more minor nit in the text: