[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Review of draft-zorn-radius-keywrap
Alan,
Thanks for your review.
I would like to make a clarification - draft-zorn-radius-keywrap is and
Independent Stream submission. An RFC document that would result from a
possible approval of this document would not be an IETF document, but an
Independent Submission Stream RFC. Not all RFCs are IETF documents. See
RFC 4844 section 5 for definitions of the different RFC streams.
Dan
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok
> Sent: Tuesday, December 14, 2010 6:32 PM
> To: 'radext mailing list'
> Subject: Review of draft-zorn-radius-keywrap
>
>
> 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/>
>
--
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/>