Subject: [Mip6] mip6-precfgkbm-01.txt review

From: Jari Arkko <[email-masked]>
Date: Sun, 15 May 2005 23:41:20 +0300

Hi Charlie,

As a part of ongoing last call I have reviewed this draft.

Overall:

- This is a solid draft and, with some modifications, should
  move forward. Its never been my big favorite due to its
  limited applicability, but it is also very efficient where it
  works. More efficient than pretty much anything else
  anyone has come up with in this space, so...

- I found a few areas where you could give more information
  and context to the reader, e.g., explaining the difference
  and impacts of using this vs. RFC 3775 mechanisms.

- I'm not too happy about all the details in the applicability
  statement text, but I have provided alternative suggestions.

Substantial:

- The title, "Precomputable Binding Management Key Kbm
  for Mobile IPv6" is correct, but at least to me, also not very
  descriptive from the point of view of what people want from
  this. What I think most people are interested to hear about
  is that if you have a preconfigured secret then you can use
  this draft for an efficient form of RO security.

  Suggestion: change title to "Securing Mobile IPv6 Route
  Optimization Using a Shared Key".

- Similarly, I think the introduction could say a few words
  to the reader on how this is different wrt base route
  optimization security. Suggested text below.

  "0. Introduction

       This specification introduces an alternative,
       low-latency security mechanism for protecting
       signaling related to the route optimization in
       Mobile IPv6. The default mechanism specified
       in [1] uses a periodic return routability test
       to verify both the "right" of the mobile node
       to a use a specific home address,  as well as
       the validity of the claimed care-of address.
       This mechanism requires no configuration and
       no trusted entities beyond the mobile node's
       home agent.

       The mechanism specified in this specification,
       however, requires the configuration of a shared
       secret between mobile node and its correspondent
       node. As a result, messages relating to the
       routability tests can be omitted, leading to significantly
       smaller latency. In addition, the right to use a specific
       address is assured in a stronger manner than
       in [1]. On the other hand, the applicability
       of this mechanisms is limited due to the need
       for pre-configuration. This mechanism is also
       limited to use only in scenarios where mobile nodes
       can be trusted to not misbehave, as the validity
       of the claimed care-of addresses is not verified."

- Details about replay protection. The draft says

>    For this reason, a correspondent
>    node that uses a precomputable Kbm also MUST keep track of the most
>    recent value of the Sequence Number field of Binding Update messages
>    using the precomputable Kbm value.

  I would be interested in knowing whether this MUST requires
  you to keep the sequence numbers in nvm storage or if the
  intent is to only require this on a per-boot basis. The draft
  might benefit from slight text changes depending on the
  answer to this question. For instance, per-boot semantics
  are OK then s/MUST/SHOULD/ might be appropriate. Otherwise
  the text should probably be explicit about the requirement
  to do this with nvm storage.

- Behavior in a misconfiguration or delayed configuration
  cases. The draft says...

>    The Nonce Indices option SHOULD NOT
>    be present.  If it is present, the nonce indices supplied MAY be
>    ignored and are not included as part of the calculation for the
>    authentication data, which is to be carried exactly as specified
>    in [1].

  However, this implies that if the preshared secret configuration
  is entered to the correspondent node but not yet to the mobile
  node, both preshared approach and base Mipv6 procedure will
  fail.

  I think this is in fact correct, due to the need to avoid
  bidding down attacks to base mechanism. But this
  could be explicitly stated somewhere, maybe in Section 3.

- Requirements for assignment of keys. The draft says:

>     -  the method of assignment for keys between the correspondent node
>        and mobile node results in a stronger security association than
>        what can be provided by the Return Routability procedure.

  This seems a bit weak, imho. It seems to imply that there
  are different methods to assigning the keys and we are not
  being told what they are. I would rather simply require that
  there must be per-mobile node preconfiguration of the
  required data (and I see that in Section 3 you already
  prohibited group keys, good...).

  This would also make it less likely that someone misuses this
  draft in ways it was not intended to be used.

