Subject: RE: [Mipshop] RE: IESG evaluation - Steve Bellovin's comments

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 15 Nov 2004 13:40:03 -0500

Thanks, I'll update the security section to do this
and resubmit the draft.

Hesham

 > -----Original Message-----
 > From: Steven M. Bellovin [mailto:[email-masked]]
 > Sent: Monday, November 15, 2004 12:50 PM
 > To: James Kempf
 > Cc: Soliman, Hesham; [email-masked]; [email-masked];
 > [email-masked]
 > Subject: Re: [Mipshop] RE: IESG evaluation - Steve 
 > Bellovin's comments 
 > 
 > 
 > In message 
 > <[email-masked]>, "James Kemp
 > f" writes:
 > >Hesham,
 > >
 > > > The problem here is the converse of the earlier point: how
 > > > does the MAP
 > > > know that it's talking to the "right" MN?  You can't authenticate
 > > > someone if you have no a priori knowledge of whom they
 > > > should be.  Do
 > > > you mean "the same as last time"?  "Someone whom I've 
 > authorized via
 > > > AAA"?  You say "no prior knowledge", and that's fine, but
 > > > then you need
 > > > to clarify how the MAP can authenticate such a party.
 > > >
 > > > Again, I've added this to my DISCUSS comments.
 > >
 > >=> I guess the same answer would apply here? The MAP is configured
 > >to accept certain certificates. This is the only knowledge needed
 > >to authorise a MN to use the MAP "service". Authentication of
 > >messages would be done afterwards using IPsec.
 > >
 > 
 > That's a perfectly fine answer -- the document just has to say so.
 > 
 > 		--Steve Bellovin, http://www.research.att.com/~smb
 > 
 > 
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 17 Nov 2004 11:49:31 -0800

hello all,

I read through the thread and dont agree with some of the
assumptions.

the current HMIPv6 document seems to the say the security
between MN and the MAP (to protect the binding updates) is
the same the security between MN and the HA. that is wrong.
in MIPv6, the HA needs per-mobile state to authenticate and
authorize the MN. since there is one HA per MN, this is
do-able. for HMIPv6, this is not true. the MN could attach
to many different MAPs. this would require a way for each
MAP to authenticate (and authorize) any MN that attaches to
the visited network. each MN should also be able to
authenticate any MAP that it might attach to. this is
do-able too, but the document needs to point out this
significant difference and not just equate it to MIPv6
security.

similarly, it is not correct to equate security between MN
and the MAP to security between MN and the AR. in most cases,
the MN needs to authenticate itself to the access network.
and in most cases, some state is created on the access
routers. a MAP is an element that sits beyond the access
routers. SEND could be used between the MN and the AR. but
I dont see how SEND can be used beween the MN and the MAP.

it would be better not to equate security between MN and the
MAP to either security between MN and the AR or security
between MN and the HA. HMIPv6 security considerations should
point this out clearly.

between the MN and the HA, one could use shared secrets with
IKE in addition to certificates. but between the MN and the
MAP, I dont see shared secretes being used. you probably
need certificates, which means, that unless the MAP is able
to verify the certificate presented by the MN, the MN wont
get HMIPv6 service. similarly, unless the MN can verify the
certificate presented by the MAP, it cant use HMIPv6.

Vijay

---

From: Alper Yegin <[email-masked]>
Date: Wed, 17 Nov 2004 15:51:36 -0800

> certificate presented by the MAP, it cant use HMIPv6.

Using the MIP6-AAA interface discussed in
draft-yegin-mip6-aaa-fwk-00.txt is another solution to this problem.

Alper