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

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 12 Nov 2004 11:56:34 -0500

In message <[email-masked]
>, "Soliman, Hesham" writes:
>Steve, 
>
>Thanks for your comments. Your comment and responses
>below.
>
>
>>	The Security Considerations section says:
>>
>>  It is crucial
>>  that the security relationship between the mobile node and the MAP is
>>  of strong nature; it MUST involve mutual authentication,
>
>>but there is no hint of how this can be done.  In particular, how does the mo
>bile node know >that the MAP is *authorized* for that role?  This is much wors
>e than the ordinary MIPv6 
>>situation, since in the normal case you're dealing with an on-link forwarder 
>where the 
>>added risk is low.  (The risk is high, but the added risk from MIP is low, an
>d SEND helps 
>>with the normal risk -- but not for this.)  
>
>=> I'm not sure why you think it's worse than normal MIPv6. Let me 
>explain why I don't think it's worse. The SA established between
>the MN and the MAP is currently using IKE. Of course this can be 
>done using preconfigured keys or dynamically. Preconfigured keys
>are probably not workable in the general case so let's focus on 
>the dynamic scenario. It involves the following:
>
>1. Discovering the IP address of the MAP
>2. Negotiating the SA using IKE (exchanging certificates)
>3. Establishing the SA
>
>I'm guessing you refer to step 1. The IP address is learnt
>from the RA. If the question is: how do we know the RA
>came from a real router and not a rogue one? Then the answer 
>is either: a) the MN is on a point to point secure link (e.g.
>cellular) or b) on a shared link with no link layer security. 
>If b) then SEND can be used, however, this is a general problem
>not specific to this proposal. 
>Once this step is achieved then steps 2 and 3 should be 
>ok. Did I understand your concern correctly?

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.
>
>
>>I don't expect a solution in this document, but 
>>the problem needs to be discussed.  I believe there's some good text in one o
>f the SEND >
>>documents that can be used.
>
>>Beyond that, the document also says "the MAP does not need to know the identi
>ty of the 
>>mobile node".  This contradicts the previous statement about mutual authentic
>ation.  I 
>>believe I know what they mean, but it isn't clearly enough expressed in the d
>ocument.
>
>=> Sure, this can be changed to
>   "The MAP need not have any prior knowledge of the mobile node's
>    identity"
>How's that?
>

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.

		--Steve Bellovin, http://www.research.att.com/~smb

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

---

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

> jak>>> This seems to imply that the MN has a certificate. Is 
 > that what you
 > mean? 

=> Yes, for dynamic keying to work.

  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. 

=> This has nothing to do with SEND. The question was how 
the MAP and MN trust each other. SEND ensures that the RA
is secure, but for the MAP and MN to trust each other
certs are needed.

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

=> AAA can certainly be another option, I have no problem with
that. But today it doesn't exist.

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

=> It may be, but there is no reason to discount the 
current solution in the draft...

Hesham

 >                     jak

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