Subject: [netlmm] Trust models

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 2 Nov 2006 04:55:17 -0800

Henrik, 

Please see my response below, I changed the subject to a more
appropriate one. 

 > I'm concerned not with the specifics of a proposed solution here, but
 > with the fundamental difference between what an AR in a 
 > visited network
 > may be permitted to do on behalf of an MN, and what the MN 
 > may do using
 > its own credentials.

=> Yes I understood what you mean I think. So let's forget about the
particular protocol for now and discuss the trust model. I think that
the trust model we can apply to a netlmm protocol is one where an AR is
trusted (when it provides certain credentials) to route or re-route the
node's traffic. This is not that different from the trust model used to
secure routing protcols, right? I'm not talking about the actual
mechanisms used to secure the communication, but just the trust model.
Essentially it says "if you can prove to me that you're a one of the
trusted routers, I'll accept your request". 

Now, with MIPv6, the local anchor (HA, MAP) would need to apply a
similar model. Essentially it would mean that if an AR can show that it
is authorised to send a BU (not specific to the particular HoA or CoA in
the BU), then, barring any of the usual errors in processing, the BU
would be accepted.

So, if you agree with the above then the question becomes: How can MIPv6
work in this way without breaking the current spec? 

Hesham

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sun, 5 Nov 2006 01:33:31 -0800

Hi Hesham, Henrik
The trust models are definitely different between host and network-based
mobility. However, I disagree with Henrik in that it causes a huge
change to MIP6. Given that MIP6 uses IPsec, it is a matter of specifying
the SPD entries appropriately to allow an AR-HA SA. The MIP6
implementation pretty much has no impact from a security perspective. 

Regards,
Vidya

> -----Original Message-----
> From: Soliman, Hesham [mailto:[email-masked]] 
> Sent: Thursday, November 02, 2006 4:55 AM
> To: Henrik Levkowetz
> Cc: [email-masked]
> Subject: [netlmm] Trust models
> 
> Henrik, 
> 
>  > I'm concerned not with the specifics of a proposed 
> solution here, but  > with the fundamental difference between 
> what an AR in a  > visited network  > may be permitted to do 
> on behalf of an MN, and what the MN  > may do using  > its 
> own credentials.
> 
> => Yes I understood what you mean I think. So let's forget 
> about the particular protocol for now and discuss the trust 
> model. I think that the trust model we can apply to a netlmm 
> protocol is one where an AR is trusted (when it provides 
> certain credentials) to route or re-route the node's traffic. 
> This is not that different from the trust model used to 
> secure routing protcols, right? I'm not talking about the 
> actual mechanisms used to secure the communication, but just 
> the trust model.
> Essentially it says "if you can prove to me that you're a one 
> of the trusted routers, I'll accept your request". 
> 
> Now, with MIPv6, the local anchor (HA, MAP) would need to 
> apply a similar model. Essentially it would mean that if an 
> AR can show that it is authorised to send a BU (not specific 
> to the particular HoA or CoA in the BU), then, barring any of 
> the usual errors in processing, the BU would be accepted.
> 
> So, if you agree with the above then the question becomes: 
> How can MIPv6 work in this way without breaking the current spec? 
> 
> 
> Hesham
>

---

From: Katsutoshi Nishida <[email-masked]>
Date: Mon, 06 Nov 2006 15:01:12 +0900

Hi,

Regarding the trust model, I think the additional functionality shall be
supported within a scope of PMIP protocol in order to be able to reuse
MIPv6 specified home agent. 

This means ARs would need to share or forward IPSec security credentials
specific to the MN in order to support handover with minimum delay.
Without having this function, new AR needs to re-negotiate SA with HA
and would result in slow handover.

Although this is not a PMIP specific issue, considering the reuse of HA,
ARs of PMIP shall provide credential sharing method on top of MIP
registration function, i.e. BU/BA. This seems some level of impact
occurs in the context of protocol modification from MIP, I think.

Katsutoshi

On Sun, 05 Nov 2006 01:33:31 -0800

> > How can MIPv6 work in this way without breaking the current spec? 

Regards,
Katsutoshi

---

From: "Soliman, Hesham" <[email-masked]>
Date: Sun, 5 Nov 2006 22:12:00 -0800

> and would result in slow handover.

=> Not at all. I think you're assuming a per-mobile SA. My email talked
about the same trust model as routing protocols, i.e. aggregate trust.
So you don't need to transfer credentials between ARs.

Hesham

---

From: Katsutoshi Nishida <[email-masked]>
Date: Mon, 06 Nov 2006 16:27:54 +0900

Hi Hesham,

Thanks for your answer.
Please see my comment below.

On Sun, 05 Nov 2006 22:12:00 -0800

> So you don't need to transfer credentials between ARs.

So, is that allowed by current MIPv6 HA? 

It seems you are saying MIPv6 specified IPSec is turned off and different
type of IPSec per AR-HA is employed. Is this right understanding? 

I am just wondering how much impact on MIPv6 HA would required and if
such modified HA can serve for both MIP terminals and PMIP ARs as some
people seems to have a single HA for both scenarios.

Katsutoshi

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 6 Nov 2006 10:05:37 -0800 (PST)

Hi Katsutoshi,

> people seems to have a single HA for both scenarios.

The changes are specific to the checks related to the usage of a specific
SA for protecting a BU with a given home address. That is a minor logic
change for supporting PMIP trust model. The changes are simple extensions
to the home agent and it will not result in two variants of home agents.

Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 06 Nov 2006 20:14:08 +0100

Sri Gundavelli wrote:
>> I am just wondering how much impact on MIPv6 HA would required and 
>> if such modified HA can serve for both MIP terminals and PMIP ARs 
>> as some people seems to have a single HA for both scenarios.
>> 
> 
> The changes are specific to the checks related to the usage of a 
> specific SA for protecting a BU with a given home address. That is a 
> minor logic change for supporting PMIP trust model. The changes are 
> simple extensions to the home agent and it will not result in two 
> variants of home agents.

Not sure about AR-HA security being enough for MN, in MIP6 terms.
Securing a BU between AR and HA doesn't prevent an MN attack another MN
(instructing AR to send a BU for the victim).  This attack is not
possible with MIP6 but seems to become possible with PMIP6.

To avoid it it would require more checks at HA, I think.

Alex

---

From: "Mohamed Khalil" <[email-masked]>
Date: Mon, 6 Nov 2006 14:20:59 -0600

Hi Alexandru,

The triggers for AR to send a BU are L2 messages which usually have L2
security. The L2 security is very common in nowadays wireless techs.

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 1:14 PM
To: Sri Gundavelli
Cc: [email-masked]; Soliman, Hesham
Subject: Re: [netlmm] Trust models

Alex

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 6 Nov 2006 14:18:05 -0800 (PST)

Hi Alex,

> possible with MIP6 but seems to become possible with PMIP6.

In PMIP, the BU signalling is triggered after the access
authentication and so the host is not involved other than
authenticating itself to the network. So, I do not think
such attack is possible in PMIP. PMIP is riding on the
access authentication and that allows the access router
to predictably identify the mobile and signal the home
agent on its behalf.

Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 06 Nov 2006 23:28:14 +0100

Mohamed Khalil wrote:
> Hi Alexandru,
> 
> The triggers for AR to send a BU are L2 messages which usually have 
> L2 security. The L2 security is very common in nowadays wireless 
> techs.

I'm sure they do.  One may wonder then why one needs IPsec between MN
and HA at all (MIP6) and between AR and HA (PMIP6).  What does that
IPsec protect against?

Alex

> 
> -----Original Message----- From: Alexandru Petrescu 
> [mailto:[email-masked]] Sent: Monday, November 06, 
> 2006 1:14 PM To: Sri Gundavelli Cc: [email-masked]; Soliman, Hesham 
>>> I am just wondering how much impact on MIPv6 HA would required 
>>> and if such modified HA can serve for both MIP terminals and PMIP
>>>  ARs as some people seems to have a single HA for both scenarios.
>>> 
>>> 
>>> 
>> specific SA for protecting a BU with a given home address. That is
>>  a minor logic change for supporting PMIP trust model. The changes
>>  are simple extensions to the home agent and it will not result in
>>  two variants of home agents.
> 
> Securing a BU between AR and HA doesn't prevent an MN attack another
>  MN (instructing AR to send a BU for the victim).  This attack is not
> _______________________________________________ netlmm mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 06 Nov 2006 23:35:55 +0100

Sri Gundavelli wrote:
>>>> and
>>> if >  such modified HA can serve for both MIP terminals and PMIP
>>> ARs as some >  people seems to have a single HA for both
>>> scenarios.
>>>> 
>>> 
>>>  specific SA for protecting a BU with a given home address. That
>>> is a minor logic change for supporting PMIP trust model. The
>>> changes are simple extensions to the home agent and it will not
>>> result in two variants of home agents.
>> 
>> Securing a BU between AR and HA doesn't prevent an MN attack
>> another MN (instructing AR to send a BU for the victim).  This
>> attack is not possible with MIP6 but seems to become possible with
>> PMIP6.
>> 
> 
> authenticating itself to the network.

