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

Stefan Winter wrote:
> Sounds good to me. The mangling would be: find first @ in User-Name,
> chop off behind @, toss remainder to DNS library and hope for an answer.
> Is that what you had in mind?

  Yes.

>> 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.
> 
> Hmm... The whole purpose of dynamic discovery is that the need for
> per-client config becomes obsolete.

  Yes.  If the server determines "known" clients based on SSL
certificate, then we would require that it use RadSec / DTLS.  The issue
here is *only* for existing, IP-based clients.

> I agree that pinpointing individual
> clients to a desired transport would mitigate the bidding-down. But the
> number of clients is not necessarily known beforehand. I would be
> delighted if we'd find a solution for the generic case. But my head is
> not overflowing of ideas to that end, honestly.

  The server already tracks IP, secret, and maybe a few other things for
existing clients.  Adding one more piece of information isn't hard.

  When all existing clients have been upgraded to using RadSec / DTLS,
then I think that all client-based configuration could be removed.  The
server could then simply use TLS-based methods to verify client identity.

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