Subject: Review of draft-zorn-radius-keywrap

From: Alan DeKok <[email-masked]>
Date: Tue, 14 Dec 2010 17:32:13 +0100

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 14 Dec 2010 18:03:01 +0100

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Tuesday, December 14, 2010 6:32 PM
> To: 'radext mailing list'
> Subject: Review of draft-zorn-radius-keywrap
> 
> 
>   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.
> 
> contradicts Section 3.2.3 of the guidelines document.  It 
> does so withing a Vendor-Specific space, which is permitted 
> by the documen.
>   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:
> 
>   All in all, the draft contradicts the guidelines in pretty 
> much every respect.
> 
>   Alan DeKok.
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 14 Dec 2010 18:16:07 +0100

> RFC 4844 section 5 for definitions of the different RFC streams. 

  Sure.  The following text from Section 3.3.1 still applies, though:

  The document does not meet that criteria.

  Alan DeKok.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 14 Dec 2010 18:22:17 +0100

So, trying to make sure that I understand your point, the document could
be possibly OK as a definition of a one vendor set of extensions but
would fail some of the criteria of the guidelines document for
multi-vendor usage. 

Dan

> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Tuesday, December 14, 2010 7:16 PM
> To: Romascanu, Dan (Dan)
> Cc: radext mailing list
> Subject: Re: Review of draft-zorn-radius-keywrap
> 
> > 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.
>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 14 Dec 2010 21:17:08 +0100

> would fail some of the criteria of the guidelines document for

  I would replace "some" with "nearly all".

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 17 Dec 2010 13:31:48 -0800 (PST)

Hello,

> years.  This new signature method has had little security analysis, in

  Neither AES Key Wrap nor (D)TLS are "signature methods". AES Key Wrap
is providing an integrity check and confidentiality only on a random key.
This technique is now new; it's used in 802.11 (you should note that
the draft in question pre-dates the "guidelines" document).

  AES Key Wrap has received quite a bit of analysis. There is a very
good critique of it in "Deterministic Authenticated Encryption: A
Provable Security Treatment of the Key Wrap Problem" by Rogaway and
Shrimpton available at:

            http://web.cecs.pdx.edu/~teshrim/keywrap.pdf

  regards,

  Dan.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 18 Dec 2010 13:22:09 +0100

> is providing an integrity check and confidentiality only on a random key.

  The document contains a Message-Authentication-Code attribute, which
is defined as:

   This Attribute MAY be used to "sign" messages ...

  The following text describes an "ad hoc" method for signing packets.
It is not based on keywrap.

  Perhaps you haven't read the document, or you didn't notice the pages
of text talking about a new packet signature method?

> the draft in question pre-dates the "guidelines" document).

  I'm suitably impressed with this irrelevant fact.

>             http://web.cecs.pdx.edu/~teshrim/keywrap.pdf

  Which is not referenced anywhere in the document.

  In fact, there is *no* reference in the document to any security
analysis, origin, or history of the "keywrap" method.  The *only*
reference to "keywrap" is in the document title.

  Given the document *on its face*, the authors have given us every
reason to believe that the cryptographic methods described in it were
invented solely for this specification.

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 18 Dec 2010 11:24:17 -0800 (PST)

Alan,

  I am not attempting to impress you, just to inform you. AES Key Wrap
was not "invented solely for this specification". It was developed by
NIST and published in November of 2001. It has widespread use and has
received cryptographic analysis. These statements are true whether the
draft makes mention of them or not.

  Dan.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 18 Dec 2010 21:31:48 +0100

Dan Harkins wrote:
> was not "invented solely for this specification".

  That's a straw man: quoting text out of context.

> It was developed by

  It might be useful for the draft to reference the cryptographic method
it's using.  Right now, it doesn't even claim to be implementing the
keywrap method.

  Alan DeKok.