[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: REMINDER: Call for review of the "NAI-based Peer Discovery" document for acceptance as a RADEXT WG work item
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?
>> 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.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.