Subject: [Mip6] Re: draft-ietf-mip6-precfgkbm-03.txt

From: Margaret Wasserman <[email-masked]>
Date: Sun, 11 Sep 2005 11:29:51 -0400

Hi Charlie,

Do you have an ETA for a revision to draft-ietf-mip6-precfgkbm-03.txt 
that will address the discusses and comments raised by the IESG 
during IESG review?

For everyone's reference, I've included our discusses and comments 
below.  Some of these issues may require discussion by the WG, so I 
have cc:ed the WG above.

Thanks,
Margaret

Ted Hardie:
Comment:
[2005-07-05] 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.

Sam Hartman:
Discuss:
[2005-07-07] 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.

David Kessens:
Discuss:
[2005-07-07] 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.

Comment:
[2005-07-07] 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.

Allison Mankin:
Discuss:
[2005-07-07] 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.

Jon Peterson:
Comment:
[2005-07-06] The Abstract might be a bit more concrete. Unusual way 
of splitting the references...

Margaret Wasserman:
Discuss:
[2005-07-07] Review sent to IESG by Bernard Aboba:

From: Bernard Aboba <[email-masked]>
To: [email-masked]
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.

Bert Wijnen:
Comment:
[2005-07-06]
It seems to me that a normative reference to RFC2119 (use of RECOMMENDED
and MUST) needs to be added. And a citation of course.

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 12 Sep 2005 09:46:40 +0300

Hello all,

I can try to do this within the next week or so.

It's such a simple and obvious idea.  I'm quite
surprised at the combined ability to find issues.
Be that as it may, each issue will receive due
attention and response.  I hope none of my
comments will be interpreted as a challenge to
find even more issues.

I also view this ongoing discussion as a pretty
good explanation about why it was a major error
to delete this simple capability from the text
of RFC 3775 in the first place.

Regards,
Charlie P.

Margaret Wasserman wrote:

> that will address the discusses and comments raised by the IESG during 
> IESG review?
>
> There are other discusses like this, but I'm not sure if they call for 
> specifying the
> [2005-07-06] The Abstract might be a bit more concrete. Unusual way of 
> splitting the references...
>
> Margaret Wasserman:
> Discuss:

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 19 Sep 2005 12:03:01 +0300

Hello folks,

Here are some answers to your questions.

> like a valuable addition.

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

> explain why they are not.

Did you know that the RFC editor's page cannot find BCP 107?

The preconfigured keys draft satisfies the following criteria from
section 2.1:

>       The total volume of traffic over the entire lifetime of the long-
>       term session key will be very low.
>
>       The scale of each deployment is very limited.

I will cite RFC 4086.  The key length is supposed to be at least 160 bits,
which is long enough according to section 2.3.  I will cite RFC 4107
along with some discussion about conformance.

> substantial issue (maybe the security ADs can comment more on this as 

No, because there isn't very much data over the life of
the security association.  If you can suggest some text that
specifies how much data the mobile node should be allowed to
generate before rekeying, I can put that in, but under the
conditions of applicability for the specification I believe there
will not be a problem.

> so this difference should not be relevant though]

In fact, I think that a manual key should be allowed to be longer
than 20 bytes.

> This all boils down to how careful the user is in supplying the Kcn with

Indeed.  I hope this will be clear enough, and any language you
can provide to help will be appreciated.

> to be able to generate/select a sufficiently good value for Kcn,

Done.

> or warning on the randomness requirement of Kcn, and

Done.

>  * Security considerations might include some of this discussion.

Done.

> RFC3562 because the key randomness properties are similar.

I didn't do this, because it seemed to me that RFC 4086 was
really enough!  But if it's _required_ that I do so, please let
me know and I'll stick it in there somewhere.

> [2005-07-07] I received the following comments from Pekka Savola on 

Done.

> something that requires uppercasing.

Done.

> BCP 107 for a sufficiently long key.  BCP 107 may need to be normative 

Done.

> splitting the references...

Please suggest something specific that you would like to see.
I cannot really guess what is too abstract about the abstract.

> discussion be placed earlier in the document, by swapping Sections 2 and

O.K with me, if others are happy with it.

> the HoA.  Otherwise, the statements appear to contradict each other.

Correct.  I added the clarification.

> error when it is configured incorrectly?

This is not a protocol problem.  Presumably, the user interface to
the configuration utility would display an error message.  The probability
of it happening for any particular correspondent node is about 2^(-160),
so I don't think there's too much cause for stress.  I guess the probability
of it _ever_ happening is less than 2^(-100) if the keys are chosen with
the amount of randomness required by RFC 4086, but I might be wrong.

> "keeping track" might just mean keeping a value in memory.

I added "(for example, by committing it to stable storage)"

> be triggered by a negotiation.

What about people that think that preconfiguring keys in this
way is more secure than the results of return routability?

> References

The bibliography section already cited RFC 3775, but a weird
omission in my bibliography database caused the number to
be omitted from the actual text of the citation.

> Comment:

Done.

Regards,
Charlie P.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 20 Sep 2005 09:09:24 +0300 (EEST)

Thanks Charlie for the draft version; it addresses all comments I made 
except one (one text proposal below).

On Mon, 19 Sep 2005, Charles E. Perkins wrote:
>> David Kessens:
>> Discuss:
>> [2005-07-07] I received the following comments from Pekka Savola on the Ops 
>> Directorate that need to be addressed:
>> 

It's OK with that assumption; you added in security considerations:

      [...]  In order to
    assure protection against dictionary attacks, the configured security
    information is intended to be used ONLY for authenticating Binding
    Update messages.

It would probably be a good idea to also put a bullet point on this in 
Applicability Statement, so that it's clear that this option is only 
to be used for BU auth -- because I note that this isn't stated 
explicitly. For example,

  - This mechanism is used only for authenticating Binding Update
    messages (and not e.g., data) so the total volume of traffic
    is low.

(You could also add some extra text referring to the [4] reference 
here to address other IESG comments relating to whether the use of 
manual keying is valid in this scenario if you'd like)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings