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

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 12 Nov 2004 23:50:41 -0500

> Let me spell out the authorization issue a bit more.  The RA message 
 > tells you what the MAP is.  If you believe the RA is 
 > genuine, you can 
 > presumably believe the pointer; as you note, SEND can help here, but 
 > the Security Considerations needs to point that out.  Beyond that, 
 > though, you still have a problem: how does the MN know what sort of 
 > certificate chain to expect for the MAP?  It will have a 
 > certificate, 
 > of course, but anyone can create arbitrary certificates; I 
 > do that all 
 > the time.  The certificate chain needs to be rooted in some trust 
 > anchor that the MN accepts.  (This was an issue for SEND, 
 > too -- when I 
 > sit down in my local hotspot, how do I know the certificate 
 > for the RA 
 > is for the real router and not my evil neighbor's laptop.)  This 
 > problem needs to be discussed, and is discussed in the SEND draft.
 > 
 > I've added this to the DISCUSS ballot.

=> Understood. The assumption here is that the MN is configured
with a set of trusted CAs. Does this need global PKI? No it doesn't.
Today operators have existing agreements and configurations that
allow mobiles to roam globally. Part of this agreement would be to
configure MNs to accept certain certificates. So it's not an arbitrary
certificate. Of course if the MN chooses to accept an arbitrary
certificate then it's responsible for the consequences. 
I agree with you that this is not spelt out in the security considerations
section. If this explanation makes sense then I'll add it in the 
draft.

 > 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.

thanks for the follow up

Hesham

 > 
 > 		--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: "James Kempf" <[email-masked]>
Date: Mon, 15 Nov 2004 09:08:14 -0800

Hesham,

thanks for the follow up

jak>>> This seems to imply that the MN has a certificate. Is that what you
mean? SEND doesn't require the MN to have a certificate because provisioning
of an arbitrary host with a certificate has, in general, turned out to be a
difficult problem to solve, though in certain very specfic cases it has been
possible. That is no reason not to include such a requirement here, but it
does mean that deployment possibilities are limited. Alternatively, one
could require a CGA and use that as authorization for the address change,
but that would be limiting address configuration in a way that might have a
similar dampening impact on deployment prospects as requiring certificates.

jak>>> I think it more likely that an AAA mechanism would be more
deployable, though the issue there is interaction between the mobile and the
foreign access network. This is not very well defined in current AAA
interactions, as most assume an end to end connection with the home AAA
server via EAP, with the foreign AAA server acting as an overlay router and
receiving instructions from the home AAA server.

jak>>> If it is acceptable to the IESG, perhaps the question of exactly how
to achieve host to network authentication could be left as an open question
for MOBOPTS, as was done with FMIP?

                    jak

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 15 Nov 2004 09:47:00 -0800

> for MOBOPTS, as was done with FMIP?

Yes, it is acceptable to the IESG. We asked this specific question proactively
when we went through the charter approval process.

 From the mipshop charter at
http://www.ietf.org/html.charters/mipshop-charter.html

> There are security issues that arise because of the highly dynamic
> nature of the security relationships between, say, a mobile node and
> its mobility anchor points, or between a mobile node and its access
> routers in a fast handover scenario. The working group is not required
> to provide solutions to all these issues before publishing its
> experimental and informational protocols. The working group will
> document the security requirements and the shortcomings of the
> solutions in the corresponding protocol specifications. This will
> provide valuable feedback to other groups or subsequent efforts.

-gabriel

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 15 Nov 2004 12:50:19 -0500

In message <[email-masked]>, "James Kemp
>messages would be done afterwards using IPsec.

That's a perfectly fine answer -- the document just has to say so.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 15 Nov 2004 12:51:05 -0500

>> provide valuable feedback to other groups or subsequent efforts.

Sure, that works, but that's not what the I-D says now.  All I was 
asking for on that was consistency.