Subject: [Mip6] [issue38] David Kessens' comments (Ops Directorate review)

From: Basavaraj Patil <[email-masked]>
Date: Fri, 09 Sep 2005 18:41:46 +0000

New submission from Basavaraj Patil <[email-masked]>:

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.

----------
category: Editorial
draft: draft-ietf-mip6-precfgkbm
messages: 137
nosy: bpatil
priority: Should fix
status: Pending
title: David Kessens' comments (Ops Directorate review)

_________________________________________________
Mip6 issue tracker <[email-masked]>
<http://www.mip4.org/issues/tracker/mip6/issue38>
_________________________________________________

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