Subject: [Mipshop] Confirmation on decision on HMIPv6 Security

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 09 Nov 2006 14:53:45 -0800

Hello,

there were some slides presented by the WG chairs
on the topic of HMIPv6 security at the working
group meeting. the slides are at
http://www3.ietf.org/proceedings/06nov/slides/mipshop-11.pdf

the first proposal was to progress HMIPv6 as a
proposed standard based on the use of EAP over
IKEv2 as the default authentication mechanism.
this removes a dependency to standardize a
separate document that describes MN-MAP security.
there was consensus in the meeting room to
proceed with this.

the second proposal was on what to do with the
current charter item which talks about
standardizing a separate solution for HMIPv6.
there was consensus in the meeting room to not
develop any separate security solution for
HMIPv6.

this mail is to confirm the above decisions on
the mailing list. please send an email by Nov
23rd if you don't agree.

Vijay

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

---

From: Wassim Haddad <[email-masked]>
Date: Mon, 20 Nov 2006 00:33:01 +0200 (EET)

Hi Vijay,

The HMIPv6 security is included in the new mipshop WG charter.
I would like to suggest accepting other proposal(s) for HMIPv6
security and publishing it as experimental RFC(s).

Do you see any problem with that?

Regards,

Wassim H.

---

From: "Soliman, Hesham" <[email-masked]>
Date: Sun, 19 Nov 2006 16:34:41 -0800

> > IKEv2 as the default authentication mechanism.

=> I just want to clarify that the default is IKE/IPsec, whether EAP is
used or not is secondary. You could use EAP or certs establish the SA.

Hesham

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 21 Nov 2006 18:04:57 +0200

If EAP/IKEv2 is sufficient for HMIP, why not for FMIP as well? In other
words, do we still need FMIPv6 security solutions?

Alper

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Friday, November 10, 2006 12:54 AM
> To: [email-masked]
> Subject: [Mipshop] Confirmation on decision on HMIPv6 Security
> 
> Hello,
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 21 Nov 2006 08:49:42 -0800

changed the subject line....

> words, do we still need FMIPv6 security solutions?

I don't think one would ever use IKEv2 with an
access router.

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 21 Nov 2006 22:08:47 +0200

> I don't think one would ever use IKEv2 with an

Why? What's wrong with IKEv2?

Alper

---

From: Julien Laganier <[email-masked]>
Date: Wed, 22 Nov 2006 05:02:44 -0800

Hi Vijay,

Couple of comments below:

On Thursday 09 November 2006 14:53, Vijay Devarapalli 
> IKEv2 as the default authentication mechanism.

I don't understand why IKEv2 usage is restricted to EAP 
authentication. IMHO, mandating IKEv2 "alone" as the 
authentication mechanism seems sufficient; whether or 
not EAP is used to authenticate the initiator is 
deployment-dependent.

Second, I am not sure it really makes sense to base 
HMIPv6 security on IKEv2. See below for an 
explanation.

> develop any separate security solution for

I am not sure I agree with IKEv2 being the only 
solution to secure HMIPv6, and I also have doubts that 
IKEv2 should be one of the solution to secure HMIPv6:

If we suppose that IKEv2 is used between the MN and a 
network entity (let's forget once second it's the HMIP 
MAP), and that the MN and this network entity both 
supports tunnel mode and MOBIKE, then it is possible 
to use ESP with NULL encryption and integrity 
protection to get the same functionality than HMIPv6 
gives. (tunnel overhead will be different, does it 
really matter...)

Note that this is entirely different with MIPv6, 
because MIPv6 has route optimization, which aren't 
possible with HMIPv6.

Now don't take me wrong, I am not saying that HMIPv6 is 
useless since we have MOBIKE. What I am saying is that 
if IKEv2 is mandated along with HMIPv6, then perhaps 
HMIPv6 isn't that useful since MOBIKE can achieve 
about the same.

In other words, I'd like an alternative security 
solution for HMIPv6 to be standardized.

Best,

--julien

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 22 Nov 2006 06:27:55 -0800

> not EAP is used to authenticate the initiator is 

=> Agreed. IKEv2 and IPsec are the means defined in the draft. How an
IKE SA is bootstrapped is not a protocol issue.

 > IKEv2 should be one of the solution to secure HMIPv6:

=> Well, there is no doubt that it is one solution. Probably the best in
fact.

 > HMIPv6 isn't that useful since MOBIKE can achieve 

=> Well, if someone thinks that they can use MOBIKE as a LMM protocol
and get the same results then good luck to them. I think it's a terrible
thing to do and won't give the same results, but if it meets their
requirements then fine. Removing IKE from the solution set is not really
the way yo avoid that scenario. You can't make people use HMIPv6 by
fooling them ;) 

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 22 Nov 2006 07:31:36 -0800

> not EAP is used to authenticate the initiator is 

thats because the MN and the MAP are in different
domains. saying use pre-shared keys or certificates
is not sufficient to advance HMIPv6 as a proposed
standard, since neither are very realistic. MIPv6
did not have this issue since the MN and the HA
belong to the same domain.

so the idea is to say EAP over IKEv2 is the default
mechanism (thereby leveraging the AAA mechanism)
that allows the MAP to authenticate a MN from another
domain. if certificates are still possible, they can
ofcourse be used.

> solution to secure HMIPv6, 

never said that. it is a solution and it is a
described as the only mechanism in the base HMIPv6
spec.

> HMIPv6 isn't that useful since MOBIKE can achieve 

completely irrelevant to this discussion. sure,
MOBIKE will work, but we are not discussing that
here.

Vijay

---

From: Julien Laganier <[email-masked]>
Date: Wed, 22 Nov 2006 07:36:34 -0800

On Wednesday 22 November 2006 06:27, you wrote:
>  > solution to secure HMIPv6, and I also have doubts
>  > that IKEv2 should be one of the solution to
>  > secure HMIPv6:
>
> => Well, there is no doubt that it is one solution.

Yes.

> Probably the best in fact.

There our opinions might differ. 

The issue with IKEv2 is that it currently requires 
distribution of credentials to MNs so that they can be 
authenticated by the MAP. 

IMHO this greatly increase the cost of deploying 
HMIPv6.

Should it be possible to authenticate the IKEv2 SA 
based on self-generated credentials (i.e. CGAs), I'd 
be fine with using IKEv2 as the sole security method.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 22 Nov 2006 08:03:09 -0800

On Wednesday 22 November 2006 07:31, Vijay Devarapalli 
wrote:
> >> http://www3.ietf.org/proceedings/06nov/slides/mip
> >>sho p-11.pdf
> >>
> > I don't understand why IKEv2 usage is restricted
> > to EAP authentication. IMHO, mandating IKEv2
> > "alone" as the authentication mechanism seems
> > sufficient; whether or not EAP is used to
> > authenticate the initiator is
> > deployment-dependent.
>

Right.

> that allows the MAP to authenticate a MN from
> another domain. if certificates are still possible,
> they can ofcourse be used.

Right.

But then the issue is that, besides allowing to 
leverage on AAA to secure HMIPv6, you're coupling the 
deployment of HMIPv6 with the deployment of a AAA 
infrastructure. 

That is, you make it a pre-requisite to have AAA beofe 
HMIPv6 can be deployed.

I think this is problematic. I have absolutely nothing 
against the use of AAA for securing IP layer services 
(e.g. MIPv6), but in some circumstances I'd like to be 
able to deploy such services where no AAA 
infrastructure is available, or the MN has no relation 
to that infrastructure.

In simple words I'd like to keep AAA and HMIPv6 
independent, while not preventing to combine them 
when/where it makes sense.

> described as the only mechanism in the base HMIPv6

Right.

But I am concerned about IKEv2 being the sole solution 
to secure HMIPV6. I am probably misunderstanding that 

> develop any separate security solution for

If no separate solution is developed that mean we have 
a sole manner of securing HMIPv6. Probably I am 
missing something...

--julien

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 22 Nov 2006 23:00:07 +0200

> > > authenticate the initiator is

I agree.

> infrastructure is available, or the MN has no relation

I agree. 

Alper

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 22 Nov 2006 22:54:10 +0200 (EET)

On Wed, 22 Nov 2006, Julien Laganier wrote:

> I think this is problematic.

=> Agree. Note that the HMIPsec proposal with CGA applied on
both sides (to answer some concerns) enables establishing the
SA between the MN and the MAP.

Wassim H.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 22 Nov 2006 13:40:16 -0800

I read this thread and just decided to pick one of the emails to respond
:) 

I don't understand the confusion here, so, let me make a couple of
points: 

- IKEv2, as specified by RFC4306, supports the use of certificates
(X.509 and self-signed), PSKs and EAP for client authentication. So, all
that we need to say is that HMIPv6 uses IKEv2/IPsec to secure the
signaling and people can choose whether they want to use it without an
infrastructure (i.e., self-signed certs), with a PKI (i.e., X.509
certs), or with a AAA infrastructure (i.e., using EAP). There is no tie
to AAA automatically with IKEv2. So, I don't think we need to specify
the use of EAP, because, using EAP for client authentication is
automatically within the scope of RFC4306. 

- To remain infrastructureless and use IKEv2, we don't need CGAs -
self-signed certs are sufficient. If we want stateless autoconfiguration
of the RCoA and cryptographic proof of ownership for those, using CGAs
in IKEv2 may be an option. This is one of the topics slated for
discussion on the cga-ext mailing list. If that work gets done, then,
use of CGAs in IKEv2 should be feasible. 

So, I think we are fine leaving the HMIPv6 spec with IKEv2/IPsec
specified. No further granularity is really needed. 

Vidya

> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Wednesday, November 22, 2006 7:37 AM
> To: Soliman, Hesham; [email-masked]
> Cc: Vijay Devarapalli
> Subject: Re: [Mipshop] Confirmation on decision on HMIPv6 Security
> 
> >  > I am not sure I agree with IKEv2 being the only  > solution to 
> > secure HMIPv6, and I also have doubts  > that IKEv2 should 
> be one of 
> > the solution to  > secure HMIPv6:
> >
> IMHO this greatly increase the cost of deploying HMIPv6.
> 
> Should it be possible to authenticate the IKEv2 SA based on 
> self-generated credentials (i.e. CGAs), I'd be fine with 
> using IKEv2 as the sole security method.
> 
> --julien
>

---

From: "James Kempf" <[email-masked]>
Date: Wed, 22 Nov 2006 13:45:50 -0800

Agree. Seems like it would be more valuable to standardize use of CGAs with 
IKEv2/IPsec rather than do another custom protocol just for HMIP. That way, 
more protocols benefit.

            jak

----- Original Message ----- 
From: "Narayanan, Vidya" <[email-masked]>
To: "Julien Laganier" <[email-masked]>; "Soliman, Hesham" 
<[email-masked]>; <[email-masked]>
Cc: "Vijay Devarapalli" <[email-masked]>
Sent: Wednesday, November 22, 2006 1:40 PM
Subject: RE: [Mipshop] Confirmation on decision on HMIPv6 Security

Vidya

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 22 Nov 2006 23:47:24 +0200 (EET)

On Wed, 22 Nov 2006, Narayanan, Vidya wrote:

> self-signed certs are sufficient.

=> and CGA can fulfill such requirement. So why you won't want to put them
aside?!!

> If we want stateless autoconfiguration
> in IKEv2 may be an option.

=> Using CGAs on both sides don't require IKEv2!

Regards,

Wassim H.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 22 Nov 2006 13:50:25 -0800

James Kempf wrote:
> Agree. Seems like it would be more valuable to standardize use of CGAs 
> with IKEv2/IPsec rather than do another custom protocol just for HMIP. 

agree.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 22 Nov 2006 13:58:42 -0800

Hi Wassim,

> => and CGA can fulfill such requirement. So why you won't 
> want to put them aside?!!
> 

CGAs alone don't fulfill the requirement of remaining infrastureless
*and using IKEv2* :) Julien was talking about using IKEv2 with CGAs for
avoiding the infrastructure and my comment was related to that. 

> > If we want stateless autoconfiguration of the RCoA and 
> cryptographic 
> > proof of ownership for those, using CGAs in IKEv2 may be an option.
> 

Using CGAs on both sides? Do you mean that the MAP IP address is also
based on CGAs? That is possible, although I'd hope that the MAP will
have more to show for authentication and authorization (an X.509 cert,
for e.g.). I do agree that using CGAs doesn't necessarily need IKEv2 -
it is feasible to use the CGA public key to authenticate the messaging,
but that would mean public key cryptography for every LBU/LBA. CGAs can
also be used to establish a shared key - but, that is what would be
facilitated by IKEv2. I don't believe there is value in defining a
different key management protocol that would allow the use of CGAs to
establish shared keys - it can be done, but, it is likely to lose a lot
of the good features of IKEv2 (e.g. algorithm negotiation and protected
ID exchange, etc). 

Vidya

---

From: Wassim Haddad <[email-masked]>
Date: Thu, 23 Nov 2006 00:11:21 +0200 (EET)

Hi Vidya,

> avoiding the infrastructure and my comment was related to that.

=> I see! I was talking about "with CGA and without IKEv2" :)

> for e.g.).

=> Agree in general.

> I do agree that using CGAs doesn't necessarily need IKEv2 -

=> I don't know how to thank you on that! :)

> but that would mean public key cryptography for every LBU/LBA.

=> Not for every LBU/LBA.

> CGAs can also be used to establish a shared key - but, that is what
> would be facilitated by IKEv2.

=> I see what you mean. Let me just mention that CGA have already been
used to establish shared secret without using IKEv2.

Regards,

Wassim H.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 22 Nov 2006 17:09:05 -0800

> automatically within the scope of RFC4306. 

my proposal at the WG meeting was to pick EAP over
IKEv2 as the default mechanism to authenticate the
MN to the MAP. this is because we need to define
at least one realistic mechanism that works for
HMIPv6 instead of just saying use IKEv2 between
the MN and the MAP. that is not sufficient.

for MIPv6 route optimization we could have easily
said use IKE (v1/v2) between the MN and the CN and
you have the SA to secure the BU.

certificates, pre-shared keys can all be used when
available. nobody is disputing that.

Julien and Hesham also seem to have this concern
about making EAP the default mechanism. I would
like to hear more opinions about this.

Vijay

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 22 Nov 2006 17:31:35 -0800

> standard, 

=> Vijay, please see emails from Vidya, James and me about this. The
progression to PS part seems to be your opinion. We all agree the simply
saying IKE/IPsec is enough.

   since neither are very realistic. 

=> Only in your opinion.  

Hesham

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 22 Nov 2006 17:33:10 -0800

> IMHO this greatly increase the cost of deploying 

=> No more than giving each MN a SIM card today. 

 > be fine with using IKEv2 as the sole security method.

=> That's a separate issue. So you want to see an additional mechanism.
That's fine with me. 

