EAP over IKEv2 as the default mechanism for HMIPv6 (was Re: Confirmation on decision on HMI

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

=> 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
> MN and the MAP for authentication and security
> 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

>
> Vijay
>
> Vijay Devarapalli wrote:
> > Narayanan, Vidya wrote:
> >
> >> - 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.
> >
> > 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
> >
> > _______________________________________________
> > Mipshop mailing list
> > Mipshopietf.org
> > https://www1.ietf.org/mailman/listinfo/mipshop
>
>
> _______________________________________________
> Mipshop mailing list
> Mipshopietf.org
> https://www1.ietf.org/mailman/listinfo/mipshop
>

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