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

[Margaret Wasserman <[e-mail]>]

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 <[e-mail]>
To: [e-mail]
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/mip6