So the security of PMIP6 relies not only on security of MIP6 but also on
proper AAA interaction?

Remark in the case of MIP6 the protocol is inherently secure, no need of
external security support (be it l2 security, or AAA).

Alex

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 6 Nov 2006 14:53:10 -0800

> authenticating itself to the network. So, I do not think such 
> attack is possible in PMIP. PMIP is riding on the access 
> authentication and that allows the access router to 
> predictably identify the mobile and signal the home agent on 
> its behalf.
> 

You are assuming here that there is a *tie* between the L2 security of
an MN to it's IP address. There isn't. For instance, there is no binding
whatsoever between the L2 keys and an IP address. So, it does not
prevent an authenticated MN from using an invalid IP address. 

However, that is the leap that network-based mobility is making. And,
there may some complicated ways of providing "some" protection against
such things, but nothing simple or practical that I can think about. 

Vidya

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 6 Nov 2006 15:06:21 -0800 (PST)

> such things, but nothing simple or practical that I can think about.

The coupling is with the mobile's identity in the form of NAI.
The authentication is coupled to the NAI and that is used by
the network/AR to obtain the mobile's profile from the policy
store and identify the home address. So, the AR will not trigger
BU's for "any" home address that the mobile uses. There is a
proper check there.

This layered architecture of access security and bootstrapping
the mobility from it, provides the required security.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 6 Nov 2006 15:08:17 -0800 (PST)

Hi Alex,

On Mon, 6 Nov 2006, Alexandru Petrescu wrote:

>>  In PMIP, the BU signalling is triggered after the access authentication
>>  and so the host is not involved other than authenticating itself to the
>>  network.
>

It relies on the access security.

> external security support (be it l2 security, or AAA).

Model is different and the proxy model requires it. If we want host
to host secutity, we need to involve the host in the signalling
and that we want to avoid that.

Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 6 Nov 2006 15:50:45 -0800

> store and identify the home address. So, the AR will not 
> trigger BU's for "any" home address that the mobile uses. 
> There is a proper check there.
> 
> This layered architecture of access security and 
> bootstrapping the mobility from it, provides the required security.
> 

I am not sure I understand. Network access control works because there
is a way to enforce it on a per-packet basis - i.e., every packet must
be protected with a valid SA. This enforcement is at the NAS level. The
NAS, however, does not check whether the appropriately protected
incoming packet has a particular IP address. So, while the HA/LMA, from
the tie to the NAI, may know that a given NAI is tied to a given
address, there is no way of verifying that a given packet sent from an
MN is in fact, in compliance with that. Since the NAI is not a
per-packet identifier, I actually don't see how this can be verified, by
the NAS or by the HA/LMA. Not to mention that there are no ties between
the AR and NAS and these could be different entities. 

What am I missing here? 

Vidya

---

From: Julien Laganier <[email-masked]>
Date: Mon, 6 Nov 2006 16:23:15 -0800

Hi Vidya,

Some thoughts below,

On Monday 06 November 2006 15:50, Narayanan, Vidya 
wrote:
> > The coupling is with the mobile's identity in the
> > form of NAI. The authentication is coupled to the
> > NAI and that is used by the network/AR to obtain
> > the mobile's profile from the policy store and
> > identify the home address. So, the AR will not
> > trigger BU's for "any" home address that the
> > mobile uses. There is a proper check there.
> >
> I am not sure I understand. Network access control
> works because there is a way to enforce it on a
> per-packet basis - i.e., every packet must be
> protected with a valid SA. 

Why? That would be a protection about IP spoofing, this 
is a different issue. I think what we're concerned 
about is the security of the *triggering* of PMIP, and 
that's somewhat unrelated to the IP address of the MN. 

More below:

> This enforcement is at 
> the NAS level. The NAS, however, does not check
> whether the appropriately protected incoming packet
> has a particular IP address. So, while the HA/LMA,
> from the tie to the NAI, may know that a given NAI
> is tied to a given address, there is no way of
> verifying that a given packet sent from an MN is in
> fact, in compliance with that. Since the NAI is not
> a per-packet identifier, I actually don't see how
> this can be verified, by the NAS or by the HA/LMA.

AFAICS, the triggering can be based on a NAI verified 
at the NAS, and the LMA would update routing for the 
IP addresses bound to that NAI. The NAS doesn't need 
to deal with IP addresses per se.

> Not to mention that there are no ties between the AR
> and NAS and these could be different entities.

Agree that for that to work NAS and AR would need to be 
collocated, or at least be interfaced.

