Review of draft-zorn-radius-keywrap

[Alan DeKok <aland@deployingradius.com>]

  This is a review of the draft-zorn-radius-keywrap document.

  First off, as co-author of the "Guidelines" document, most of the
comments below come straight from that document.

  The keywrap document defines a new RADIUS packet signature method, at
a time when TLS and DTLS transport have been worked on for a number of
years.  This new signature method has had little security analysis, in
contrast to TLS.

  The documents defines a multi-field "text" attribute, which
contradicts Section 3.2.3 of the guidelines document.  It does so
withing a Vendor-Specific space, which is permitted by the documen.
i.e. vendors can do anything they want in their space.

  However, anything that's done in the Vendor-Specific space does not
need to be published as an IETF document.  So I'm a little unsure as to
the purpose of this document.  If it's a vendor extension, there's no
need for an IETF document.  If it's for use in the wider community, it
should follow Section 3.3.1 of the guidelines document:

   The design and specification of VSAs for multi-vendor usage SHOULD be
   undertaken with the same level of care as standard RADIUS attributes.
   Specifically, the provisions of this document that apply to standard
   RADIUS attributes also apply to VSAs for multi-vendor usage.

  All in all, the draft contradicts the guidelines in pretty much every
respect.

  Alan DeKok.


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