Hi,
2006/11/27, James Kempf <kempf docomolabs-usa.com>:
> 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.
I agree.
A solution may be just to remove "Hence, in the absence
of
Certificates or PKI-based trust models,"
>
> - 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.
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? 
>
> - 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.
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.
> 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" <vidyanqualcomm.com>
> To: "Jari Arkko" <jari.arkkopiuha.net>; "Vijay Devarapalli"
> <vijay.devarapalliazairenet.com>
> Cc: <mipshopietf.org>
> 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)
>
>
> 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
>
> > -----Original Message-----
> > From: Jari Arkko [mailto:jari.arkkopiuha.net]
> > Sent: Monday, November 27, 2006 5:20 AM
> > To: Vijay Devarapalli
> > Cc: mipshopietf.org
> > 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:
> >
> > 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
> >
> > Vijay Devarapalli kirjoitti:
> > > 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
> > >
> > > 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
> >
>
> _______________________________________________
> 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
|