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

["Charles E. Perkins" <[e-mail]>]

Hello folks,

Here are some answers to your questions.

Margaret Wasserman wrote:

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

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.

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

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.

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

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.

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

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
> sufficient randomness.

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

>
> 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,

Done.

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

Done.

>
>  * Security considerations might include some of this discussion.

Done.

>
> It might also be worth considering adding an informative reference to
> 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.

>
> 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)

Done.

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

Done.

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

Done.

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

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

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

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

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

Correct.  I added the clarification.

>
> 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?

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.

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

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

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

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

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

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.

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

Done.

Regards,
Charlie P.




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