Subject: [netlmm] Security comments about draft-sgundave-mipv6-proxymipv6-00

From: "Jean-Michel Combes" <[email-masked]>
Date: Fri, 8 Dec 2006 16:17:12 +0100

Hi,

I've read the draft PMIP (i.e. draft-sgundave-mipv6-proxymipv6-00)
and, IMHO, there are critical security issues. So I would like to have
confirmation on these issues that are so critical that I have doubts
about my analysis ...

At first, my analysis is only focused on the security of the signaling
between PMAs and the HA. This one is based on IPsec like MIPv6.

In the following, the new PMA is noted PMAn and the previous one PMAp

Issue #1 - Security material (e.g. certs, pre-shared keys, etc.)
To be compliant with the information in the HA's PAD about a specific
MN, all the PMAs must share the same security material regarding this
same specific MN.
Such an assumption is not acceptable from a security point of view.

Issue #2 - IPsec SAs management (manual SAs)
All the PMAs must share the same SAs, regarding a specific MN, with the HA.

Issue #3 - IPsec SAs management (dynamic SAs)
Here, there are 2 cases:
(a) One couple of SAs, regarding a specific MN, in only one PMA at the
same time.
In this case, how can the PMAn have the right SAs from the PMAp?
BTW, a re-negotiation of IPsec SAs is not possible between the HA and
the PMAn, because this one is not aware of the IKE_SA previously
negotiated by the PMAp with HA.
(b) All the PMAs must share the same SAs at the same time, regarding a
specific MN, with the HA
In this case, which mechanism is used to synchronize the SAs?

Issue #4 - MIPv6/PMIPv6 HA (i.e. the same HA manages MIPv6 and PMIPv6)
In this case, Issue #1 becomes critical: a same security material is
shared all the PMAs, the MN and the HA. That means, in the case where
a PMA is compromised, this one may impact PMIP service as well as
MIPv6 service!!!

Please, don't hesitate to correct me if I am wrong and I missed
something in the draft :)

Thanks in advance.

Best regards.

JMC.

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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Dec 2006 08:50:09 -0800

>In this case, which mechanism is used to synchronize the SAs?

IPsec doesn't support this currently, but how about a group key?

            jak

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 8 Dec 2006 10:31:52 -0800 (PST)

Hi Jean,

> Such an assumption is not acceptable from a security point of view.

There is no such assumption. All the PMA's in the proxy domain
are not required to share the same security credentials. Trust is
still between two entities, PMA and the HA. The solution adapts
a security model that is suited for this proxy mode of operation.
Note that the mobile is not involved in any signalling, it does
not have any mobility state and so the MN's security is not in the
picture. There is a special node in the network, Proxy Mobile Agent
that seeks mobility for certain nodes and so the security is between
these two entities. Home Agent has to ensure, the node that is
sending proxy registrations has the right security privileges and
if it is authorized to do so. Referring to NEMO model, the home agent
creates a routing state for a prefix, on the request from a
mobile router. It is possible that prefix belongs to some other
mobile router, but the home agent has to authorize that request
and create a routing state. Same thing here, in the context of
security. The home agent knows certain entities that have privileges
to request certain services. The special entities here are the
PMA's and the service is the mobility service for a mobile node.

> All the PMAs must share the same SAs, regarding a specific MN, with the HA.

No. See above.

> In this case, which mechanism is used to synchronize the SAs?

No. See above.

> shared all the PMAs, the MN and the HA. That means, in the case where

No. See above.

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Fri, 8 Dec 2006 20:06:22 +0100

Hi Sri,

> PMA's and the service is the mobility service for a mobile node.

So, how does look like SPD/SAD/PAD in the HA/PMAp/PMAn? Specially,
what IDs are used to generate the SAs?

[snip]

Thanks.

Best regards.

JMC.

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 11 Dec 2006 18:01:44 -0800

> what IDs are used to generate the SAs?

The IPsec SA will be between the PMA and the HA.
The IDi will be set to the PMA's identity.

PAD typically ties the key negotiation protocol
like IKEv2 to the IPsec SA. Since the IKEv2 end
points are the PMA and the HA and the IPsec SA
is also created between these two, there is only
one PAD entry at the HA per PMA. no per-MN PAD
entry.

We can discuss and add the SPD/PAD/SAD entries
if needed to the PMIPv6 draft.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 11 Dec 2006 19:02:20 -0800

Hi Jean,

> what IDs are used to generate the SAs?

Sorry. I missed your follow up note.

Adding to Vijay's response...

The IPSec peering is between the home agent and the Access Router
with their respective identities for the peer authorization. We
are working on updating the draft with all the details covering the
security aspects. We plan to submit it very soon.

Regards
Sri

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 12 Dec 2006 04:41:05 +0100

Hi Vijay,

Thanks for your reply.

At first, I must admit I missed one point: I didn't see that the NAI
option is used in your proposal (BTW, please add the RFC 4283 in the
references ;). But this point has not consequences my previous mails.

Now, I still don't understand some points ... :s

Explanations:
o Knowing that the draft specifies that a Proxy-BU MH is only a MIPv6
BU with a "P Flag" in the BU MH (cf. section 4.1 of the draft)
o Knowing that the RFC 3775 specifies that a BU packet must contain a
Home Address option (cf. section 11.7.1 of the RFC 3775)
o Knowing that the Binding Cache in the HA is the same as a classical
HA' s MIPv6 Binding Cache, with optionally a P flag (cf. section 5.1
of the draft)

So for me, if a PMA wants to send a P-BU for a specific Mobile Station
(MS), this one looks like (cf. RFC 3776) a "fake" MS' BU:
IPv6 header (source = PMA's egress interface IP address,
                   destination = HA's IP address)
      Destination Options header
         Home Address option (Mobile Station's IP address)
      ESP header in transport mode
      Mobility header
         Binding Update
            NAI option (Mobile Station's NAI)
            Alternate Care-of Address option (PMA's egress interface IP address)

(BTW, I don't understand why you need to add the NAI MH option for the P-BU)

So, the IPsec configuration will need to be based on the Mobile
Station's IP address as specified in the RFC 3776 (and
draft-ietf-mip6-ikev2-ipsec for IKEv2).
So, I don't still understand how can you base the IPsec policy on the
LMA and so avoid the issues I've listed ...

Best regards.

JMC.

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 12 Dec 2006 04:51:28 +0100

Hi Sri,

> Hi Jean,

s/Jean/Jean-Michel ;)

> Adding to Vijay's response...

I've already replied to its email :)

> with their respective identities for the peer authorization.

But as far as I understand your proposal, the principle of your
mechanism is to "spoof" the Mobile Station's BU (my basic summary of
your proposal :). So clearly for me, the BU (i.e. P-BU) looks like to
a BU sent by the MS but in fact sent by the LMA and so the IPsec
policy is based on the MS's HoA and not the LMA's IP address.

>  We

Clearly, precisions are needed (e.g. how does look like the P-BU
packet? Which IP addresses are used? etc.) :)

Best regards.

JMC.

---

From: "Kumar Vinod-A20689" <[email-masked]>
Date: Tue, 12 Dec 2006 12:02:59 +0800

Hi All,
 
According to draft-sgundave-mipv6-proxymipv6-00, there is a special node
in the network, Proxy Mobile Agent that seeks mobility for certain
nodes. In my opinion, it would be more precise if it is explicitly
specified that at any given time, we have one Proxy Mobile Agent (PMA)
functionality for a given MN inside the local mobility domain. As a
result, only this PMA function needs to have an SA with the HA as far as
this MN is concerned. In addition, this PMA need not be collocated with
the ARs and can be a stand-alone entity. Whenever the MN moves between
ARs inside the LMD, the same PMA will send the PBU to the local mobility
anchor (LMA). The LMA just needs to be aware that it has a SA with a PMA
that is authorized to send PBUs for a specific set of (one or more) MNs.
 
A similar idea has been proposed in draft-singh-netlmm-protocol-00.txt. 
(http://www.ietf.org/internet-drafts/draft-singh-netlmm-protocol-00.txt)
. 
 
Any comments?

Regards,
Vinod  

-----Original Message-----
From: Jean-Michel Combes [mailto:[email-masked]] 
Sent: Tuesday, December 12, 2006 9:21 AM
To: Sri Gundavelli
Cc: [email-masked]
Subject: Re: [netlmm] Security comments
aboutdraft-sgundave-mipv6-proxymipv6-00

Hi Sri,

s/Jean/Jean-Michel ;)

> >> There is no such assumption. All the PMA's in the proxy domain are 
> >> not required to share the same security credentials. Trust is still

> >> between two entities, PMA and the HA. The solution adapts a 
> >> security model that is suited for this proxy mode of operation.
> >> Note that the mobile is not involved in any signalling, it does not

> >> have any mobility state and so the MN's security is not in the 

> >> that seeks mobility for certain nodes and so the security is 
> >> between these two entities. Home Agent has to ensure, the node that

> >> is sending proxy registrations has the right security privileges 
> >> and if it is authorized to do so. Referring to NEMO model, the home

> >> agent creates a routing state for a prefix, on the request from a 
> >> mobile router, but the home agent has to authorize that request and

> >> create a routing state. Same thing here, in the context of 
> >> security. The home agent knows certain entities that have 
> >> privileges to request certain services. The special entities here 
> >> are the PMA's and the service is the mobility service for a mobile
node.

>
> The IPSec peering is between the home agent and the Access Router with

> their respective identities for the peer authorization.

But as far as I understand your proposal, the principle of your
mechanism is to "spoof" the Mobile Station's BU (my basic summary of
your proposal :). So clearly for me, the BU (i.e. P-BU) looks like to a
BU sent by the MS but in fact sent by the LMA and so the IPsec policy is
based on the MS's HoA and not the LMA's IP address.

> security aspects. We plan to submit it very soon.

Clearly, precisions are needed (e.g. how does look like the P-BU packet?
Which IP addresses are used? etc.) :)

Best regards.

JMC.

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 12 Dec 2006 05:10:41 +0100

Hi Kumar,

At first I didn't read the draft raft-singh-netlmm-protocol-00.txt.

> that is authorized to send PBUs for a specific set of (one or more) MNs.

What, in a technical point of view (i.e. PAD/SAD/SPD), does
"authorized" term mean if your security is based on IPsec?

Best regards.

JMC.

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 11 Dec 2006 20:17:15 -0800 (PST)

Hi Jean,

Please see inline ..

> Home Address option (cf. section 11.7.1 of the RFC 3775)

Good question. We discussed about this earlier and we decided
to relax this for PBU operations. The PBU message will not
have  a HoA, but instead we will have a new home address
mobility option.

> LMA and so avoid the issues I've listed ...

The HA will index the IPSec SA using the CoA. Since, there is no
HoA in the mobility message, the SA look up will be based on COA.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 11 Dec 2006 20:25:55 -0800 (PST)

Hi Jean-Michel,

> 2006/12/12, Sri Gundavelli <[email-masked]>:

Sorry !

> policy is based on the MS's HoA and not the LMA's IP address.

The principal of the proposal is not exactly to spoof the BU,
but to create a model where the home agent accepts proxy BU
messages. The AR sends the proxy messages with its own identity
and on behalf of a mobile and the home agent clearly knows the
message is from a proxy node and it knows how to index the IPSec
SA correctly. The IPSec SA indexing by both the peers is just
as in  regular non-mobile IP scenario. We drop the HoA option
and add a home address mobility option.

Regards
Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 11 Dec 2006 20:59:00 -0800

hi Jean-Michel,

Let me reply to the question about why the Mobile
Node Identifier Option (RFC 4283) is needed.

First of all RFC 4383 does not mean 4285 is used. :)
RFC 4283 introduces an option that can carry a mobile
node's identity. It can be used with any Mobile IPv6
extension.

In draft-ietf-mip6-ikev2-ipsec, the mobile node's
identity is carried in the IDi field in the IKE_AUTH
exchange. The home agent maps the IDi field to the
home address used by the mobile node and stores this
state.

But when the IKEv2 end point is not the mobile node
(in PMIPv6 it is the PMA), we are not conveying the
mobile node's identity to the home agent. So we need
the MN Identifier option to carry the mobile node's
identity.

Vijay

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 12 Dec 2006 18:04:44 +0100

---------- Forwarded message ----------
From: Jean-Michel Combes <[email-masked]>
Date: 12 déc. 2006 18:00
Subject: Re: [netlmm] Security comments about draft-sgundave-mipv6-proxymipv6-00
To: Sri Gundavelli <[email-masked]>
Cc: Vijay Devarapalli <[email-masked]>, [email-masked]

Hi Sri,

2006/12/12, Sri Gundavelli <[email-masked]>:
> have  a HoA,

OK.

>  but instead we will have a new home address
> mobility option.

OK.

> HoA in the mobility message, the SA look up will be based on COA.

So, in that case, a MIPv6 HA will not be able to manage PMIPv6 too
unless you modify RFC 3775 (i.e. the MIPv6 daemon must be modified to
accept P-BU)

Anyway, I think it is preferable that I wait for the new version of the draft.

Best regards.

JMC.

---

From: "Kumar Vinod-A20689" <[email-masked]>
Date: Wed, 13 Dec 2006 11:15:14 +0800

Hi Jean,

The term "authorized" means that the PMIP client (or PMA) has the
security keys for a specific set (of one or more) MNs. Note that these
security keys could be different for each of those MNs. Similarly the HA
also is provided the security key for each MN, and the HA will only
accept binding updates secured by an SA with the holder of that key.

Regards,
Vinod

-----Original Message-----
From: Jean-Michel Combes [mailto:[email-masked]] 
Sent: Tuesday, December 12, 2006 9:41 AM
To: Kumar Vinod-A20689
Cc: Sri Gundavelli; [email-masked]
Subject: Re: [netlmm] Security comments

Hi Kumar,

2006/12/12, Kumar Vinod-A20689 <[email-masked]>:
> Hi All,
>
> According to draft-sgundave-mipv6-proxymipv6-00, there is a special 
> node in the network, Proxy Mobile Agent that seeks mobility for 
> certain nodes. In my opinion, it would be more precise if it is 
> explicitly specified that at any given time, we have one Proxy Mobile 
> Agent (PMA) functionality for a given MN inside the local mobility 
> domain. As a result, only this PMA function needs to have an SA with 
> the HA as far as this MN is concerned. In addition, this PMA need not 
> be collocated with the ARs and can be a stand-alone entity. Whenever 
> the MN moves between ARs inside the LMD, the same PMA will send the 
> PBU to the local mobility anchor (LMA). The LMA just needs to be aware

> that it has a SA with a PMA that is authorized to send PBUs for a
specific set of (one or more) MNs.

What, in a technical point of view (i.e. PAD/SAD/SPD), does "authorized"
term mean if your security is based on IPsec?

Best regards.

JMC.

> > >> still
> > >> not

> > >> and

> > with
packet?