Subject: Re: EAP over IKEv2 as the default mechanism for HMIPv6 (was Re:[Mipshop] Confirmation on decision on HMIPv6 Security)

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 23 Nov 2006 16:51:01 -0800 (PST)

As far as I remember the issue was deployment, or lack of deployment possibilities for HMIPv6 at that time? Or there was no request from the SDOs. Things might have changed now. 

Behcet

----- Original Message ----
From: "Soliman, Hesham" <[email-masked]>
To: Vijay Devarapalli <[email-masked]>; [email-masked]
Cc: Jari Arkko <[email-masked]>
Sent: Thursday, November 23, 2006 6:07:05 PM
Subject: RE: EAP over IKEv2 as the default mechanism for HMIPv6 (was Re:[Mipshop] Confirmation on decision on HMIPv6 Security)

 > 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
 > > [email-masked]
 > > https://www1.ietf.org/mailman/listinfo/mipshop
 > 
 > 
 > _______________________________________________
 > Mipshop mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/mipshop
 > 

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

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

---

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

Actually, my recollection why HMIP was not proposed for PS originally is
that there were two reasons. First, nobody
was lining up to deploy it, as Behcet mentioned. That really hasn't changed
but IETF has no requirement that a particular protocol have a deployment 
case
before it is standardized, so if the WG wants to standardize it there is 
nothing
to prevent it (unless of course the IESG objects).

The other was that the use of IKEv1 was rather vaguely specified.
There were still a lot of
details, involved in establishing the mobile node identity,
provisioning of the mobile node with certificates for IKEv1, SA selectors, 
etc..,
that were not discussed in the document. For MIP6 itself, these details have 
required
an entirely separate draft, it is not clear that all of the MIP6 details 
would be
reusable, but the document should at least discuss which details are
and which need to be changed, if any. In particular, at the time, I think
IKEv1 for MIP6 did not support dynamic home agent selection, which is
very similar to how a MAP would work, so it was not clear whether IKEv1
would actually work in a real deployment. I think the IESG didn't object
because their requirements for approving a draft for experimental are
much less strict than for approving a draft for PS.

I think what's changed now is that the bootstrapping
 work has led to a much better understanding of how a dynamic home agent
could be deployed, and that knowledge transfers to HMIP also, as Gerardo
said. I think this needs to be captured somehow in the current
document, and the details need to be filled in. I don't think arguing
about what was or was not the reason that HMIP was not standardized
is particularly helpful. I think we need to focus on what is the problem
with the current text and how to fix it such that someone wanting to
deploy it (if that should ever happen) would be able to do so
given their particular deployment needs.

            jak

---

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

> The other was that the use of IKEv1 was rather vaguely specified.

=> At the risk of rat holing here, I'll completely disagree with this
recollectiion of events. It's not an important issue now but I won't accept
a reconstruction of historu :) sorry. 
The security aspects were reviewed by several people and discussed for at
least a month. The security Ads said it was "perfectly acceptable". 
If that were the reason it would have been easily fixed, but it wasn't.

 > an entirely separate draft, 

=> HMIP reuses all that, the only part that needed clarification was the IKE
policy checks, which are in 4140. The rest is the same as MIPv6. 

Hesham