Hesham

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 22 Nov 2006 17:42:43 -0800

> the MN and the MAP. that is not sufficient.

=> I think it is sufficient to say use IKE/IPsec. The difference is how
IKE is bootstrapped, which need not be defined as "default". It's a
deployment issue not a protocol issue.

 > you have the SA to secure the BU.

=> No, of course not, you're comparing apples and elephants here! 
Having the "any to any SA" with certs or using AAA is complete fiction.
This is a completely different problem from the MN-MAP issue...

 > like to hear more opinions about this.

=> I don't have a concern about that, what I said was that we don't need
to get into how IKE is bootstrapped. The draft already explains that it
can be done using certs or with EAP/AAA. That's all we need to say.

Hesham

---

From: Julien Laganier <[email-masked]>
Date: Thu, 23 Nov 2006 00:43:18 -0800

On Wednesday 22 November 2006 13:45, James Kempf wrote:
> Agree. Seems like it would be more valuable to
> standardize use of CGAs with IKEv2/IPsec rather than
> do another custom protocol just for HMIP. That way,
> more protocols benefit.

Yes, that makes sense.

--julien

> To: "Julien Laganier" <[email-masked]>;
> "Soliman, Hesham" <[email-masked]>;
> <[email-masked]> Cc: "Vijay Devarapalli"
> <[email-masked]> Sent: Wednesday,
> November 22, 2006 1:40 PM
> I don't understand the confusion here, so, let me
> make a couple of points:
>
> - IKEv2, as specified by RFC4306, supports the use
> of certificates (X.509 and self-signed), PSKs and
> EAP for client authentication. So, all that we need
> to say is that HMIPv6 uses IKEv2/IPsec to secure the
> signaling and people can choose whether they want to
> use it without an infrastructure (i.e., self-signed
> certs), with a PKI (i.e., X.509 certs), or with a
> AAA infrastructure (i.e., using EAP). There is no
> tie to AAA automatically with IKEv2. So, I don't
> think we need to specify the use of EAP, because,
> using EAP for client authentication is automatically
> within the scope of RFC4306.
>
> - To remain infrastructureless and use IKEv2, we
> don't need CGAs - self-signed certs are sufficient.
> If we want stateless autoconfiguration of the RCoA
> and cryptographic proof of ownership for those,
> using CGAs in IKEv2 may be an option. This is one of
> the topics slated for discussion on the cga-ext
> mailing list. If that work gets done, then, use of
> CGAs in IKEv2 should be feasible.
>
> So, I think we are fine leaving the HMIPv6 spec with
> IKEv2/IPsec specified. No further granularity is
> really needed.
>
> Vidya
>
> > From: Julien Laganier
> > [mailto:[email-masked]] Sent: Wednesday,
> > November 22, 2006 7:37 AM To: Soliman, Hesham;
> > [email-masked]
> > Cc: Vijay Devarapalli
> > distribution of credentials to MNs so that they
> > can be authenticated by the MAP.
> >
> > based on self-generated credentials (i.e. CGAs),
> > I'd be fine with using IKEv2 as the sole security
> > method.
> >
> > --julien
> >

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Thu, 23 Nov 2006 09:54:02 +0100

Hi Vijay and Hesham,

> can be done using certs or with EAP/AAA. That's all we need to say.

I agree with Hesham. I don't think we need to tie the usage of HMIPv6
to EAP. As an example in the MIPv6 bootstrapping solution IKEv2 is
used and we described how it can be used with either EAP or certs
depending on the credentials the MN owns and depending on operator
deployment choice.

For this reason, I am in favor of mandating IKEv2/IPsec; the RFC may
include two different paragraphs to describe how IKEv2 can be
bootstrapped based on certs and on EAP.

--Gerardo

---

From: Julien Laganier <[email-masked]>
Date: Thu, 23 Nov 2006 01:49:18 -0800

On Wednesday 22 November 2006 17:09, Vijay Devarapalli 
wrote:
> > EAP for client authentication. So, all that we
> > need to say is that HMIPv6 uses IKEv2/IPsec to
> > secure the signaling and people can choose whether
> > they want to use it without an infrastructure
> > (i.e., self-signed certs), with a PKI (i.e., X.509
> > certs), or with a AAA infrastructure (i.e., using
> > EAP). There is no tie to AAA automatically with
> > IKEv2. So, I don't think we need to specify the
> > use of EAP, because, using EAP for client
> > authentication is automatically within the scope
> > of RFC4306.
>

I don't think we need to define the IKEv2 
authentication method, that is an IKEv2 matter and is 
beyond the scope of the HMIPv6 specification. 

Saying that IKEv2 is used is sufficient, it implies 
that MN and MAP have the means to establish an SA. 
Whether these means are PSKs, Certs, AAA... or even 
CGAs does not matter as long as the SA can be 
established, IMHO.

If we go down the path of enlightening the reader on 
"realistic" IKEv2 authentication methods, then we 
could as well list EAP methods that would 
"realistically" be used in an HMIPv6 deployment 
secured with EAP over IKEv2 ;-)

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 23 Nov 2006 02:02:35 -0800

On Wednesday 22 November 2006 17:33, Soliman, Hesham 
wrote:
>  > >  > I am not sure I agree with IKEv2 being the
>  > >  > only solution to secure HMIPv6, and I also
>  > >  > have doubts that IKEv2 should be one of the
>  > >  > solution to secure HMIPv6:
>  > >
>  > The issue with IKEv2 is that it currently
>  > requires distribution of credentials to MNs so
>  > that they can be authenticated by the MAP.
>  >

Agree, but note that giving each MN a SIM card 
certainly has a non negligible cost. 

Besides, if HMIPv6 is to be used in localized domain 
across the world, this mean that either 1) the MN 
shares credentials with all of those domains, or 2) 
the MN shares credential with its "home" domain, and 
these local domains have a relationship to the MN's 
home domain. 

IMHO that's a quite specific deployment scenario.

>  > Should it be possible to authenticate the IKEv2
>  > SA based on self-generated credentials (i.e.
>  > CGAs), I'd be fine with using IKEv2 as the sole
>  > security method.
>
> => That's a separate issue. So you want to see an
> additional mechanism. That's fine with me.

Ok. (Yes I'd like to see a CGA-based mechanism -- MIPv6 
will have one, why not HMIPv6?)

--julien

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 23 Nov 2006 05:22:39 -0800

> certainly has a non negligible cost. 

=> Sure, but the cost is already borne, so you can re-use it.

 > these local domains have a relationship to the MN's 

=> Sure, 2) sounds very much like roaming to me, coincidence? :) 

 > IMHO that's a quite specific deployment scenario.

=> I don't think so, if it's used by 2 Billion people it can't be too
specific ;)

 > will have one, why not HMIPv6?)

=> Fine with me. I'm a co-author on a solution that uses CGA so I can't
say I'm against that. I'd be interested in seeing such solution too.

Hesham

---

From: Julien Laganier <[email-masked]>
Date: Thu, 23 Nov 2006 05:41:14 -0800

Hesham,

I think we more or less agree. Couple of comments 
below, though.

On Thursday 23 November 2006 05:22, Soliman, Hesham 
> => Sure, but the cost is already borne, so you can

No argument about re-using SIM where deployed -- my 
point was about new deployments.

>  > Besides, if HMIPv6 is to be used in localized
>  > domain across the world, this mean that either 1)
>  > the MN shares credentials with all of those
>  > domains, or 2) the MN shares credential with its
>  > "home" domain, and these local domains have a
>  > relationship to the MN's home domain.
>
> => I don't think so, if it's used by 2 Billion
> people it can't be too specific ;)

I did not say it's not used, neither that it's not used 
a lot.

I said that it is a specific deployment scenario. To 
name it, a scenario where the target deployment is a 
cellular network -- or are you saying that all 
networks where HMIPv6 can be applied are cellular 
networks? ;-)

>  > > => That's a separate issue. So you want to see
>  > > an additional mechanism. That's fine with me.
>  >
>  > Ok. (Yes I'd like to see a CGA-based mechanism --
>  > MIPv6 will have one, why not HMIPv6?)
>
> => Fine with me. I'm a co-author on a solution that
> uses CGA so I can't say I'm against that. I'd be
> interested in seeing such solution too.

Fine.

--julien

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 23 Nov 2006 05:50:54 -0800

> networks where HMIPv6 can be applied are cellular 

=> I didn't say cellular, I said roaming. I don't know of any system
(presumably wireless) that allows for roaming without some form of third
party trust. So it's perfectly fine for third party (i.e. the home
network) trust to be used with HMIP when the MN is roaming. If the MN is
at home then obviously it can use HMIP without worrying about third
party trust.

Hesham

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 23 Nov 2006 09:01:16 -0500

Vijay Devarapalli wrote:
<snip>
> like to hear more opinions about this.

I do not have an issue with IKEv2 being the default mechanism for 
securing HMIPv6 but I am against mandating EAP over IKEv2 since it rules 
out other ways of bootstrapping IKEv2. I am also strongly concerned 
about IKEv2 being the SOLE solution for HMIPv6 security. Hence, I would 
like to oppose the decision to stop working on standalone approaches to 
HMIPv6 security.

Cheers
Suresh

---

From: Julien Laganier <[email-masked]>
Date: Thu, 23 Nov 2006 05:57:45 -0800

On Thursday 23 November 2006 05:50, Soliman, Hesham 
wrote:
>  > >  > Besides, if HMIPv6 is to be used in
>  > >  > localized domain across the world, this mean
>  > >  > that either 1) the MN shares credentials
>  > >  > with all of those domains, or 2) the MN
>  > >  > shares credential with its "home" domain,
>  > >  > and these local domains have a relationship
>  > >  > to the MN's home domain.
>  > >
>  > I did not say it's not used, neither that it's
>  > not used a lot.
>  >
>  > I said that it is a specific deployment scenario.
>  > To name it, a scenario where the target
>  > deployment is a cellular network -- or are you
>  > saying that all networks where HMIPv6 can be
>  > applied are cellular networks? ;-)
>
> => I didn't say cellular, I said roaming. I don't
> know of any system (presumably wireless) that allows
> for roaming without some form of third party trust.
> So it's perfectly fine for third party (i.e. the
> home network) trust to be used with HMIP when the MN
> is roaming. If the MN is at home then obviously it
> can use HMIP without worrying about third party
> trust.

We seems to talk a bit past to each others...

The bottom line is that it is possible to deploy HMIPv6 
without distributing credentials to MNs or requiring a 
third party if an infrastructureless security 
mechanism (e.g. CGA) is used. I think we agreed on 
that.

--julien

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Thu, 23 Nov 2006 15:05:03 +0100

Hi Suresh,

one question: what do you mean by standalone approaches?

--Gerardo

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 23 Nov 2006 06:33:53 -0800

Folks, 

There were two issues being discussed:

1. Whether IKE/IPsec should be the only mechanisms defined for securing
HMIP

2. Whether EAP over IKE should be the required default in the spec.

I think there is general agreement that 2) is unacceptable and that the
spec should mention IKE/IPsec without mandating a bootstrapping
mechanism as a default. 

Regarding 1) above, I'd like people to refer to the discussion we had in
Paris, the slides are available in the proceedings. We always discussed
the nomad model as one model where no infrastructure is needed to
establish the trust between the MN and MAP. This is where CGAs came into
the picture. 

I personally think there is value in allowing the infrastructure-less
option (i.e. some form of CGA-based approach). Which CGA approach to use
is a different question.
Other infrastructure-based approaches (PKI, AAA) are already included in
the base spec. 

Comments?

Hesham

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 23 Nov 2006 09:50:56 -0500

> 1. Whether IKE/IPsec should be the only mechanisms defined for securing

No. It can certainly be one of the mechanisms (even the default) but not 
the only one.

> 2. Whether EAP over IKE should be the required default in the spec.

No. Why should we restrict ourselves to EAP when we have no reason to?

<snip>

> option (i.e. some form of CGA-based approach). Which CGA approach to use

I fully agree.

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 23 Nov 2006 16:16:55 +0100

Hi,

I agree to not specify which method is mandatory to be used with IKEv2
(i.e. certs, EAP, etc.) for HMIPv6 security.

Best regards.

JMC.

---

From: Julien Laganier <[email-masked]>
Date: Thu, 23 Nov 2006 07:41:56 -0800

On Thursday 23 November 2006 06:50, Suresh Krishnan 
wrote:
> > 1. Whether IKE/IPsec should be the only mechanisms
> > defined for securing HMIP
>
> No. It can certainly be one of the mechanisms (even
> the default) but not the only one.

ditto.

> No. Why should we restrict ourselves to EAP when we

ditto.

> <snip>
>
> > I personally think there is value in allowing the
> > infrastructure-less option (i.e. some form of
> > CGA-based approach). Which CGA approach to use is
> > a different question.
>
> I fully agree.

ditto.

--julien

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 23 Nov 2006 09:04:45 -0800

all right. quite a few people have expressed a
preference not to mandate EAP over IKEv2 as the
default authentication mechanism. so we will go
with that in 4140bis.

but another question.

when 4140 was standardized, it was decided to
go for experimental because there was no
standard mechanism to authenticate the MN to
the MAP. 4140 already said use IKE between the
MN and the MAP for authentication and security
association setup. this was not sufficient.

we need to tell the IESG what has changed now
for HMIPv6 to become a proposed standard. I can
see two reasons.

1. better understanding. we now know better how
    HMIPv6 works. :)
2. 4140 talks about IKEv1 whereas 4140bis talks
    about IKEv2. with IKEv2, HMIPv6 does not have
    an issue anymore.

is there something else?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 23 Nov 2006 09:07:38 -0800

Suresh Krishnan wrote:
> out other ways of bootstrapping IKEv2. 

this is *not* correct. among the text you snipped
there was this following text.

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 23 Nov 2006 19:30:24 +0200

> bootstrapped based on certs and on EAP.

Unless we mandate support (not use!) of at least one of the two, we cannot
ensure interoperability between the MN and MAP.

Alper

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 23 Nov 2006 13:44:26 -0500

Vijay Devarapalli wrote:
>> securing HMIPv6 but I am against mandating EAP over IKEv2 since it 
>> rules out other ways of bootstrapping IKEv2. 
> 

This sentence was in response to the following mail you sent on 11/9 
where the last date to comment was today :-)

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 23 Nov 2006 16:07:05 -0800

> the MAP. 

=> No, that's not true. Security was _not_ the reason that HMIP went to
experimental. I don't think you can find one email or WG concensus that
indicates that. There were non-technical reasons that made it go
experimental, or at least I was not given any technical reasons for the
decision.

  4140 already said use IKE between the
 > association setup. this was not sufficient.

=> Not true.

 > is there something else?

=> Security was not the reason. In fact the IESG Sec ADs had no problems
with HMIP security. So I don't see any reason to tell the IESG anything
about security. 

