Subject: RE: [Mipshop] RE: Review of draft-yegin-hmip-sa-00

From: "Giaretta Gerardo" <[email-masked]>
Date: Thu, 7 Sep 2006 12:07:03 +0200

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 <[email-masked] <mailto:[email-masked]> >
> > Date: Wed, 01 Mar 2006 16:03:22 -0500
> > To: < [email-masked] <mailto:[email-masked]> >
> > Cc: <[email-masked] <mailto:[email-masked]> >, <[email-masked] <mailto:[email-masked]> >
> > 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

________________________________

	From: Alper Yegin [mailto:[email-masked]] 
	Sent: martedì 22 agosto 2006 20.10
	To: Giaretta Gerardo
	Cc: [email-masked]; 'Lakshminath Dondeti'
	Subject: RE: [Mipshop] RE: Review of draft-yegin-hmip-sa-00

	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:[email-masked]] 
	Sent: Wednesday, August 16, 2006 6:46 PM
	To: Alper Yegin
	Cc: [email-masked]; 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
	> [email-masked]
	> https://www1.ietf.org/mailman/listinfo/mipshop <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 [email-masked] <mailto:[email-masked]> .
	        Thank you
	                                        www.telecomitalia.it <http://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 [email-masked].

        Thank you

                                        www.telecomitalia.it

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