The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model
draft-blumenthal-aes-usm-08

[Ballot comment]
In response the the comment by Ned:
- I think that RFC3414 sect 11.2 does discuss this topic somewhat,
  but not as detailed as this new document. So elaborating on this
  with more detail in this document seems goodness to me.

From one of my MIB doctors:
- Section 1.1 - should say probably 'User-based Security Model (USM)'
  as opposed to just 'USM'

- Language in 1.3 and 4 seem to be inconsistent 'can be
  suggested' and MUST do not play well for my English parser
  (not the best in the world, of course)
  This one is in sync with the concern about conflicting SHOULD and MUST
  language in the two sections.

[Ballot comment]
A minor editorial comment that can be ignored unless a document
update is needed for other reasons:

This document uses an unusual method for defining acronyms --
just using the full name at the beginning and the acronym later,
without associating the two.  Here is one example:

"The main goal of this memo is to provide a new privacy protocol for the
USM based on the Advanced Encryption Standard.
[...]
For a given user, the AES-based privacy protocol..."

I would have preferred to see Advanced Encryption Standard (AES),
as this makes it easier to associate the acronym with the name
and is consistent with other RFCs.

[Ballot discuss]
I have three DISCUSS comments:

1.  In section 1.1, a normative reference to the NIST FIPS that defines AES.  I suggest:

    The main goal of this memo is to provide a new privacy protocol for the
    USM based on the Advanced Encryption Standard (AES) [FIPS-AES].

2.  The first paragraph in section 4 says:
 
    The security of the cryptographic functions defined in this document
    lies both in the strength of the functions themselves against various
    forms of attack, and also, perhaps more importantly, in the keying
    material that is used with them.  The recommendations done in Section
    1.3 MUST be followed to ensure maximum entropy to the selected
    passwords, and to protect the passwords while stored.

However, the referenced section 1.3 does not contain any MUST statements.  Either change the statements in section 1.3 to MUST, or change the MUST in section 4 to SHOULD.

3.  The second paragraph in section 4 says:

    For information regarding the necessary use of random IV values, see
    [CRYPTO-B].

The document properly requires unique IVs for each encryption.  Given the mode that is being used, unique IVs ought to be discussed in this paragraph too.

[Ballot comment]
In section 3.1, please remove the dash at the front of each paragraph.  Alternatively, treat it as a bulleted list by adding an introduction sentence.

[Ballot comment]
It seems to me that the password entropy discussion in 1.3 applies regardless
of the symmetric cipher that's employed and really belonged in section 11.2
of RFC 3414 rather than in a document whose goal is only to define a new symmetric
cipher for SNMP. But the way this section is worded (e.g. "functions specified
in this document") makes it sound like the need for strong passwords is somehow
specific to AES. Perhaps this could be reworded to make it clear the need is more
general.

Comments by Bert Wijnen (reviewed revision 06 in my rile as OPS-NM AD)
-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: dinsdag 29 juli 2003 23:50
To: Uri Blumenthal; Keith McCloghrie; fmaino@cisco.com
Cc: smb@research.att.com; uri@bell-labs.com; Wijnen, Bert (Bert)
Subject: RE: draft-blumenthal-aes-usm-06.txt


My comments:

1. As I explained to Keith, I think you better make it very
  clear which value of snmpEngineTime is to be used. It is
  not OBVIOUS.

2. SMICng complains:
  E: f(usmaes.mi2), Missing semicolon at end of IMPORTs - terminating

3. I do not see a COPYRIGHT statement in the DESCRIPTION clause
  of the MODULE-IDENTITY.
  See draft-ietf-ops-mib-review-guidelines-01.txt

4. Section 3.3.1 says:
    2) The privParameters field is set to the serialization according to
      the rules in [RFC3417] of an OCTET STRING representing the 64-bit
      integer that will be used in the IV as described in [RFC3414].
  Should that not point to sect 3.1.3 and 3.1.4 in your own document
  instead of RFC3414 ??
  But maybe I am not getting it.
  I think what you want to send with the encrypted packet is the "salt",
  which is the concatenation of snmPEngineBoots, snmPEngineTime and
  a randomly intialized (and then monotonically increasing) 64-bit
  integer. Sofar sogood.
  I think what you may mean to imply with your reference to RFC3414 is
  that the salt needs to be XORed with some (part of) the users key
  (the pre-IV ??). Is it also 8 octets (as per RFC3414?) I guess not,
  I would guess it is 16 octets here? Or is there no XORing in this case?

  SO I wonder, why you would try to save one or two sentences by pointing
  to the DES procedures in RFC3414 (in fact you just point to 3414 and the
  reader is given the tesk to figure out which page you mean). Why not
  make the complete procedure of how to do thing self-contained in this
  document? Like section 8 in RFC3414 is (or at least was intended to be)
  self-contained?

5. In the Security Considerations:
      This algorithm MUST be used with an authentication and/or integrity
      protection algorithm (including but not limited to those defined in RFC
      3414), because CFB encryption mode does not detect ciphertext
      modifications.
  Not sure I understand "authentication and/or integrety protection algorithm"
  We have a so called "authentication protocol" which goes with an
  algorithm. That also provides integrity protections. So why is there an
  "and/or" in that sentence?

  Also I see "(...but not limted to RFC3414)"
  What does that mean? Mmm... I see it in sect 1.1. too.??

  Finaly, you may want to add a sentence to state that the MIB module does
  not define any management objects, and so there are no security considerations
  for the MIB module itself.

6. IPR section starts with:
    The authors made no IPR claims on the contents of this document or the
    algorithms defined in it.
  I do not believe that that is approved text foir this section.
  See RFC 2026 section 10.
  Since Steve is the shepherding AD and since he is also IPR WG chair,
  I will leave it to him if it is acceptable or not.

7. IANA considerations
  WHy are you suggesting to assign 4 for the new snmpPrivProtocol?
  The next free value I believe is 3, is it not?

8 References.
  - I see RFC2104 in ref sect. But I see no citation?

that is all.

Thanks,
Bert

Most issues resolved.  This one remains open:

> 3.1.2.1
>        What is the justification for that algorithm?  Why not use,
>        say, SHA2-n for an n-bit key?  Better yet, why not use the
>        key derivation function from draft-blumenthal-keygen-03.txt,
>        which is intended as BCP?  (I'm personally unhappy with
>        functions of the form used here, since the early bits of the key
>        have been passed through fewer iterations of SHA1.  But I'm
>        not certain that that's a cryptographically sound argument,
>        though I think it does make it somewhat easier to recover Kul
>        by looking at the early bits.)

State Changes to New Version Needed (WG/Author)                    from AD Evaluation                                    by bellovin