Hesham

---

From: Jari Arkko <[email-masked]>
Date: Mon, 27 Nov 2006 15:19:51 +0200

When you design the security mechanisms for the
HMIP Proposed Standard specification, there are
a number of issues that you should take into account:

1. Feasibility of the credential deployment

    It is necessary for you to provide mechanisms
    that convince the rest of the IETF that
    you can actually deploy your protocol.

    In my experience, deploying new client-side
    credentials for any but the most high value
    purposes is economically infeasible.

    In this case it is probably enough that
    IKEv2 has the optional capability to
    employ AAA and existing credentials
    via EAP, so we have at least one mechanism
    that could be used for a typical wireless
    network deployment. IKEv2 + some zero-config
    mechanism for the client side would
    suffice too, but then I would like to
    see the spec for that. (The same goes
    for EMSK-based approaches if someone
    was thinking of them.)

    So from this point of view you can
    say "just use IKEv2" and leave it
    at that. But see further down in
    the list.

    Anyway, to form a well-informed opinion,
    it would be great to hear about the
    plans of the folks who intend to
    deploy something like this. Are there
    such plans?

2. Sufficiently detailed specification

    It is necessary for you to talk about
    how you use a particular generic
    mechanism such as IPsec in the
    context of this application. What
    addresses are used where, do
    the policy needs of the application
    fit those supported by RFC 4301,
    etc.

3. Defaults and "profiling"

    Defaults and profiling of generic
    mechanisms down to specific
    configuration options can be useful,
    but not absolutely necessary.

    First, IKEv2 can negotiate parameters.

    Second, older specifications that employed
    IPsec had to do a lot of profiling
    because the then-current IPsec RFCs
    were out of date with respect to, say,
    the mandatory encryption algorithms.
    It is not clear that you have do much
    of profiling in newer specifications.
    But see below.

4. Interoperability and mandatory-to-implement

    It is necessary for the specification to
    have a mandatory-to-implement part
    that matches what people expect will
    be needed by most folks who deploy
    the protocol. Otherwise conformance
    to the spec does not at all guarantee
    interoperability.

    Whether you actually need to say anything
    more than "just use IKEv2" depends also
    on what the requirements in RFC 4306
    are for various features. Some features
    are mandatory, some are not. For those
    that are not, if you need them, you need
    to make them mandatory to implement.

    What this means in practice is a
    judgment call. But if you expect
    most of HMIP to be based on AAA,
    the IKEv2 EAP part needs to be
    mandatory to implement.

    Note that mandatory to implement !=
    mandatory to use. I at least would find
    it problematic if you outlawed any of the
    existing IKEv2 authentication methods.
    Or anything else for that matter, unless
    there was a specific technical problem.

-Jari

---

From: "James Kempf" <[email-masked]>
Date: Mon, 27 Nov 2006 09:44:36 -0800

Hesham,

What is the problem with using self-signed certs as an infrastructureless 
approach, as Vidya suggested?

            jak

----- Original Message ----- 
From: "Soliman, Hesham" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, November 23, 2006 6:33 AM
Subject: RE: [Mipshop] Confirmation on decision on HMIPv6 Security

Folks,

Comments?

Hesham

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 27 Nov 2006 10:06:40 -0800

I was looking through RFC4306 and noticed that it is ambiguous on
whether EAP is mandatory to implement or not - EAP is not mentioned in
Section 4 (Conformance Requirements), which I interpret to mean that it
is not mandatory. I am not aware of IKEv2 implementations that don't
support EAP though, but that is a different point. So, if needed, we
could say that EAP in IKEv2 is mandatory to implement (not mandatory to
use) at the MAP. 

Beyond that, as Jari says below, I also think we need some details on
the IPsec selectors and SPD values. 

Vidya

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Monday, November 27, 2006 5:20 AM
> To: Vijay Devarapalli
> Cc: [email-masked]
> Subject: Re: EAP over IKEv2 as the default mechanism for 
> HMIPv6 (wasRe: [Mipshop] Confirmation on decision on HMIPv6 Security)
> 
> When you design the security mechanisms for the HMIP Proposed 
> Standard specification, there are a number of issues that you 
> should take into account:
> 
> > all right. quite a few people have expressed a preference not to 
> > mandate EAP over IKEv2 as the default authentication 
> mechanism. so we 
> > will go with that in 4140bis.
> >
> > but another question.
> >
> > when 4140 was standardized, it was decided to go for experimental 
> > because there was no standard mechanism to authenticate the 
> MN to the 
> > MAP. 4140 already said use IKE between the MN and the MAP for 
> > authentication and security association setup. this was not 
> > sufficient.
> >
> > we need to tell the IESG what has changed now for HMIPv6 to 
> become a 
> > proposed standard. I can see two reasons.
> >
> >>> (X.509 and self-signed), PSKs and EAP for client 
> authentication. So, 
> >>> all that we need to say is that HMIPv6 uses IKEv2/IPsec to secure 
> >>> the signaling and people can choose whether they want to use it 
> >>> without an infrastructure (i.e., self-signed certs), with a PKI 
> >>> (i.e., X.509 certs), or with a AAA infrastructure (i.e., 
> using EAP). 
> >>> There is no tie to AAA automatically with IKEv2. So, I 
> don't think 
> >>> we need to specify the use of EAP, because, using EAP for client 
> >>> authentication is automatically within the scope of RFC4306.
> >>
> >> IKEv2 as the default mechanism to authenticate the MN to the MAP. 
> >> this is because we need to define at least one realistic mechanism 
> >> that works for
> >> HMIPv6 instead of just saying use IKEv2 between the MN and 
> the MAP. 
> >> that is not sufficient.
> >>
> >> for MIPv6 route optimization we could have easily said use IKE 
> >> (v1/v2) between the MN and the CN and you have the SA to 
> secure the 
> >> BU.
> >>
> >> Julien and Hesham also seem to have this concern about 
> making EAP the 
> >> default mechanism. I would like to hear more opinions about this.
> >>
> >> Vijay
> >>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Nov 2006 10:04:56 -0800

>     purposes is economically infeasible.

agreed. this is why I have issues when someone says
just use certificates or pre-shared keys between the
MN and the MAP for mutual authentication.

>     deploy something like this. Are there

none that I am aware of.

>     fit those supported by RFC 4301,

the plan is to re-use what has been done for MIPv6.

>     the IKEv2 EAP part needs to be

this is what I am driving at. make sure there is at
least one mechanism that is guaranteed to work. this
of course requires a AAA infra to be in place.

>     existing IKEv2 authentication methods.

we are not doing that.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 27 Nov 2006 10:15:10 -0800

Hi James,
There is one problem with self-signed certs usage for HMIP. If I recall
correctly, the MN is supposed to autoconfigure its RCoA in HMIP. The use
of self-signed certs in this case will not provide any address
authorization for the RCoA, which could lead to redirection attacks. If
the MAP assigned an RCoA in IKEv2, this is not a problem, since the MAP
could tie the assigned address to the IPsec SA. 

Using CGAs with IKEv2 will allow for address authorization with RCoA
autoconfiguration. 

Vidya 

> From: James Kempf [mailto:[email-masked]] 
> Sent: Monday, November 27, 2006 9:45 AM
> What is the problem with using self-signed certs as an 
> infrastructureless approach, as Vidya suggested?
> 
>             jak
>

---

From: "James Kempf" <[email-masked]>
Date: Mon, 27 Nov 2006 10:49:12 -0800

I think allowing the RCoA to be assigned within IKEv2 should work. I believe 
we have thought through this quite throroughly in the boostrapping 
discussion, so the HMIP draft only need refer to that.

But I'm curious how redirection attacks are prevented now if the RCoA is 
autoconfigured. If the RCoA is not a CGA, there's no authorization to tie 
the address to the SA, or am I missing something?

            jak

----- Original Message ----- 
From: "Narayanan, Vidya" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Soliman, Hesham" 
<[email-masked]>; <[email-masked]>
Sent: Monday, November 27, 2006 10:15 AM
Subject: RE: [Mipshop] Confirmation on decision on HMIPv6 Security

Hi James,

Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 27 Nov 2006 10:58:36 -0800

Hi James, 

> Sent: Monday, November 27, 2006 10:49 AM
> To: Narayanan, Vidya; Soliman, Hesham; [email-masked]
> I think allowing the RCoA to be assigned within IKEv2 should 
> work. I believe we have thought through this quite 
> throroughly in the boostrapping discussion, so the HMIP draft 
> only need refer to that.
> 

Agreed. 

> But I'm curious how redirection attacks are prevented now if 
> the RCoA is autoconfigured. If the RCoA is not a CGA, there's 
> no authorization to tie the address to the SA, or am I 
> missing something?
> 

I don't believe you are missing anything. However, if we did IKEv2 with
EAP, the ID (Say, NAI) is tied to the IKE_SA. The ID is authenticated
(due to client authentication) and if the peer is required to send the
chosen IP address in IKEv2 to the MAP, the MAP can tie that to the SA
after performing a proxy DAD and ensuring that it doesn't have the
address registered for any other node. So, while there is no "absolute"
address authorization, this will still ensure that no live node's
traffic is being redirected to an attacker. We can do the same with
self-signed certs, but the issue will be that, in the event of problems,
it is much harder (impossible) to track down the attacker, since there
was no authentication. But then, the fact that the system is
infrastructureless may imply that there is no reason to track anyone
down :) 

Such details on address authorization should be captured in the document
for a complete security solution. 

Vidya

> infrastructure-less

---

From: "James Kempf" <[email-masked]>
Date: Mon, 27 Nov 2006 11:23:12 -0800

Here's the current text in the HMIP draft on IKEv2:

    IKEv2 allows the use of EAP as a mechanism to bootstrap the security
    association between the communicating peers. Hence, in the absence of
    Certificates or PKI-based trust models, EAP can be used with IKEv2 to
    leverage the AAA infrastructure to bootstrap the SA between the
    mobile node and the MAP. Such mechanism is useful in scenarios where
    an administrator wishes to avoid the configuration and management of
    certificates on mobile nodes.

    If EAP is used with IKEv2, the EAP method runs between the mobile
    node and a AAA server. Following a successful authentication, the
   resulting keying material can be used to bootstrap IKEv2 between the
   MAP and the mobile node. The specification of which EAP methods
   should be used, or how keys are transported between the MAP and the
   AAA server is outside the scope of this document.

Perhaps we can concentrate on how to craft some text that captures what 
might be necessary for someone who wants to implement HMIP to be able to 
ensure interoperability, and for someone who wants to deploy it to be able 
to match their deployment circumstances?

My issues are the following:

- The current text seems to make certs the default and EAP a backup option. 
I think that both options should be equally weighted.

- Since 4306 does not mandate EAP, I think EAP is a MUST for HMIP, to ensure 
interoperability. If 4306 does not mandate certs, that should also be 
included as a MUST, i.e. both options need to be available for 
interoperability.

- I think the text should discuss the drawbacks of each option from a 
deployment standpoint as guidance to people who are deploying it. I think 
this should be included in the "Security Considerations" section.

- I think the text should point to draft-ietf-mip6-ikev2-ipsec-07.txt, 
draft-ietf-mip6-bootstrapping-split-03.txt, and 
draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt (if relevant) and 
specify what details in those drafts can be reused for HMIP security and 
what details need to be changed (if anything) and what those changes are.

- I think it would make sense to include self-signed certs as an 
infrastructureless option, but that might require more changes, as Vidya 
suggested. I think these are certainly worthwhile, the WG needs to consider 
whether it is worth taking the time to work through them.

In short, I think the current text needs tightening up and more details 
about exactly how IKEv2 can be used.

            jak

----- Original Message ----- 
From: "Narayanan, Vidya" <[email-masked]>
To: "Jari Arkko" <[email-masked]>; "Vijay Devarapalli" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 27, 2006 10:06 AM
Subject: RE: EAP over IKEv2 as the default mechanism for HMIPv6(wasRe: 
[Mipshop] Confirmation on decision on HMIPv6 Security)

Vidya

---

From: "James Kempf" <[email-masked]>
Date: Mon, 27 Nov 2006 11:27:15 -0800

jak>> If proxy DAD is used, then the MAP is restricted to be on the last 
hop, right? If this is the case for any solution where the RCoA is 
autoconfigured, then the deployment scenerios for HMIP become quite 
restricted, IMO. If that is the case, then I think the WG needs to think 
about adding assignment of the RCoA within the IKEv2 SA regardless of 
whether self-signed certs are mentioned, so that deployment scenerios where 
the MAP is acting as a gateway to an entire access network can also be 
securely accommodated.

jak>> Yes, I agree. The current document is really lacking in discussion of 
details such as these.

            jak

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 27 Nov 2006 11:31:49 -0800

> hop, right? 

Not really. Is it any different from Proxy ND in general? The HA in MIP6
does Proxy ND for the MN. The MAP will need to do the same thing, right?

Vidya

> If this is the case for any solution where the 
> RCoA is autoconfigured, then the deployment scenerios for 
> HMIP become quite restricted, IMO. If that is the case, then 
> I think the WG needs to think about adding assignment of the 
> RCoA within the IKEv2 SA regardless of whether self-signed 
> certs are mentioned, so that deployment scenerios where the 
> MAP is acting as a gateway to an entire access network can 
> also be securely accommodated.
> 
> Such details on address authorization should be captured in 
> the document for a complete security solution.
> 
> jak>> Yes, I agree. The current document is really lacking in 
> discussion 
> jak>> of
> details such as these.
> 
>             jak 
> 
>

---

From: "James Kempf" <[email-masked]>
Date: Mon, 27 Nov 2006 11:37:41 -0800

ND only works on the last hop. The TTL is set to 255, and if it gets 
decremented, the receiver is required to drop the packet. It's a security 
measure to prevent offlink attacks.

An HA is typically on the last hop, so proxy ND will work for an HA (modulo 
the lack of SEND).

            jak

----- Original Message ----- 
From: "Narayanan, Vidya" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Soliman, Hesham" 
<[email-masked]>; <[email-masked]>
Sent: Monday, November 27, 2006 11:31 AM
Subject: RE: [Mipshop] Confirmation on decision on HMIPv6 Security

Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 27 Nov 2006 12:03:32 -0800

> Sent: Monday, November 27, 2006 11:38 AM
> ND only works on the last hop. The TTL is set to 255, and if 
> it gets decremented, the receiver is required to drop the 
> packet. It's a security measure to prevent offlink attacks.
> 

Right. However, doesn't proxy ND simply mean that it works on that hop
alone? It doesn't mean that it extends ND to multiple hops, right?  

> An HA is typically on the last hop, so proxy ND will work for 
> an HA (modulo the lack of SEND).
> 

