Subject: [mobile-ip] Proposed resolution for Issue #146

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 29 Oct 2002 15:42:53 -0800

Hello folks,

When I originally raised this issue, I suggested that:

> The only clarification that I think is needed is that for
> preconfigured binding keys, the Nonce Indices option is truly
> optional.

This is still the main point of clarification, but as noted
below, there have been several other sections identified.
After some discussion about whether or not the mobile node
should prove routability at the care-of address, Hesham
stated:

> Right, and I am suggesting that we clearly say
> "handle with care" when this is used. That's my 
> comment on this issue. If no one else brings other 
> points, I don't have other comments on this.

I took this to mean that the ability to use preconfigured
binding keys should be utilized with clear understanding
of two requirements:

1. The binding key must be specific to a particular mobile
   node and correspondent node, so that there is no vulnerability
   to denial of service at a particular care-of address

Vijay wrote, among other things:

> Replay protection? I change the key every 64000 binding updates.

For this, I add another requirement:

2. If the binding key is used enough times to cause sequence
   number rollover within the lifetime of the association between
   the mobile node and correspondent node, it needs to be changed
   in order to prevent replays. 

While looking through old e-mails, I found another separate
issue.  Regarding what happens when the correspondent node expects
a Nonce Indices option and does not get it, Jaris points out:

> We don't have an error code for this. It's a MUST have
> nonce indices in sect 9.4.1 under 'when using rr', and
> there is no other explanations in the draft what other
> methods are applicable.

So, I propose that we create a new error code for
"Nonce Indices Option required" for cases where the
correspondent node needs it to go forward.

------

I have found the following parts of the specification that could
be clarified or revised for this to be done consistently (using
the section numbers from the intermediate Internet Draft version).

Section 9.7.1 should contain a statement about how the correspondent
node MAY use Kbm to validate the Binding Update

   When a preconfigured Kbm is used to authorize a Binding Update,

   -   The Binding Authorization Data mobility option MUST be present,
       and its contents MUST satisfy rules presented in Section 5.2.6.

    -  The Binding Authorization Data mobility option MUST be the last
       option and MUST NOT have trailing padding.

    -  The Home Registration (H) bit MUST NOT be set.

or, better, these actions should be mandated for USE of a Kbm,
and the previous two bullets used as the specification for how
to _produce_ Kbm:

   When the return routability procedure is used to enable the
   establishment of nonce indices as inputs to the creation of
   the binding key Kbm, the following are also required:

   - (bullet about Nonce Indices taken verbatim)

   - (bullet about regeneration of keygen tokens taken verbatim)

   When using Kbm (preconfigured or newly created) for validating
   the Binding Update, the following are required:

    -  The Binding Authorization Data mobility option MUST be present,
       and its contents MUST satisfy rules presented in Section 5.2.6.

    -  The Binding Authorization Data mobility option MUST be the last
       option and MUST NOT have trailing padding.

    -  The Home Registration (H) bit MUST NOT be set.

The latter is the cleanest solution, requiring minimal new text,
and has the advantage for a very clean separation of function.

-----

The text in Section 13.1 should allow for Kbm to be included
as part of the mobile node's Conceptual Data Structures, for
instance:

   - If configured, a value for Kbm to be used for computing
     authentication data for the Binding Updates to that
     correspondent node.

-----

The text in Section 9.1 should allow for Kbm to be included
as part of the correspondent node's Conceptual Data Structures,
for instance:

   - If configured, a value for Kbm to be used for authorizing
     Binding Updates from that mobile node.

-----

Section 5.2 should note that some nodes MAY support also
preconfigured Kbm:

This can be done by replacing the first sentence:

   Binding Updates to correspondent nodes can be protected by using a  
   binding management key established using data exchanged during the
   return routability procedure.

by:

   Binding Updates to correspondent nodes can be protected by using a  
   binding management key, Kbm.  Kbm may be established using data
   exchanged during the return routability procedure, or in some cases
   it may be preconfigured between certain mobile nodes and
   correspondent nodes.

-----

Section 11.8.2 has a sentence containing the clause:

                          the mobile node SHOULD also start a return
   routability procedure to each other node for which an entry exists
   in the mobile node's Binding Update List,

This clause should be replaced by:

                        the mobile node SHOULD begin processing
   (possibly staring a return routabiliby procedure when no
   binding management key is available) to send a Binding Update
   to each other node for which an entry exists in the mobile
   node's Binding Update List,

This is more to the point anyway, since the Binding Update is
the important part, not the return routability.

-----

The list at the end of section 11.8.2  should contain a bullet
item which states that the mobile node can use preconfigured Kbm
if available to compute the authenticator field.

-----

In section 6.1.8, a new status code:

            138   Nonce Indices option not found

-----

