Subject: [mobile-ip] RO between MN-CN using shared secret (issue 146)

From: gabriel montenegro <[email-masked]>
Date: Fri, 08 Nov 2002 12:35:32 +0100

Folks,

There was a lot of debate around issue 146, and at the
end it was left out based on a request from the chairs.
Even though I was away on vacation, I want to go on record
saying that I agree with the decision taken by
Phil and Raj.

This feature is not essential, as RR is already there,
so it obviously could (and can) be specified in a
separate spec.

A decision had to be made, and judging from what we
knew (or thought we knew) at the time, some negative
feedback from security experts (we have since received positive feedback
as well), less than compelling applicability,
and an urgent need to make a decision so rev 19 could
ship, the decision to be conservative and leave it out of the
base spec (at least for the moment) was, I think,
the right one. Comments?

Now that rev 19 is out, IESG review is under way and last
call is soon to start, it is a good time to revisit this issue,
particularly given the possibility of option 2 below.

Here are the options:

1. leave the functionality out of the base spec and let it die.
2. work it into the base spec during LC
3. don't let it die: specify it in a separate document
4. Get feedback from the ADs as to what would the IESG reaction be
    to including this feature up front. Thomas and/or Erik to
    speak up if they see any issue.

I tend to think that #3 is the way to go.

Any other options? Comments?

-gabriel

---

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Nov 2002 08:49:59 -0800

I'm happy with 3.

            jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 08 Nov 2002 10:14:25 -0800

Hello folks,

(3) is better than nothing, but I would like to suggest
that (2) is eminently doable.

As best I could tell, issue #146 was resolved.  Text was
produced for draft 19, and then not submitted, as Gabriel
has alluded to.  In the meantime, new discussion has
occurred, which presumably would have to be resolved
during IETF Last Call.  My belief is that the resolution
would be straightforward -- whether or not is is applied
to a new draft or to text integrated into the base
specification.

The argument for integration into the base specification
will be obvious if one looks at the following text:
         http://people.nokia.net/~charliep/txt/mobilev6/precfg.txt

The Security Considerations section was produced for
draft ...-19.txt, and then pulled out.  There isn't
much else.  Actually, I expect that the most correction
to the draft at the above URL will be applied to make
the Security Considerations longer.

Details such as those would be equally appropriate for
inclusion in the base draft, I think.

Regards,
Charlie P.

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 18 Nov 2002 15:30:28 +0100

Folks,

Based on conversation amongst the chairs, we're
declaring issue 146 resolved on option #3 below.
These were the options:

There are two justifications for this.

First, Hesham Soliman, James Kempf, Michael Thomas and I expressed
preference for #3. Charlie's response was that he prefers #2.

Second, there was also the subsequent AD feedback on the MIPv6 draft
to the effect that some stuff should be taken out of the
draft, as it is too large and complex already. Given that
the LC effort will be to take out non-essential stuff, it follows
that option #2 above to add this feature during the same period
is out of the question. Thomas Narten also expressed as much
when I queried him.

So #3 it is. Interested folks are invited to work on an individual
submission for consideration by the working group. Based on the
response the WG will decide on whether it will become a WG
item.

-gabriel

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 18 Nov 2002 06:40:15 -0800

Hello Gabriel,

A draft is available at the following URL:
    http://people.nokia.net/charliep/txt/mobilev6/precfg.txt

Perhaps not everyone on the list who is interested
realized that you were polling to make a final decision
on this.

Anyway, I submit the document for consideration as a
working group item.  I hope it is not encumbered with
additional protocol features just for the purpose of making
it long enough to "seem" like an Internet Draft.

Regards,
Charlie P.

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 18 Nov 2002 17:28:44 +0100

Hi Charlie,

I don't yet see the document on the ID respository.
Could you please submit it?

tnx,

-gabriel

-- 
Gabriel Montenegro (Sun Microsystems Laboratories, Europe)
180, Avenue de l'Europe          Email: [email-masked]
ZIRST de Montbonnot              Mobile: +33 673 99 56 62
38334 Saint Ismier CEDEX, France
Office: +33 476 18 80 45 (sun internal: x38045)
Fax:    +33 476 18 88 88

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 18 Nov 2002 08:30:45 -0800

Hello Gabriel,

I don't think they're taking submissions just yet.

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 18 Nov 2002 23:07:35 +0100 (CET)

Replay protection for the Binding Authorization Data option
   authentication mechanism is provided by the Sequence Number field
   of the Binding Update.  This method of providing replay protection
   fails when the Binding Update sequence numbers cycle through the
   16 bit counter (i.e., not more than 65,536 distinct uses of Kbm),
   or if the sequence numbers are not protected against reboots.

This statement seems to assume that the CNs treat the binding cache entry
as something different than a cache - at least the sequence numbers need to
be retained even when there is no binding (because the binding has timed out
or the MN has sent a BU to remove the binding).

The draft should at minimum make this very clear.
And the WG needs to understand the implications of this change.

The draft doesn't bring up the issue about the lack of a RR check against
the CoA means that one or more threats that the base MIPv6 protects against
are not handled by this protocol. That makes me very concerned.

The description of the sequence number handling needs to be changed to support
this since you seem to assume that when the sequence number reached 65535 the
CN can not allow it to wrap around (as in the base) since such a wraparound
would allow replayed BUs. 
Is the assumption that the CN refuse further BUs until it has been configured
with a new key? Or something else?

You need to say that the sequence number be initialized to zero when the first
(or a new) key is configured.

Isn't there an attack where an attacker sends a BU with a large
sequence number which makes the CN record that as the number which
future BUs must exceed? Section 9.5.1 can be interpreted
that the expected sequence number is updated before it is verified
that the BU is authentic by saying:
    -  The Sequence Number field in the Binding Update is greater than
       the Sequence Number received in the previous Binding Update for
       this home address, if any.
That seems like an issue in the base spec as well, but it might be able to
cope since it allows wraparounds.

  Erik

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 18 Nov 2002 23:00:58 -0800

Hello Erik,

You have some valid points, and I can make the appropriate
changes to the draft before sending in version ...-00.txt
after the submission process opens again.  The point about
an attacker raising the sequence number too high is not a
concern because the sequence number is only relevant to
a particular mobile node.  A node that would do this would
only affect its own ability to send binding updates to the
correspondent node.

Regarding the threat to the care-of address, the following
text appears in the Security Considerations:

>                                                 This ensures that the
>    sender of a Binding Update can always be uniquely determined.  This
>    is necessary, as this authorization method does not provide any
>    guarantee that the given care-of address is legitimate.  For the same
>    reason, this method SHOULD only be applied between nodes that are
>    under the same administration.
>

This is intended to prevent the problem for which you express concern,
so it isn't right to say that there's nothing about it.  Plus I cite a much longer

draft that goes into details.  Nevertheless, I'd be happy to put in more or
different text that addresses your concern more fully.

Regards,
Charlie P.