- Nits on applicability stament. The draft says:

>     -  diagnostic procedures
>     -  software development and testing

  I would delete these. Of course anything can be
  used for diagnostics.

- Overall applicability text. Given the above comments,
  I wanted to see if I could come up with some suggested
  text. Here's my attempt:

   "This mechanism is useful in the specific scenario where the following
   conditions are all met:

   -   Mobile node and correspondent node are administered within
       the same domain.

   -   The correspondent node has good reason to trust the actions
       of the mobile node. In particular, the correspondent node
       needs to be certain that the mobile node will not launch
       flooding attacks against a third party as described in
       [2, draft-ietf-mip6-ro-sec].

   -   The configuration effort related to this mechanism
       is acceptable.

   -   There is a desire to take advantage of higher
       efficiency or greater assurance with regards to
       the correctness of the home address offered via
       this mechanism.

   Generally speaking, the required level of trust that the
   correspondent node needs for enabling a precomputable Kbm with a
   mobile node is more often found within relatively small, closed
   groups of users who are personally familiar with each other, or who
   have some external basis for establishing trustworthy interactions.
   A typical example scenario where this mechanism is applicable is
   within a corporation, or between specific users. Application in the
   general Internet use is typically not possible due to the
   configuration effort. Application at a public network operator
   is typically not possible due to requirements placed on the
   trustworthiness of mobile nodes."

- Is there any change wrt the lifetime of bindings created
  through this mechanism vs. RFC 3775? Seems like they
  could be higher.

Editorial:

- Citations

>    The first citation is normative, and the second citation is
>    informative only.

   I'd prefer separate lists, most I-D tools should generate
   them. Don't worry about this if your tool has trouble,
   however.

- Missing space?

> abovementioned

- Change

> very, very

  to just "very"

--Jari

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

---

From: Thomas Narten <[email-masked]>
Date: Mon, 16 May 2005 15:02:18 -0400

Thanks Jari for the review.

Some followup on your comments (I've just read the document as well).

>   Optimization Using a Shared Key".

I'd go a bit further and add "static" or "pre-configured" to "Shared
Key". Or is the former assumed when the term "shared key" is used?

>   optimization security. Suggested text below.

I definitely agree.

>        This specification introduces an alternative, low-latency
>        security mechanism for protecting signaling related to the
>        route optimization in Mobile IPv6. The default mechanism
>        specified in [1] uses a periodic return routability test to
>        verify both the "right" of the mobile node to a use a
>        specific home address, as well as the validity of the claimed
>        care-of address.  This mechanism requires no configuration
>        and no trusted entities beyond the mobile node's home agent.

>        The mechanism specified in this specification, however,
>        requires the configuration of a shared secret between mobile
>        node and its correspondent node. As a result, messages
>        relating to the routability tests can be omitted, leading to
>        significantly smaller latency. In addition, the right to use
>        a specific address is assured in a stronger manner than in
>        [1]. On the other hand, the applicability of this mechanisms
>        is limited due to the need for pre-configuration. This
>        mechanism is also limited to use only in scenarios where
>        mobile nodes can be trusted to not misbehave, as the validity

I think the above is good, and it would have saved me some thinking
had I read it before reviewing the document!

Actually, I view that last part of the above as quite significant.
There may also be problem related to broken implementations and such,
if a CN has a binding cache entry with a long time out that is no
longer correct (e.g., a COA address has been assigned to another
node).

Think also about a hacked cell phone that is able to do a DOS attack
on a specific server/host pair.

>    trustworthiness of mobile nodes."

This (IMO limited) applicability makes me wonder if we should publish
this as experimental rather than standards track.

Thomas

---

From: "Charles E.Perkins" <[email-masked]>
Date: Mon, 16 May 2005 12:53:36 -0700

Hello Jari,

>   Optimization Using a Shared Key".

O.K. with me, if no one else objects.

>        of the claimed care-of addresses is not verified."

This is all O.K. with me, and I'm happy to use it.

>   to do this with nvm storage.

The mobile device ought to avoid re-using old sequence
numbers, and the best way I know of is to store them across
reboots.  I think that "SHOULD" is O.K., as long as designers
are aware of the downside.  That is, if the sequence number
is not stored, then:
- a new key would have to be configured at both devices, or
- the correspondent node would reject future binding updates, or
- replays would be possible.

>   could be explicitly stated somewhere, maybe in Section 3.

Do you mean that the draft ought to point out what
happens if the correspondent node is not yet configured?
I could just use your paragraph for that...

>   being told what they are.

Well, this is exactly right, though.  Why is it "weak"?
Would you prefer that I omit this bullet?

?                     I would rather simply require that
>   prohibited group keys, good...).

