|
Hi Alper,
sorry for the very late answer. Please find below the email
that Sam sent during the IESG discussion of the MIP6 bootstrapping
PS.
You can find other views on this topic also in the
notes of ICOS BoF (IETF #62).
--Gerardo
>
> ------ Forwarded Message
> > From: ext Sam Hartman <hartmans-ietf at mit.edu>
>
> Date: Wed, 01 Mar 2006 16:03:22 -0500
> > To: <
iesg at ietf.org>
> > Cc: <basavaraj.patil at nokia.com>,
<gdommety at cisco.com>
> >
Subject: DISCUSS and COMMENT: draft-ietf-mip6-bootstrap-ps
> >
>
> Discuss:
> > First, thanks for a good job on a well written
problem
> statement. My
> > concerns here are concernes
about the document but can be
> interpreted
> > as early warnings
about the direction the WG seems to be taking.
> > Addressing the
concerns against the document can probably
> be done very
> >
simply, but it is important to discuss the working group's direction
>
> now to make sure that you will not end up with a discuss
challenging
> > something fundamental about your solution when it comes
to the IESG.
> >
> > In section 7.2 you discuss using the
authentication to both set up
> > network access and mobility access.
I don't think this is
> compatible
> > with how the EAP
working group and security area invision EAP being
> > used. For
example the key management framework requires
> that all keys
> >
based on the EMSK be generated at the beginning of the
> exchange.
We've
> > explicitly resisted several attempts to use EAP keying
information
> > used to set up network access to later generate keys
for other
> > purposes. Both mobility and network access are at
least valid EAP
> > applications. I recommend that you note that
the question
> of whether
> > this authentication can be reused
is open in your document. I
> > recommend that you get together
with Russ Housley, Jari,
> myself and the EAP
> > community and
decide whether this use is OK before designing a
> > solution that assumes you will be able to do this.
>
>
> > I'm assuming that this problem statement is for a standards
track
> > solution. As such, I don't think considering RFC 4285
is
> appropriate.
> > In particular I don't think it makes sense
for us to base standards
> > trackrequirements on a protocol we were
unwilling to
> standardize. It
> > feels too much like
using the informational RFC series as a
> mechanism
> > for doing
ongoing standards work without meeting our
> requirements for
> >
review. If the working group believes that something like
> RFC 4285
is
> > needed, then the working group should commit to doing the
necessary
> > work to make a standard in this space: write a service
model for
> > Mobile IP security and then write both the
authentication
> protocol and
> > the IPsec security solution as
architectural blocks that fit that
> > model. If the working
group does not want to do this work, then RFC
> > 4285-like solutions
need not influence requirements here.
> >
> > Comment:
>
> The claim in section 5.2.1 that use of certificates would require
>
> deploying a PKI is false. I do agree that certificates do not
align
> > well with AAA. I'd recommend rewording as "Certificates
are
> not easily
> > supported by traditional AAA
infrastructures."
> >
>
> ------ End of Forwarded
Message
Gerardo,
Can you point out the
e-mail where Sam has raised the issue? I'd like to fully understand the
context first.
Alper
From:
Giaretta Gerardo [mailto:gerardo.giaretta at telecomitalia.it]
Sent: Wednesday, August 16, 2006 6:46
PM
To: Alper
Yegin
Cc: mipshop at ietf.org;
Lakshminath Dondeti
Subject:
RE: [Mipshop] RE: Review of
draft-yegin-hmip-sa-00
Hi Alper,
plerase
find below one question about the approach suggested by the draft.
>
> I don't think the NAS should be involved in the
> > key
delivery. My (limited) understanding of 4140
> > tells me that
the MAP is deeper in the network
> > than a typical
NAS
>
> In my understanding, MAP is part of the "access network",
not
> the "home
> network." For that, putting aside the physical
and
> topological aspects, from
> "administrative domain" aspect
NAS and MAP are the part of
> the same network.
>
> > I
am fine with the notion of using a key from the
> > EAP keying
hierarchy for IKEv2
> > authentication. However, I don't think
we should
> > use the MSK for the key derivation. Instead
a
> > key from the EMSK hierarchy might be used.
We
> > can discuss the specifics in detail if you
want.
>
> Why do you think so?
>
As you know, there
were some proposals for MIP6 bootstrapping similar to this, deriving keys from
network access authentication for MIPv6 bootstrapping. These proposals have
not been accepted because there were strong suggestions to keep authentication
procedures for network access services and mobility services separate. In his
review of the MIP6 bootstrapping PS document, Sam mentioned again that these
two authentications must be fully separated.
Since I originally
proposed this approach for MIP6, I am wondering why you think this should be
acceptable for HMIP. Is there any real difference in the scenario in your
opinion?
--Gerardo
> We
proposed use of MSK because we assume MAP and NAS are part
> of the
same
> administrative domain. NAS can generate the HMIP-SA and
pass
> it to the MAP.
> Use of EMSK would have been more
appropriate if MAP were part
> of the home
> network along with
the HAAA server.
>
> Alper
>
>
>
>
>
_______________________________________________
> Mipshop mailing
list
> Mipshop at ietf.org
> https://www1.ietf.org/mailman/listinfo/mipshop
>
--------------------------------------------------------------------
CONFIDENTIALITY
NOTICE
This message and its attachments are addressed solely to the
persons
above and may contain confidential information. If you have
received
the message in error, be informed that any use of the content
hereof
is prohibited. Please return it immediately to the sender and
delete
the message. Should you have any questions, please contact us
by
replying to webmaster at telecomitalia.it.
Thank
you
www.telecomitalia.it
-------------------------------------------------------------------- --------------------------------------------------------------------
CONFIDENTIALITY
NOTICE
This message and its attachments are addressed solely to the
persons
above and may contain confidential information. If you have
received
the message in error, be informed that any use of the content
hereof
is prohibited. Please return it immediately to the sender and
delete
the message. Should you have any questions, please contact us
by
replying to webmaster at telecomitalia.it.
Thank
you
www.telecomitalia.it
--------------------------------------------------------------------
|