Best,

--julien

---

From: Julien Laganier <[email-masked]>
Date: Mon, 6 Nov 2006 16:07:09 -0800

On Monday 06 November 2006 14:35, Alexandru Petrescu 
wrote:
> >>> if >  such modified HA can serve for both MIP
> >>> terminals and PMIP ARs as some >  people seems
> >>> to have a single HA for both scenarios.
> >>>
> >>>
> >>> The changes are specific to the checks related
> >>> to the usage of a specific SA for protecting a
> >>> BU with a given home address. That is a minor
> >>> logic change for supporting PMIP trust model.
> >>> The changes are simple extensions to the home
> >>> agent and it will not result in two variants of
> >>> home agents.
> >>
> >> Not sure about AR-HA security being enough for
> >> MN, in MIP6 terms. Securing a BU between AR and
> >> HA doesn't prevent an MN attack another MN
> >> (instructing AR to send a BU for the victim). 
> >> This attack is not possible with MIP6 but seems
> >> to become possible with PMIP6.
> >
> > In PMIP, the BU signalling is triggered after the
> > access authentication and so the host is not
> > involved other than authenticating itself to the
> > network.
>
> So the security of PMIP6 relies not only on security
> of MIP6 but also on proper AAA interaction?

AFAICS, when no AAA or L2 sec is present, secure PMIP 
triggering could also be achieved as proposed for the 
NetLMM MN-AR interface [1]: use the SEND public key as 
an identifier for the MN, and verifies SEND signatures 
included in DNA's RS sent by the MN. If signature is 
correct, trigger PMIP.

--julien

[1] draft-ietf-netlmm-mn-ar-if 
<http://www.ietf.org/internet-drafts/draft-ietf-netlmm-mn-ar-if-01.txt>

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 6 Nov 2006 17:00:39 -0800 (PST)

> the AR and NAS and these could be different entities.

We do look at the source IP address of the packet for routing it to
the mobile's home agent over the right tunnel. We do that in MIPv4
and we do that here. That is a simple route setup based on source
address.

The MN-AR link is typically a p2p link, by the current assumption
by PMIP. The mobile is on that link after the access authentication
and no other node can be on on that p2p link.

There are many ways to ensure only the authenticated mobile is
sending packets using a given home address/MAC address. That is
part of the access control on that access link. This is more L2
security.

Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 6 Nov 2006 19:21:51 -0800

> 
> We do look at the source IP address of the packet for routing 
> it to the mobile's home agent over the right tunnel. We do 
> that in MIPv4 and we do that here. That is a simple route 
> setup based on source address.
> 

But, this is not about routing the packet over the right tunnel. It is
about "how does the HA know that the MN is claiming the correct HoA?"
Doing it in host-based mobility is in fact, viable, since the signaling
endpoint is the same as the entity that owns the IP address and the SA
can be tied to that HoA. In network-based mobility, I can't understand
how this can be done in any trivial fashion. 

> The MN-AR link is typically a p2p link, by the current 
> assumption by PMIP. The mobile is on that link after the 
> access authentication and no other node can be on on that p2p link.
> 

Until that model is attacked :) In other words, there is no
cryptographic relationship between the link and network layers. Also, at
least in PPP, the address assignment is part of the protocol. In other
models, that is not essentially the case. So, the link being a p2p link
does not prevent an attacker from spoofing the IP address on that link.
It is just that someone would equally have to spoof the corresponding
link layer ID and that is not difficult to do. 

> There are many ways to ensure only the authenticated mobile 
> is sending packets using a given home address/MAC address. 
> That is part of the access control on that access link. This 
> is more L2 security.

Not exactly. MIP allows you to ensure that the packets being sent are
sent from a given HoA, because the IPsec SA is tied to that HoA. In the
case of network-based mobility, there is no such SA. You are taking the
word of the AR that the owner of a particular HoA is in fact on that
link. 

So, two parts to the "authorization" aspect in network-based mobility: 

1. Is the AR authorized to perform network-based mobility at that
LMA/HA? Having an SA between every authorized AR and the LMA/HA allows
this to be performed. 

2. Is the MN actually present at that AR, i.e., is that AR authorized to
perform an update for a particular MN? This is much harder to achieve. 

The problem of "is the MN itself claiming the correct IP address?"
cannot be solved without an SA tied to that IP address (or using
something like CGAs). 

Thoughts? 

Vidya

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 6 Nov 2006 23:06:19 -0800 (PST)

> how this can be done in any trivial fashion.

