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

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

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:

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