I'm confused here. An HA is on the last hop with respect to what? I
can't see any difference between an HA and a MAP with respect to
relative locations in the mobility domains they are serving - what am I
missing? 

Vidya

---

From: Jari Arkko <[email-masked]>
Date: Mon, 27 Nov 2006 22:48:55 +0200

Narayanan, Vidya kirjoitti:
> support EAP though, but that is a different point.
I too was confused by merely reading RFC 4306, but
then I called Tero Kivinen :-) He first noted that
his interpretation of the Section 4 text

      ... optional features ... Ability to support various
      types of legacy authentication.

is that EAP in its entirety is optional. Then he noted
that at the end of Section 4 there are four paragraphs
that specify the truly mandatory parts of the protocol
and that EAP is not listed there.

>  So, if needed, we
This would work for me.
> the IPsec selectors and SPD values. 
Hopefully these can be mostly copied from
3776bis, as Vijay explained.

--Jari
>> available. nobody 
>>>> is disputing that.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 27 Nov 2006 22:50:34 +0200

>
> - The current text seems to make certs the default and EAP a backup
> option. I think that both options should be equally weighted.
>
> - Since 4306 does not mandate EAP, I think EAP is a MUST for HMIP, to
> ensure interoperability. If 4306 does not mandate certs, that should
> also be included as a MUST, i.e. both options need to be available for
> interoperability.
>
> deployment standpoint as guidance to people who are deploying it. I
> think this should be included in the "Security Considerations" section.
>
> specify what details in those drafts can be reused for HMIP security
> and what details need to be changed (if anything) and what those
> changes are.
>
> infrastructureless option, but that might require more changes, as
> Vidya suggested. I think these are certainly worthwhile, the WG needs
> to consider whether it is worth taking the time to work through them.
All good suggestions, agreed.

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Mon, 27 Nov 2006 13:00:50 -0800

jak>> Yes, that's right. I guess I've lost the thread here. I thought you 
were saying that address authorization is established by having the MAP 
perform proxy ND? My point was that if that is so, then it restricts MAP 
deployment to the last hop, i.e. at the access router.

jak>> Looking back over your previous post, I think we are discussing is the 
following, which I took to be your proposal for ensuring address 
authorization:

-...the ID (Say, NAI) is tied to the IKE_SA. The ID is authenticated
- (due to client authentication) and if the peer is required to send the
- chosen IP address in IKEv2 to the MAP, the MAP can tie that to the SA
- after performing a proxy DAD and ensuring that it doesn't have the
- address registered for any other node.

jak>> then it is necessary for the MAP to be on the last hop, i.e. at the 
access router because the proxy ND signaling will have the TTL set to 255 
and it would otherwise get decremented causing the packets to be dropped by 
the receiver, right?

jak>> My issue with that (sorry for repeating myself) is that it rules out 
deployments where the MAP is acting as an access network gateway. In those 
cases, this technique can't be used to provide address authorization, 
because the MAP will be deployed several hops away from the access router. I 
think having the MAP assign the RCoA within the IKEv2 SA as described in 
draft-ietf-mip6-bootstrapping-split-03.txt could be used to tie the IP 
address to the SA, independently of whether self-signed certificates are 
used. Of course, it would also work for self-signed certificates.

jak>> With respect to the mobile node's home subnet. The HA performs proxy 
ND for the mobile node on the home subnet, to ensure that no other node can 
claim the mobile node's home address, and to provide other routers with a 
link layer forwarding address for packets that they receive having the 
mobile node's home IP address.

            jak

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 27 Nov 2006 14:48:24 -0800

I agree with all the suggestions as well.  

Vidya

> Sent: Monday, November 27, 2006 12:51 PM
> To: James Kempf
> Cc: Narayanan, Vidya; Vijay Devarapalli; [email-masked]
> Subject: Re: [Mipshop] Let's talk text (was Re: EAP over 
> IKEv2 as the default mechanism for HMIPv6)
> 
> 
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Nov 2006 20:29:38 -0800

> what details need to be changed (if anything) and what those changes are.

yes, the above should be addressed in 4140bis.

Vijay

---

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 28 Nov 2006 14:54:09 +0100

> what details need to be changed (if anything) and what those 

This makes sense IMHO, but wouldn't those drafts be normative
references, i.e., wouldn't there be a problem to progress HMIP as
proposed standard before the bootstrapping mechanisms are at the same
standards level?

And do you mean reuse of HMIP security-related bootstrapping mechabisms
(Ipsec SA setup and auth/authz with MSA) only or also other
bootstrapping mechanisms such as HA(->MAP) address discovery and
HoA(->RCoA) assignment? The latter should be applicable as well and it
might be valuable to consider them as an option in addition to the
mechanisms specified in 4140.

Regards,

Kilian

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 28 Nov 2006 16:01:03 +0100

Hi,

> I think that both options should be equally weighted.

I agree.
A solution may be just to remove "Hence, in the absence of
Certificates or PKI-based trust models,"

> included as a MUST, i.e. both options need to be available for

IMHO, it would be better to keep as general as possible which methods
may be used with IKEv2 (i.e. without a MUST) like MIPv6.
My reason is that we will not able to mention all the potential
methods usable with IKEv2. Today, the *fashion" is EAP with IKEv2 but
what would happen if tomorrow, it would be Kerberos with IKEv2 or
another method? :)

> this should be included in the "Security Considerations" section.

As mentioned above, I agree to add examples of methods used with IKEv2
and it is a good idea to explain advantages and drawbacks of these
ones.

> - I think the text should point to draft-ietf-mip6-ikev2-ipsec-07.txt,

Agree.

> draft-ietf-mip6-bootstrapping-split-03.txt, and

What is the reason of such a pointer?

Best regards.

JMC.

PS: BTW, IMO, that it would be necessary to push EAP mandatory in the
revision of IKEv2 (draft-hoffman-ikev2bis-00.txt) because it would
ease its use in drafts./RFCs based on it and because the only one
deployement of IKEv2 I know today uses EAP.

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 29 Nov 2006 02:15:45 +1100

> relative locations in the mobility domains they are serving - what am I

=> Nothing.

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 28 Nov 2006 07:26:35 -0800

> proposed standard before the bootstrapping mechanisms are at the same

the above three drafts are all targeted as proposed
standards and they are further ahead in the process
too. so that shouldnt be a problem.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Tue, 28 Nov 2006 09:54:31 -0800

jak>> If these drafts contain specification that HMIP technically requires 
to get security adequately addressed, and I believe they do, references are 
necessary. Duplicating that material in the HMIP draft is not an option, 
since then any changes in the original text down the line would need to be 
propagated. Normative references that require resolution happen all the 
time, the RFC Editor is capable of resolving them. In this case, I don't 
believe there is much deployment urgency so I don't see a problem with 
delay. The other drafts are near complete anyway.

jak>> I've never been particularly fond of HMIP's bootstrapping mechanism 
because it requires changes in the access routers. One of the attractions of 
HMIP without that bootstrapping is that it could be used with no changes in 
any other access network hardware. I'm not advocating that the current 
bootstrap mechanism be removed, since others seem to like it, but I think it 
makes sense to take a look at the bootstrapping mechanisms for MIP6 and see 
whether they could also be adapted to HMIP. In particular, I think the 
mechanism in draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt would make 
a lot of sense for HMIP, since they are envisioned for dynamic home agent 
deployments, which are very similar.

jak>> However, this is orthogonal to the current discussion about security, 
and I don't see it as strictly necessary for the draft to be ready for 
publication. I do believe the current security text needs work before it is 
ready for publication, along the lines of the points outlined in the 
original email.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 28 Nov 2006 09:58:10 -0800