Access authentication on any wireless link, ensures  node with a
given MAC address and IP address is authorised to use the link.
That relation is bound to the cryptographic state. In the PMIP
scenario, while reverse tunneling the packets to the home,
the AR will ensure the node with the right MAC/IP is sending
the packets on the tunnel to home. All of this argument is not
required, when I say there is a p2p link that is assumed between
MN and AR. Now, I cannot argue with you, if you say p2p link,
means more than 2 nodes on the link. There is a layer-2 state
that ties the session-id, MAC and IP. If you say, this is not
secure, lets identify the threats and discuss in whole in the
context of PMIP deployment scenarios and the base assumptions
that the protocol does. Bottom line, as stated in the security
section of the draft, PMIP does not deal with access authentication
and it further assumes there is proper protocols in place that
ensures a given authorized node with a specific MAC/IP address
is using the link. I do not want to mix these two layers and
build a protocol, just as MIPv6 and IPSec are decoupled.

Sri

---

From: "Mohamed Khalil" <[email-masked]>
Date: Tue, 7 Nov 2006 09:13:38 -0600

Hi Alex,

The point I was trying to say is that the triggering of the handoff or
the connection setup of the AT should be controlled and secured at L2.
PMIP is not involved in this process. The IPSec is used to secure the
traffic and signals at L3 and above.

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 4:28 PM
To: Khalil, Mohamed (RICH2:2S20)
Cc: Sri Gundavelli; [email-masked]; Soliman, Hesham
Subject: Re: [netlmm] Trust models

Alex

---

From: "James Kempf" <[email-masked]>
Date: Tue, 7 Nov 2006 07:40:55 -0800

Sri,

The threats are already identified. They are described in the NETLMM threats 
draft:

http://www.ietf.org/internet-drafts/draft-ietf-netlmm-threats-04.txt

This draft has gone through two rounds of WGLC and is now with the IESG for 
publication as an informational RFC.

I suggest you read that and use it as a guide in addressing the threats to 
PMIP. I don't think there are really any significant differences.

            jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 07 Nov 2006 16:26:12 +0100

Mohamed Khalil wrote:
> Hi Alex,
> 
> The point I was trying to say is that the triggering of the handoff
> or the connection setup of the AT should be controlled and secured
> at L2. PMIP is not involved in this process. The IPSec is used to
> secure the traffic and signals at L3 and above.

Hi Mohamed - yes I understand there's need of a trigger.   The AR
needs MN's profile and that's obtained by AAA.  Without that profile
the AR doesn't know where and what prefix to put.

I think it is good to stay independent of the choice of the trigger
(AAA, DHCP, ND - other).

Alex

> 2006 4:28 PM To: Khalil, Mohamed (RICH2:2S20) Cc: Sri Gundavelli;
> [email-masked]; Soliman, Hesham Subject: Re: [netlmm] Trust models
> 
> 
> 
> Mohamed Khalil wrote:
>> Hi Alexandru,
>> 
>> The triggers for AR to send a BU are L2 messages which usually
>> have L2 security. The L2 security is very common in nowadays
>> wireless techs.
> 
> I'm sure they do.  One may wonder then why one needs IPsec between
> MN and HA at all (MIP6) and between AR and HA (PMIP6).  What does
> that IPsec protect against?
> 
> Alex
> 
> 
>> [mailto:[email-masked]] Sent: Monday, November
>> 06, 2006 1:14 PM To: Sri Gundavelli Cc: [email-masked]; Soliman,
>> Hesham Subject: Re: [netlmm] Trust models
>> 
>> 
>> Sri Gundavelli wrote:
>>> Hi Katsutoshi,
>>> 
>>>> I am just wondering how much impact on MIPv6 HA would
>>>> required and if such modified HA can serve for both MIP
>>>> terminals and PMIP ARs as some people seems to have a single
>>>> HA for both scenarios.
>>>> 
>>>> 
>>>> 
>>> The changes are specific to the checks related to the usage of
>>> a specific SA for protecting a BU with a given home address.
>>> That is a minor logic change for supporting PMIP trust model.
>>> The changes are simple extensions to the home agent and it will
>>> not result in two variants of home agents.
>> attack is not possible with MIP6 but seems to become possible
>> with PMIP6.
>> 
>> _______________________________________________ netlmm mailing
>> list [email-masked]

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 7 Nov 2006 11:58:04 -0800 (PST)

Thanks James. We will take a look at this and see
what are applicable to PMIP.

Regards
Sri

On Tue, 7 Nov 2006, James Kempf wrote:

> ----- Original Message ----- From: "Sri Gundavelli" <[email-masked]>