Review of draft-ietf-radext-digest-auth-08.txt (fwd)

"Bernard Aboba" <bernard_aboba@hotmail.com> Mon, 15 May 2006 13:04 UTC

Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 15 May 2006 13:04:36 +0000
Message-ID: <BAY106-F155505108B57182AF3173693A30@phx.gbl>
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: radiusext@ops.ietf.org
Bcc:
Subject: Review of draft-ietf-radext-digest-auth-08.txt (fwd)
Date: Mon, 15 May 2006 06:04:06 -0700
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"

---------- Forwarded message ----------
Date: Mon, 15 May 2006 10:37:03 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com
To: Bernard Aboba <aboba@internaut.com

Bernard Aboba wrote:

  We now have a new version of the document:
  http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-08.txt
  Before submitting this to the IESG, it would be helpful to know if the
  comments on -06 have been addressed.

All major issues I've raised before are addressed. The document reads much
better after removal of client side nonce generation. Some minor additional
comments below:

  2.1.2.  Constructing an Access-Request
[...]

  Due to syntactic requirements, HTTP-style protocols have to escape
  quote characters in contents of HTTP Digest directives.  When

"with backslash all quote and backslash characters in contents of ..."

  translating directives into RADIUS attributes, the RADIUS client only
  removes the surrounding quotes where present.  See Section 3 for an
  example.

  2.2.1.  General Attribute Checks

[...]
  The RADIUS server removes '\' characters that escape quote characters
"... that escape quote and '\' characters ..."
  from the text values it has received in the Digest-* attributes.

  8.1.  Denial of Service
[...]
  An attacker can attempt a denial of service attack on one or more
  RADIUS servers by sending a large number of HTTP-style requests.  To
  make simple denial of service attacks more difficult, the nonce
  issuer (RADIUS client or server) MUST check if it has generated the
  nonce received from an HTTP-style client.  This SHOULD be done
  statelessly.  For example, a nonce could consist of a
  cryptographically random part and some kind of signature provided by
  the RADIUS client, as described in [RFC2617], section 3.2.1.

The RADIUS client no longer generates nonces, so it can't verify signature,
unless it knows how RADIUS server generates nonces.

  9.  Acknowledgments

  We would like to acknowledge Kevin Mcdermott (Cisco Systems) /or
typo: "for"
  providing comments and experimental implementation.

Alexey
/*
*/



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