> What is the reason of such a pointer?

In the discussion on address authorization, there is a question whether the 
current RCoA provisioning mechanism provides protection against redirection 
attacks. One way to accomplish that is to have the RCoA assigned as part of 
the IKEv2 SA establishment. That is described in 
draft-ietf-mip6-bootstrapping-split-03.txt. Of course, if there is some 
other way to provide redirecdtion attack protection that doesn't use this 
technique, that would be adaquate too.

            jak

---

From: Julien Laganier <[email-masked]>
Date: Tue, 28 Nov 2006 12:55:18 +0100

Hi James,

I agree with your proposal below.

--julien

On Monday 27 November 2006 20:23, James Kempf wrote:
> 
> [...]
>
> Perhaps we can concentrate on how to craft some text
> that captures what might be necessary for someone
> who wants to implement HMIP to be able to ensure
> interoperability, and for someone who wants to
> deploy it to be able to match their deployment
> circumstances?
>
> - The current text seems to make certs the default
> and EAP a backup option. I think that both options
> should be equally weighted.
>
> - Since 4306 does not mandate EAP, I think EAP is a
> MUST for HMIP, to ensure interoperability. If 4306
> does not mandate certs, that should also be included
> as a MUST, i.e. both options need to be available
> for interoperability.
>
> - I think the text should discuss the drawbacks of
> each option from a deployment standpoint as guidance
> to people who are deploying it. I think this should
> be included in the "Security Considerations"
> section.
>
> draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt
> (if relevant) and specify what details in those
> drafts can be reused for HMIP security and what
> details need to be changed (if anything) and what
> those changes are.
>
> - I think it would make sense to include self-signed
> certs as an infrastructureless option, but that
> might require more changes, as Vidya suggested. I
> think these are certainly worthwhile, the WG needs
> In short, I think the current text needs tightening
> up and more details about exactly how IKEv2 can be
> used.
>
>             jak

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 29 Nov 2006 11:28:40 +1100

Folks, 

I encourage everyone to read the security considerations section in 4140.
The issue of address authorisation and IKE policy was discussed several
times in great detail and the resolution was included in the 4140. 

I'd like to re-iterate to everyone that unlike a HoA, the RCoA is not
"pre-assigned" in HMIP. The MN opportunistically configures an address and
the MAP allows that, provided that no one else is using such address. This
is the only requirement. 

Hesham

 > Sent: Tuesday, November 28, 2006 6:27 AM
 > Subject: *****SPAM***** Re: [Mipshop] Confirmation on decision on HMIPv6
 > Security
 >

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 29 Nov 2006 11:31:02 +1100

> approach, as Vidya suggested?

=> I didn't say there was a problem, I was discussing the various categories
of scenarios. The reason I favour CGAs for the infrastructure-less case is
that they would work for FMIP as well. 

Hesham

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 28 Nov 2006 18:58:39 -0800

I exchanged a couple of offline emails with Hesham and realized we were
saying the same thing :) To clarify, "address authorization" does not
need/mean cryptographic address ownership proof. 

In the case of HMIP, the MN auto-configures an RCoA. The MN must then
claim that address in an IKEv2 exchange with the MAP, at which point,
the MAP must verify that the RCoA is not already in use by a different
node (i.e., the RCoA is not already tied to a different IKE/IPsec SA).
If the prefix on which the RCoA belongs is a physical link, the MAP
would also have to perform a DAD on the link for the RCoA, but this is
obviously not needed if the link is virtual. If the RCoA is not in use,
the MAP then ties that RCoA to the IKE/IPsec SA. Subsequent LBU from the
MN will result in a check at the MAP to ensure the correct RCoA-SA
mapping. 

Effectively, IMHO, the above procedure is performing authorization for
the RCoA. Also, FWIW, I don't think this is any different for the HoA in
the MIP6 case either. Whether the HA/MAP is assigning the address or the
MN is picking one, the point is that the IKEv2 exchange ties the address
to the SA created after verification that the address can be used by
that MN. The duration of validity of these addresses is really
irrelevant. 

I re-read the security considerations of 4140 and it does contain
relevant text (except I disagree that authorization for the RCoA is not
needed - it is needed and that is exactly what is being done as well -
but, I think that is just a terminology debate as to what one means by
"address authorization") - but, I think we need to be clearer and look
for consistency in the other sections on MAP behavior. 

Vidya

> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Tuesday, November 28, 2006 4:29 PM
> To: 'James Kempf'; Narayanan, Vidya; Soliman, Hesham; [email-masked]
> Subject: RE: Address authorisation in HMIP[Mipshop] 
> Confirmation on decision on HMIPv6 Security
> 
> Folks, 
> 
> The issue of address authorisation and IKE policy was 
> discussed several times in great detail and the resolution 
> was included in the 4140. 
> 
> I'd like to re-iterate to everyone that unlike a HoA, the 
> RCoA is not "pre-assigned" in HMIP. The MN opportunistically 
> configures an address and the MAP allows that, provided that 
> no one else is using such address. This is the only requirement. 
> 
> Hesham
> 
>  > From: James Kempf [mailto:[email-masked]]  > 
> Sent: Tuesday, November 28, 2006 6:27 AM  > To: Narayanan, 
> Vidya; Soliman, Hesham; [email-masked]  > Subject: 
> *****SPAM***** Re: [Mipshop] Confirmation on decision on 
> HMIPv6  > Security  >  > I don't believe you are missing 
> anything. However, if we did IKEv2 with  > EAP, the ID (Say, 
> NAI) is tied to the IKE_SA. The ID is authenticated  > (due 
> to client authentication) and if the peer is required to send 
> the  > chosen IP address in IKEv2 to the MAP, the MAP can tie 
> that to the SA  > after performing a proxy DAD and ensuring 
> that it doesn't have the  > address registered for any other 
> node. So, while there is no "absolute"
>  > address authorization, this will still ensure that no live 
> node's  > traffic is being redirected to an attacker. We can 
> do the same with  > self-signed certs, but the issue will be 
> that, in the event of problems,  > it is much harder 
> (impossible) to track down the attacker, since there  > was 
> no authentication. But then, the fact that the system is  > 
> infrastructureless may imply that there is no reason to track 
> anyone  > down :)  >  > jak>> If proxy DAD is used, then the 
> MAP is restricted to be on the last  > hop, right? If this is 
> the case for any solution where the RCoA is  > 
> autoconfigured, then the deployment scenerios for HMIP become 
> quite  > restricted, IMO. If that is the case, then I think 
> the WG needs to think  > about adding assignment of the RCoA 
> within the IKEv2 SA regardless of  > whether self-signed 
> certs are mentioned, so that deployment scenerios  > where  > 
> the MAP is acting as a gateway to an entire access network 
> can also be  > securely accommodated.
>  >
>  > Such details on address authorization should be captured 
> in the document  > for a complete security solution.
>  >
>  > jak>> Yes, I agree. The current document is really lacking 
> in discussion  > of  > details such as these.
>  > 
>  >             jak
>  >
>  >

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Wed, 29 Nov 2006 10:36:39 +0100

> that MN. The duration of validity of these addresses is really

I agree. And draft-ietf-mip6-bootstrapping-split-03 introduces a way
for the MN to auto-configure a HoA in IKEv2 exchange, too. So I really
don't see an issue in HMIPv6 about this if IKEv2 is used: it's the
very same approach used in MIP6 bootstrapping.

--Gerardo