The draft already does say this in section 3:

   A mobile node MUST use a different value for Kcn for each node in
   its Binding Update List, and a correspondent node MUST ensure that
   every mobile node uses a different value of Kcn. 

Does it need more?

>   I would delete these. Of course anything can be

I can delete them, but I don't agree with your statement!

>    trustworthiness of mobile nodes."

This is fine with me.  I can replace section 2 in
its entirety by this text.

>   through this mechanism vs. RFC 3775? Seems like they

The idea is that binding lifetimes can be a lot higher.
The vulnerabilities (small as they are) associated with
return routability are not present.

> > abovementioned

This is a word.  Do you prefer having two words instead?

>   to just "very"

O.K., but I also think that
"very, very" is correct.

Regards,
Charlie P.

---

From: "Charles E.Perkins" <[email-masked]>
Date: Mon, 16 May 2005 13:07:01 -0700

Hello Thomas,

> Key". Or is the former assumed when the term "shared key" is used?

O.K.  "Shared key" does NOT imply preconfigured -- for instance,
AAA can distribute shared keys.

> longer correct (e.g., a COA address has been assigned to another

This seems to be a low-probability event in IPv6.

...

> this as experimental rather than standards track.

I think we already have a lot of experience with this, and
know that it works.  It was, after all, the _only_ method
available until the return routability was devised, and it
was deleted from the base specification only at the last
minute, sigh.  What is the rationale for experimental?
It is already well laid out exactly what that applicability
is for the specification.  The behavior is easier to predict
than RFC 3775.  I think it should be published as a Proposed
Standard.

Regards,
Charlie P.

---

From: Thomas Narten <[email-masked]>
Date: Mon, 16 May 2005 16:12:59 -0400

Hi Charlie.

> AAA can distribute shared keys.

Good point!

> This seems to be a low-probability event in IPv6.

I think arguing either way requires making assumptions, and I don't
know that either set of assumptions will prove correct ten years from
now...

> I think we already have a lot of experience with this, and know that
> it works.  It was, after all, the _only_ method available until the
> return routability was devised, and it was deleted from the base
> specification only at the last minute, sigh.  What is the rationale
> for experimental?  It is already well laid out exactly what that
> applicability is for the specification.  The behavior is easier to
> predict than RFC 3775.  I think it should be published as a Proposed
> Standard.

To be clear, I'm somewhat on the fence. I agree that PS is correct
from the perspective of "it works, it's been vetted for
interoperability, it can advance up the standards track, and if you
are going to implement something like this, this protocol is what you
should implement...". Ooops, I think I just argued for PS. :-)

The signal I don't like to send is that this (because it is a
standard) is something everyone should implement. And PS sometimes
does that. So, if the applicability statement is clear and accurate, I
think that would address my concern adequately.

Thomas

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 May 2005 18:13:40 +0300

>>AAA can distribute shared keys.
I would actually rather see this draft and its security
considerations focus on the preconfigured case.

Of course we may develop a AAA mechanism to deliver
keys for this at a later stage. But I'm uneasy with claiming
generality to new situations without seeing the system
level specifications of how that works and why its
efficient/good idea/secure etc.

Keep it simple, and short. Work on add-ons and new
documents later if you want AAA to key this.

--Jari