Securing Mobile IPv6 Route Optimization Using a Static Shared Key
draft-ietf-mip6-precfgkbm-04

[Ballot comment]
I think I'm confused. The document says in the Introduction:

  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.

In the applicability statement, it goes on to say:

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

But the Security Considerations don't contain any details about what happens
if this trust is misplaced.  draft-ietf-mip6-ro-sec-03 has quite a taxonomy
of potential issues; I would have thought that a basic run-through of those
would be useful.  Not that it needs to go through the whole document, but
a statement about whether any existing consideration (one of the flooding
attacks?)  are worsened by this approach or that none are would seem
like a valuable addition.


Charlie responded:

do not agree with this.  It would be wrong to repeat the contents of
draft-ietf-mip6-ro-sec-NN here, and there isn't any real relevance.  The
point of the document is to provide a good way to secure Binding Updates,
and in fact my major complaint with draft-ietf-mip6-ro-sec-NN was that
it often seemed to imply that Mobile IPv6 was vulnerable to situations
caused by insecure Binding Updates.  That would be wrong, because a
crucial point of the design of Binding Update was to ensure security.
The cited document did not make that clear enough in my opinion, and
as a result people would run around acting very worried.  Keep in mind
that the cited Internet Draft was written _years_ after the Binding
Update was well-secured, so that this raised quite unwarranted fears.

Nevertheless, if you would like to see some specific text in the current
document under discussion, please send it to me and I reckon it would
go in, as a way of eliminating concerns from future readers with similar
worries.

[Ballot comment]
My Discuss is handled in to-come 04 (pretty simply because I just asked for a normative ref and didn't
say how to couch it); I clear in advance because Sam added a more detailed Discuss related to BCP 107
issues after mine. 

(I replied on Oct 3 to email from Basavaraj Patil dated Sep 29, to all the Discussant ADs and author)

From that mail:
>
> Allison Mankin:
> Discuss:
> [2005-07-07] I'll put in this Discuss because of Russ's absence.  My=20
> attention has been drawn for some
> Transport documents to the expertise in BCP 107 (RFC 4107), and=20
> especially given the fact that
> there is self-definition of the applicability of the trust model for=20
> this usage, the manual keys
> here at least seems to me to need to meet the cryptographic=20
> requirements in BCP 107, such as:
>
>  When manual key management is used, long-term shared secrets MUST be
>  unpredictable "random" values, ensuring that an adversary will have
>  no greater expectation than 50% of finding the value after searching
>  half the key search space.
>
> There are other discusses like this, but I'm not sure if they call for

> specifying the
> key generation procedure to ensure randomness.  There's also a SHOULD
in
> BCP 107 for a sufficiently long key.  BCP 107 may need to be normative

> here.

Done.

[Ballot discuss]
Allison points out that this document uses manual key management in
the sense of BCP 107.  That BCP requires explicit justification for
manual key management.  Please go through the analysis in BCP 107 and
explain why manual key management is used.  Also, please examine the
guidance in section 2.3 and make sure that these guidelines are met or
explain why they are not.

[Ballot discuss]
Review sent to IESG by Bernard Aboba:

From: Bernard Aboba
To: iesg@ietf.org
Subject: Review of draft-ietf-mip6-precfgkbm-03.txt

Overall, I do think it makes sense to have a pre-configuration option for
route optimization, if only for testing purposes.  The document does
include discussion of applicability, ableit in Section 3 (I'd suggest this
discussion be placed earlier in the document, by swapping Sections 2 and
3).

Section 1:

This section is somewhat unclear about the security properties as
compared to RFC 3775.  In particular, there are two statements that appear
ambiguous:

"In addition, the right to use a specific address is assured in a stronger
manner than in [1]."

and

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

My assumption is that the address referred to in the first statement is
the HoA.  Otherwise, the statements appear to contradict each other.

Section 4

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

What is the correspondent node supposed to do if it finds that more than
one mobile node has the same value of Kcn?  Is there an error message that
is supposed to be sent, or is the implementation supposed to flag this
error when it is configured incorrectly?

"  Given typical mobility patterns, there is little danger of replay
  problem"

I think this assumes that the replay counter is committed to stable
storage.  This requirement is not stated explicitly in the document;
"keeping track" might just mean keeping a value in memory.

"  Note that where a node has been configured to use the mechanism
  specified in this document with a particular peer, it SHOULD NOT
  attempt to use another mechanism, even if the peer requests this
  or claims to not support the mechanism in this document.  This is
  necessary in order to prevent bidding down attacks."

Actually "bidding down" attacks are prevented by verifying that the nodes
have negotiated the highest possible security level.  It would appear that
this advice requires that the MN and CN use preconfiguration, even if a
higher level of security is available.  Given the use of this draft in
testing, I think the issue is not "bidding down" per se, but more one
of reproducibility.  You'd want preconfiguration to be used so that a
particular code path can be tested, and not some other path that might
be triggered by a negotiation.

References
----------

RFC 3775 has been assigned an RFC #, so it can be cited.  Typical practice
is to have a different subsection for normative and informative
references.

