comments on draft-zorn-radius-encattr-15

["Dan Harkins" <dharkins@lounge.org>]

  Hi,

  I just read draft-zorn-radius-encattr-15 and have a few comments.

  - an appendix showing at least two examples (with nice
    ASCII art figures too!) would be most helpful.

  - apparently there is a requirement (unstated) to support
    encryption of random data as well as key wrapping, and to
    be able to authenticate encrypted data. To do this the
    draft mandates AES-CBC-128 (for encryption of arbitrary
    data), AES Key Wrap (for key wrapping), and HMAC-SHA1 to
    integrity check the encrypted data and the rest of the
    message.

    These three tasks could be accomplished by one single
    cipher mode: SIV. SIV can do authentication encryption
    with associated data of arbitrary-sized plaintext when a
    nonce is included in its input, or do deterministic key
    wrapping when a component of the plaintext contains a
    random key.

    Furthermore, there seems to be a desire to integrity check
    a message that does not have any encrypted components. To
    satifsy this requirement (also unstated) the draft mandates
    HMAC-SHA1 instead of AES-CMAC.

    If the draft mandated support for AES-SIV-CMAC to do
    authenticated encryption (with associated data!) and
    AES-CMAC for encryption-less integrity protection then
    it can be implemented with a single primitive. Since
    AES-SIV-CMAC itself uses AES-CMAC you get it for free.
    Then the draft could build upon a single foundation and
    its security would be based on the assumption that AES
    is a secure pseudo-random permutation (which I believe
    is the basis for the proof of both AES-CMAC and AES-SIV).

    I recommend the mandatory-to-implement encryption algorithm
    be AES-SIV-CMAC and the mandatory to implement integrity
    check (when encryption is not used) be AES-CMAC.

  - 3.5 says that "Applications using [Key-Liftime] SHOULD
    consider the beginning of the lifetime to be the point
    in time when the key is first used." Why not when it was
    first exponsed (albeit encrypted)? If there is going to
    be a recommendation I think it would help if there's some
    reasoning to go along with it, otherwise just get rid of
    the recommendation.

  - 3.6 says, "If the data encapsulated in the Encrypted-Data
    TLV represents a cryptographic key and the algorithm
    specified by the Encryption-Type TLV requires the use of
    an initialization vector (IV), this TLV may be used to
    communicate the IV from the RADIUS server to its client."

    Actually, if the encryption algorithm is AES-CBC then this
    TLV is needed whether the data being encrypted is a key or
    not. I think it would be better to say, "If the encryption
    algorithm specified by the Encryption-Type TLV requires an
    IV or the data being protected is not a key then this TLV
    may be used to communicate the IV from the RADIUS server
    to its client."

    Also it MAY be appropriate to use "MAY" instead of "may".

  - 3.7, the "algorithms" in this section might be a nice place
    to mention that AES Key Wrap operates on blocks of 64-bits
    even though the block cipher on which it is based operates
    on 128-bit blocks.

    The input of AES-SIV-CMAC includes associated data so the
    two "algorithms", send and receive, should include mention
    of this fact right after they mention an IV.

  - 3.8, the description should mandate this TLV is also required
    for encryption algorithms that do not produce authenticated
    ciphertext, like AES-CBC.

  - 3.8.1.1 "...the value of the MAC field is a hash..." What
    about when using AES-CMAC? Does that produce a hash too?
    Perhaps "output from a pseudo-random function" would be better.

  - in 3.8.1.1 MAC=MAC-ALG(x,y) while in 3.8.1.2 MAC=HASH-ALG(x,y).
    How about calling making it more generic: MAC=PRF(x,y)?

  - 3.8.2, what about when using AES-SIV? The RFC 5116 interface
    is mentioned in 3.1 and that produces an authenticating tag
    concatenated with encrypted plaintext as a single "ciphertext"
    output. So when AES-SIV is used should the Message-Authentication-
    Code attributes signify individual components of AAD (since
    SIV can take a vector of inputs and not just a single concatenated
    input)? I think using an Encryption-Type TLV with NULL encryption
    to accomodate traditional RADIUS attributes is wrong, it will also
    screw up AES-SIV since AES-SIV will expect an Encryption-Type TLV
    somewhere that says AES-SIV as the type. It would be better to
    define an Envelope TLV to contain traditional RADIUS attributes.

  - 3.8.2: doesn't CMAC-AES return 16 bytes?

  - 3.9, what's the point of the MAC-Randomizer? In the case of key
    wrapping semantic security is achieved because a component of
    the plaintext is a key. In the case of non-key wrapping encryption
    semantic security is achieved by the IV. In the case of an
    unencrypted message I don't see the need for a MAC-Randomizer.
    If I'm missing something then I'd wager some other people are too
    and a justification is in order.

  - 6, what's "the strength of the algorithm used" if that algorithm
    is HMAC-SHA1?

  regards,

  Dan.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>