comments on draft-zorn-radius-keywrap-12.txt

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

  Hi,

  I recently read draft-zorn-radius-keywrap-12.txt and have a few
comments. I hope they can be addressed before this draft is advanced
to RFC.

  general:
    * there is a real lack of requirements in this draft. Most things
      are MAY and it looks like a compliant implementation could do
      almost nothing, which seems odd for an RFC. Furthermore
      interoperability will be extremely difficult since little behavior
      MUST be followed. Ironically. one of the rare MUSTs in the draft
      really should be a SHOULD.

  section 3.1:
    * the Key ID, lifetime, IV and Key material fields MAY be omitted
      but then the length of the keying material attribute would not
      be >= 24 as defined later on when the layout of the attribute is
      defined. I suggest changing the length to be >= 8 and specify that
      if any of these attributes are omitted then they MUST all be omitted
      otherwise someone could legitimately omit one field and include
      another and it would be impossible to parse the attribute on receipt.

    * "if the client requires the use of the Keying-Material Attribute"
      but it's not present then it "MAY ignore the message"? This should
      be MUST or else "require" doesn't mean what I believe most people
      think it means.

    * KEK ID, KM ID are both unspecified. They are supposed to identify
      the key but how? If the Frobnitz corporation defines the ID to be
      sha("the KEK ID") and the Fubar corporation defines it as the
      string "this is your KEK ID!" (both 20 bytes) then how do they
      interoperate? 20 bytes? Why won?t 4 do? Or even 2? Does this have
      something to do with hashing to produce an ID? It?s not specified.

      Having unspecified things and then say "Further specification of the
      content of this field is outside the scope of this document" means
      that specification in its entirety is outside the scope of this
      document. That being the case then why is this even part of an IETF
      document? These fields should be removed before the document is
      advanced.

      The KEK ID and KM ID, being entirely unspecified, are gigantic
      subliminal channels. I really don't think that's appropriate.

    * if the Enc Type field is 0 then "the IV field MUST be as specified
      in RFC3394". Is it supposed to be the "default IV"? If so then why
      even bother sending it in the attribute? It would be painful to
      make the attribute variable length-- i.e. if Enc Type field is 0
      then there is no IV field-- so why not change this MUST to a SHOULD?
      Also, there may be legitimate reasons to use a different IV than the
      default one listed in RFC3394 (which is why that RFC allows it).

  section 3.3:
    * MAC Key ID, same comments apply here as with KEK ID and KM ID above.

  section 5:
    * If two new keys are being defined then there is no point in having 3
      ID fields to identify them. They are implicitly identified here. One
      key is for key wrapping and the other key is used for integrity
      checking. Again, there is no need for a KEK ID, KM ID, or MAC Key ID.

    * I think these two new keys MUST be cryptographically independent of
      the RADIUS shared secret (not SHOULD). The RADIUS shared secret
      already has a defined use and it's not as a key deriving key. There
      is no valid reason in any particular circumstance to ignore this
      particular item (to paraphrase RFC2119).

  I think it's great to have an RFC3394-style way to send keys from a
RADIUS server to a RADIUS client but this seems to go way beyond that
simple task. And there isn't any real apparent justification for those
excesses. KEK ID, KM ID, MAC Key ID... please just get rid of them. If
someone wants to pass VSAs then they should just pass VSAs.

  thanks,

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