New section 14.4.6:

   A correspondent node and a mobile node MAY use a preconfigured
   binding management key (Kbm) to manage the authentication
   requirements for binding cache management messages (specifically,
   the Binding Update and Binding Acknowledgement messages).
   Such keys must be handled carefully to avoid inadvertent
   exposure to the threats outlined in ~\cite{Aura-Arkko}.

   In particular, a preconfigured Kbm MUST be used to secure
   Binding Updates between only one pair of nodes (viz., a mobile
   node and a correspondent node).  Widespread dissemination of
   such a preconfigured key could possibly lead to loss of
   confidence that the binding management operations are safe
   from actions of malicious nodes that might otherwise have
   gained knowledge of Kbm.

   Replay protection for the Binding Authorization Data option
   authentication mechanism is provided by the Sequence Number
   field of the Binding Update.  This provide protection for
   65,536 distinct uses of Kbm.  If the mobile node were to move
   every hour, 24 hours a day, every day of the year, this would
   require changing keys every 7 years.  Even if the mobile node
   were to move every minute, this would provide protection for
   over a month.  Given typical mobility patterns, there is
   little danger of replay problems; nodes for which problems
   might arise are expected to use methods other than manual
   configuration for Kbm anyway.

------

---

From: Jari Arkko <[email-masked]>
Date: Wed, 30 Oct 2002 02:51:28 +0200

Hello Charlie,

>    to denial of service at a particular care-of address

Is this going to be in the text? I would say "A different key
MUST be used for all the other nodes that this node is in
communication with. " We need a keyword, plus its hard to
dictate a global uniqueness for these keys. Uniqueness
from a single node's point of view suffices.

> correspondent node needs it to go forward.

I would name it "Preshared secret not available"
AND, and would like to state somewhere clearly that
both support and use of this feature is a MAY.

>      authentication data for the Binding Updates to that

Is this under BCE? But BCE is a transient data structure. Do
you need a new, fixed configuration data structure?

>    node's Binding Update List,

I'd say ".. the mobile node SHOULD start a return routability
procedure ... (all of the old text). The mobile node MAY, if
it has a configured binding management key for this correspondent
node, skip this procedure and send a Binding Update directly. Support
for configured binding management keys is optional."

>    from actions of malicious nodes that might otherwise have

You could shorten this. Delete the everything in parantheses. Delete the
sentence that refers to draft-aura. Keep the only-pair clause from
the second paragraph and add ", to ensure that the sender of a Binding
Update can always be uniquely determined. This is necessary, as
this authorization method can 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. The return routability procedure is
RECOMMENDED for all general use and MUST be the default
procedure."

>    configuration for Kbm anyway.

Hmm... doesn't this only apply if you update your non-volatile
memory every time the sequence number is changed? Otherwise
reboots will be a problem, as the nodes may not know what values
they have already used? Would it be easier to just say "This
method does not provide replay protection when the Binding Update
sequence numbers cycle through the 16 bit counter, or if the
sequence numbers are not protected against reboots."

Anyway in conclusion there are a few suggested text modififications
above. The good thing about this new feature is that it can
speed up operations, albeit in limited number of scenarios. It
may also be a good thing to have a second method as a backup of
RR. On the other hand it adds a few special cases to a spec that
is already quite long.

Jari

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 29 Oct 2002 17:30:34 -0800

Hello Jari,

O.K. on most of your suggestions, which I won't include
in this note.  However, on the point about using Return
Routability vs. preconfigured Kbm, I think that if two parties
go to all of the trouble of doing this they probably intend to
use the preconfigured key in preference to one established
by way of return routability.  This is true because the
preconfigured key is _more_ secure than the key created
from combining two pieces of public information.

Thus,

> for configured binding management keys is optional."

Surely, support for the preconfigured keys is optional.  But if that
option is supported and exercised, then for the lifetime of the
preconfigured key I would expect the nodes to use it in preference
to initiating any return routability procedure.

> RECOMMENDED for all general use and MUST be the default

Again, I'm not sure about MUST be the default procedure.

Regards,
Charlie P.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 30 Oct 2002 03:43:56 +0200

> from combining two pieces of public information.

The two methods can't necessarily be ordered in terms of
their security. The security is different, not necessarily
better in one or the other. RR is good in looking after potential
victims at the care-of address, and is good on replay protection.
Preshared Kbm is then again better against on-path attackers.

But about the default: Given that RR was the approach that the
WG chose after much research and discussion, I really think
it is the default. How about

   Return routability procedure is RECOMMENDED for all
   general use and MUST be the default, unless the user
   explicitly overwrites this by entering a key for a
   particular peer.

Jari

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 29 Oct 2002 18:04:04 -0800

Hello Jari,

O.K.  That's about what I meant, anyway...

Regards,
Charlie P.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 29 Oct 2002 18:15:32 -0800

hi Charlie,

I read the proposal. Looks fine to me. But some of Jari Arkko's
comments also made sense. 

in general I think we should go with the following (Jari's text).

> for configured binding management keys is optional."

regards
Vijay