Re: REMINDER: Call for review of the "NAI-based Peer Discovery" document for acceptance as a RADEXT WG work item

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> This is a reminder of an ongoing call for review of the document
> "NAI-based Peer Discovery" for adoption as a RADEXT WG work item.  This
> document was formerly part of the RADSEC document, and is now being
> split off into its own document, which (like RADSEC) will be targeted
> toward Experimental Status.

  I support adopting this document as a WG work item.

Review
Submitter name: Alan DeKok
Submitter email address: aland@deployingradius.com
Date first submitted: June 12, 2009
Reference:
Document: dynamic-discovery
Comment type: T
Priority: 1

Section 2.2: says:

   For a given NAI-based input realm,

NAI is... ?  The document doesn't define this term, and doesn't
reference RFC 4282 (NAI definition).

   ...
   the following algorithm is used to
   determine the AAA server to contact:

   1.   Transform input realm into punycode.
   ...

 This recommendation is correct for DNS, but is problematic in practice.
 The recommendations in RFC 4282 define how the above transformation is
done.  *BUT* those recommendations have serious problems.

  Would it be possible to simply rely on the DNS library to do the
correct conversion, and name resolution?  This document could then
describe how to mangle the NAI as a string, and that string then gets
passed to the DNS library for additional punycode mangling, and finally
lookup.


Section 3 talks about bidding down attacks.  These attacks can be
largely mitigated by additional per-client configuration on the server.
 See the DTLS document for discussion of this topic.

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