Subject: RE: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-0 0.txt

From: Phil Roberts <[email-masked]>
Date: Tue, 17 Jul 2001 13:22:06 -0400

Hi,

> The requirements presented are so directly related to cryptography.
> The word "authorized" is used extensively.  I was wondering if it is
> possible to include requirements that are more "functional" in nature
> and that would allow solutions that do not rely necessarily on crypto.
> 
> For example, the wireless broadcast would allow the MN to overhear
> when a BU with its Home Address were sent by an attacker.

I'm not sure exactly what you're asking here.  This sounds like something
that belongs in the threat model, and in fact I believe there is something
like it in sec 6.2.

Could you explain what the functional requirement is that you'd like
to add?

> 
> Another example is that the AR's usually trust each other and thus
> might easily exclude an unauthorized AR.

Do you mean exclude an unauthorized BU?  And I'm not sure how ARs
with trust relationships impact messages received by visiting MNs.

Phil

> Just wondering,
> Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: 18 Jul 2001 10:51:29 +0200

> that belongs in the threat model, and in fact I believe there is something

What I'm proposing is that when the MN overhears a BU with the same
Home Address option that was not sent by itself it could be required
to "stop" communication.  If the attacker wanted to become an MITM
then at least the MN will be protected.  That does not rely on
authorization mechanisms, but on capacity to overhear.

Again in case B, when AR forwards a BU from MN and the
corresponding BAck from CN it could forbid subsequent attacker BU with
the same HoA and different CoA.

> with trust relationships impact messages received by visiting MNs.

I meant "unauthorized AR".  If attacker adds new AR by attaching to
the same point where the other AR's are attached (and not by DR'ing to
an existing AR as in threat B.3) then it should be the trust
relationships between existing AR's that will exclude the attacker AR.

The threat of attaching an AR as described above could probably be
added as Threat B.4.

Alex

---

From: Claude Castelluccia <[email-masked]>
Date: Mon, 23 Jul 2001 16:36:28 +0200

Hello,

This is a very interesting draft ... too bad that the privacy issues are not
addressed...
Anyway i think that requirement H.3 should be:

 "CNs MUST NOT process any packet (BU or not) containing a Home
   Address option unless they have verified that that the node sending the
packets
   is authorized to use the home address in the destination option:

  In fact the MIPv6 draft says :
  "A node receiving a packet
   that includes a Home Address option MAY implement the processing of
   this option by physically exchanging the Home Address option field
   with the source IPv6 address in the IPv6 header."

    An attacker can then easily use a CN as a packet reflector with current
MIPv6...
    it only needs to send packets with a home address option containing the
victim address to several CNs...
    CNs will exchanged the source IPv6 address with the vicitim address and
reply to the victim ...NO Binding entrie
   is necessary for this attack...

   Am i missing something?

    thanks,

    Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/