Confirmation on decision on HMIPv6 Security

Julien Laganier wrote:
> Hi Vijay,
> 
> Couple of comments below:
> 
> On Thursday 09 November 2006 14:53, Vijay Devarapalli 
> wrote:
>> 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/mipsho
>> p-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.
> 
> 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.

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.

> I am not sure I agree with IKEv2 being the only 
> 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.

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

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

Vijay

_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

On Wednesday 22 November 2006 07:31, Vijay Devarapalli 
wrote:
> Julien Laganier wrote:
> > Hi Vijay,
> >
> > Couple of comments below:
> >
> > On Thursday 09 November 2006 14:53, Vijay
> > Devarapalli
> >
> > wrote:
> >> 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
> >> htt
p://www3.ietf.org/proceedings/06nov/slides/mip
> >>sho p-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.
> >
> > 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.
>
> 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.

Right.

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

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.

> > I am not sure I agree with IKEv2 being the only
> > 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.

Right.

But I am concerned about IKEv2 being the sole solution 
to secure HMIPV6. I am probably misunderstanding that 
other part of your message:

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

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

--julien

_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

> > >>
> > >> there were some slides presented by the
WG chairs
> > >> on the topic of HMIPv6 security at the
working
> > >> group meeting. the slides are at
> > >> htt
p://www3.ietf.org/proceedings/06nov/slides/mip
> > >>sho p-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.
> > >
> > > 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.

I agree.

> > 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.
> 
> Right.
> 
> > 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.
> 
> 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.

I agree. 


Alper


> 
> In simple words I'd like to keep AAA and HMIPv6
> independent, while not preventing to combine them
> when/where it makes sense.
> 
> > > I am not sure I agree with IKEv2 being the
only
> > > 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.
> 
> Right.
> 
> But I am concerned about IKEv2 being the sole solution
> to secure HMIPV6. I am probably misunderstanding that
> other part of your message:
> 
> > 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.
> 
> If no separate solution is developed that mean we have
> a sole manner of securing HMIPv6. Probably I am
> missing something...
> 
> --julien
> 
> _______________________________________________
> Mipshop mailing list
> Mipshopietf.org
> https:
//www1.ietf.org/mailman/listinfo/mipshop


_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

On Wed, 22 Nov 2006, Julien Laganier wrote:

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

=> 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.

_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

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

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



_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop