FW: FW: Last Call: The AES Cipher Algorithm in the SNMP's User-based Security Model to Proposed Standard

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

FYI.
I had forwarded the IETF Last Call to SNMPv3 list.

Thanks,
Bert 

-----Original Message-----
From: Wes Hardaker [mailto:hardaker@tislabs.com]
Sent: dinsdag 22 april 2003 1:39
To: Uri Blumenthal; kzm@cisco.com; fmaino@andiamo.com
Cc: Bert Wijnen; Snmpv3-wg (E-mail)
Subject: Re: FW: Last Call: The AES Cipher Algorithm in the SNMP's
User-based Security Model to Proposed Standard


>>>>> On Wed, 26 Mar 2003 00:04:48 +0100, "Wijnen, Bert (Bert)" <bwijnen@lucent.com> said:

Bert> SNMPv3 supporters, pls review and post your comments (if any)as
Bert> requested.

Bert> Statements of: I have read it and think it is "good stuff" are
Bert> welcome too

"good stuff" (but needs a fair amount of editing).  I implemented an
earlier version of the draft in 2 packages and it's still compliant
with the most current (though the implementation I based my work on
also supported the 192 and 256 versions of the same algorithm.

I have a number of commends/questions/concerns/editorial-catches,
which I'll list here (I've removed all the editorial catches that
other people already made.  IMHO, the entire document needs to be
re-proofread by all the authors especially after all the grammatical
changes that people have caught and found):

Concerns/Questions/Comments:

 - 1.1: The 3rd paragraph says the AES privacy protocol MAY be used
   with the authentication protocols in ... RFC3414.  Obviously, it
   may be used with more (future-defined) protocols as well and you
   may want to change the wording to reflect this.  You do mention it
   later in the document, however, but if you're going to cover it in
   both places you should have them both state the same thing (and the
   first statement made of this type should always be the most
   informative).

 - 1.3: My are you recommending that a 12 byte [should be "octets by
   the way] minimum password be used (don't get me wrong, I agree that
   longer is better).  Was 12 chosen arbitrarily (as opposed to 16 or
   24 or ...)?  I guess the real question is that if RFC3414 says 8
   bytes is enough for DES, then you should offer a reason why 12 is
   needed for AES (of course neither 8 nor 12 come anywhere near the
   potential entropy of a truly random key).  (Actually, the entropy
   of the authentication algorithms is more critical in my mind).

 - 1.3: I'd used the word "prohibited" instead of "limited" with
   respect to password sharing.

 - 1.3: I'd add a 3rd bullet: "Implementations SHOULD support the use
   of randomly generated master keys as a superior form of security."
   or something like that.  Truly the entropy in a password sucks, so
   I'd at least recommend the use of true random keys when possible.

 - 2: This really needs a full MIB definition, not just a segment.
   This section and the segment seems to imply that RFC3414 is going
   to be modified and have this stuck in it?  I don't think that would
   fly.

 - 3.1: "The secret value is shared by all SNMP engines authorized to
   originate messages on behalf of the appropriate user."  This is not
   true and is a bad statement to make from security prospective.
   1) The key has nothing to do with authorization, and the wording
      choices seems to imply that it might.
   2) The key dose *not* need to be shared with engines that may only
      need to send noAuthNoPriv or authNoPriv messages.  Your sentence
      implies that all engines using the given user should have the
      privacy key, which is not true and implies a greater secrecy
      sharing that is needed for some situations.

 - 3.1.1.2 - 3.1.1.4: if these are standard sizes suggested by
   [AES-MODE], say so in the document.

 - 3.1.2: "of the generating SNMP engine's 32-bit snmpEngineBoots, the
   SNMP engine's 32-bit snmpEngineTime, and a lcal 64 bit integer".
   This is not correct.  "generating SNMP engine" should be
   "authoritative SNMP engine".  Since management applications will
   not be transmitting their (local) boots/time values, and the entire
   IV is not transmitted you must use the boots and time values that
   are always known to both parties.  This means only the
   authoritative engine's boots/time values can be used unless you
   change the contents of the msgPrivacyParameters to include the full
   IV (which, of course, I don't recommend for octet-saving reasons).

 - 3.1.2: "An implementation can use any method to vary the value of
   the IV ..." IV => integer.  Since the boots and time are not put
   into the privacy field, only the integer can be varied in an
   arbitrary manner.

 - 3.1.2: I'd put in a note mentioning that multiple managers
   communicating with a single authoritative engine within a second
   can cause a duplicate IV to be used if they both (accidentally)
   use the same 64 bit integer value [the probability of such a
   problem is low, though birthday statistics drop this a bit more.  I
   posted an analysis of this a few months ago.].

 - 3.1.3, 3.1.4: an ASCII diagram would be nice for the people that
   aren't familiar with CFB mode (if you're going to describe it then
   you might as well generate the diagrams for it).

 - 3.2.1: you also need to know the authorization algorithm for the
   user, since it's used to generate the localized key.  And you might
   as well throw in the encryption algorithm just to check that it's
   the right one ;-)

 - 4: You should mention key entropy here since you talk about it
   earlier.  Additionally, I'd refer the reader to RFC3414 explicitly
   since the USM specific implications are there.

 - 4: you reference [CRYTPO-B] as a document that describes the need
   for a unique IV value.  However, I don't think that document is the
   right reference.  That document describes plain-text analysis and
   attacks of DES when operating in CBC mode.  CFB mode, which is used
   by your document, is quite different from CBC mode in its use of an
   IV and thus I don't think the statements made in that paper about
   unique IV requirements properly support your statements within your
   own document.  [since the author of the paper in question is also
   the reviewing security AD, maybe he'll have further comments on the
   subject?].

Editorial ('*' pairs mark changed parts of sentences):

 - General: You use "Symmetric Encryption Protocol" in many places.
   Why is it capitalized?  It really shouldn't be, IMO.  The same goes
   fore "Cipher Algorithm".

 - 1.  remove the ()s around the word "initial".
 - 1. "Model, however, allows" (add the commas)
 - 1.1 protocol for *the* USM based
 - 1.3: It is worth *remembering* that ... password *or non-localized key* is
   disclosed ...
 - 1.3: the sentence suffix "in this case" isn't needed.
 - 3: alternative to the *DES* privacy protocol
 - 3.1: of the message that *will* be encrypted *in an SNMP message*.
 - 3.1.1: contain description*s* of the revlevent
 - 3.1.2: satisfy *this* requirement *[above]*.
 - 3.1.3, 3.1.4: "r is less *than* or equal to 128"
 - 3.2.1: MUST be *greater than or equal to* 128 bits (earlier you
   stated that you strip off the first 128 bits of a longer key, but
   here you state that a 128 bit length is mandatory).
 - 3.2.2 privacy key is *[delete normally]* different
 - 3.2.2, 3.2.3: for readability, I'd either use a English phrase for
   both of these or use msgPrivacyParameters for 3.2.4.
 - 3.2.4.1, 3.2.4.2: passes the *(localized)* secret key
 - 3.3: for the AES privacy protocol *for SNMP's User-based Security Model*
 - 3.3.1 step 1: *en*cryptKey (which is the full name the ASI has in
   the argument list).
 - 3.3.2 step 3: *de*cryptKey (ditto)

-- 
Wes Hardaker
Network Associates Laboratories