[Ballot discuss]
I'll put in this Discuss because of Russ's absence.  My attention has been drawn for some
Transport documents to the expertise in BCP 107 (RFC 4107), and especially given the fact that
there is self-definition of the applicability of the trust model for this usage, the manual keys
here at least seems to me to need to meet the cryptographic requirements in BCP 107, such as:

  When manual key management is used, long-term shared secrets MUST be
  unpredictable "random" values, ensuring that an adversary will have
  no greater expectation than 50% of finding the value after searching
  half the key search space.

There are other discusses like this, but I'm not sure if they call for specifying the
key generation procedure to ensure randomness.  There's also a SHOULD in
BCP 107 for a sufficiently long key.  BCP 107 may need to be normative here.

I'm sorry if this did not come up in the working group - the BCP has been in an
approved status for quite a long time, though the RFC publication was recent.

[Ballot comment]
I received the following comments from Pekka Savola on the Ops Directorate:

minor editorial issues
----------------------

  When a Binding Update is to be authenticated using such a
  precomputable binding key (Kbm), the Binding Authorization Data
  suboption MUST be present.  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].


==> "MAY be ignored" ?  What is the alternative?  Shouldn't this
be "MUST be ignored" or "SHOULD be ignored"? (This seems like an
editorial issue, because AFAIR "may be ignored" in English can be
interpreted with at least two levels of normativeness)

  A correspondent node and a mobile node MAY use a precomputable
  binding management key (Kbm) to manage the authentication
  requirements for binding cache management messages.

==> I'd replace "MAY" with "may", because this doesn't seem to be
something that requires uppercasing.

[Ballot discuss]
I received the following comments from Pekka Savola on the Ops Directorate that need to be addressed:

substantial issue (maybe the security ADs can comment more on this as needed)
-----------------

(I believe this can be easily addressed with a little bit of text
tweaking.)


  There is no upper bound on the lifetime defined for the precomputable
  Kbm.  As noted, the key is very likely to be quite secure over the
  lifetime of the security association and usefulness of applications
  between a mobile node and correspondent node that fit the terms
  specified in section 3.

==> this is the only place (AFAICS) that even touches the topic of the
security properties of a manually configured Kcn.  With RFC3775, Kbm
is generated by hashing a number of changing inputs together, so it
can be guaranteed to have be pretty unique, and have pretty good
randomness properties against brute-force or dictionary attack
attempts.

On the other hand, this specification proposes a manually configured,
static secret of (at least) 20 bytes.  Further, it seems that the
expectation is that the statically configured key never changes.
This seems to make the key significantly more vulnerable to dictionary
and other attacks compared to RFC3775.

[an aside observation: RFC3775 specifies that Kcn MUST be exactly 20
bytes; this says at least 20 bytes.  Kcn is munged by a hash function
so this difference should not be relevant though]

This all boils down to how careful the user is in supplying the Kcn with
sufficient randomness.

As this is going on Standards Track, I believe some additional warnings
should be needed; for example:

* The assumptions should explicitly mention that the users are assumed
to be able to generate/select a sufficiently good value for Kcn,

* Section 2, when discussing Kcn, should explicitly give a recommendation
or warning on the randomness requirement of Kcn, and

* Security considerations might include some of this discussion.

It might also be worth considering adding an informative reference to
RFC3562 because the key randomness properties are similar.

[Ballot comment]
It seems to me that a normative reference to RFC2119 (use of RECOMMENDED
and MUST) needs to be added. And a citation of course.

[Ballot comment]
I think I'm confused. The document says in the Introduction:

  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.

In the applicability statement, it goes on to say:

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

But the Security Considerations don't contain any details about what happens
if this trust is misplaced.  draft-ietf-mip6-ro-sec-03 has quite a taxonomy
of potential issues; I would have thought that a basic run-through of those
would be useful.  Not that it needs to go through the whole document, but
a statement about whether any existing consideration (one of the flooding
attacks?)  are worsened by this approach or that none are would seem
like a valuable addition.

Review from Jari Arkko:

From: Jari Arkko
To: Margaret Wasserman
Cc: Jari Arkko
Subject: Re: draft-ietf-mip6-precfgkbm-01.txt

Margaret, Sam,

I have reviewed this draft and sent my comments to the mip6
list. Copied below for your convenience. --Jari

-----

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"

LC Review Comments from Jari Arkko:

From: Jari Arkko
To: mip6@ietf.org, Charlie P
Cc:
Subject: [Mip6] mip6-precfgkbm-01.txt review

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
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6

Mail sent to Sec ADs requesting review:

To: Sam Hartman , Russ Housley
From: Margaret Wasserman
Subject: draft-ietf-mip6-precfgkbm-01.txt
Cc:
Bcc:
X-Attachments:


I have just sent draft-ietf-mip6-precfgkbm-01.txt to IETF LC.  This is a very short document that talks about how to precompute binding management keys (Kbm) for MIP6.  The document itself seems fairly straightforward, but I am concerned that it may have wider repercussions.

I am not really qualified to evaluate the impacts (if any) of precomputed keys on the MIP6 security model.  Is there someone in your area (perhaps in one of your directorates or something) who could be asked to do a thorough review of this document, including a review of how/if it impacts the overall MIP6 security model?

If you can find someone to do this and that person needs more than two weeks to complete the review, let me know and I will hold the document for that review after LC.

Thanks,
Margaret