> OK, since RFC 2865 only defines RADIUS in terms of UDP, it must not be > the authoritative reference for "RADIUS *at all*". What is? I'd like > to read it... Okay, point taken. Since there's no source for RADIUS without entangled UDP transport, the RadSec I-D should have a section that states which parts of 2865 are irrelevant when using a TCP transport. I.e. the draft should define the subset that matches the fuzzy expression of "RADIUS *at all*". I'll go through 2865 and list the spots. On a side note, 2865 has other hard-wired assumptions that aren't incredibly valid today. Are we going to split hairs on every one of them? That would mean making an update to 2865 though. Take for example 2. Operation [...] If the client is valid, the RADIUS server consults a database of users to find the user whose name matches the request. The user entry in the database contains a list of requirements which must be met to allow access for the user. This always includes verification of the password, but can also specify the client(s) or port(s) to which the user is allowed access. Enter EAP-TLS. Where's the database? What password? I somehow wonder why the introduction of EAP-TLS went by silently without an outcry that 2865 is too narrowly specified to allow this, by being hardwired to a specific set of auth backends. Back then, an RFC updated 2865 for EAP, and that was it. The fuss argumentation would be and could have been in a similar direction like the one we have here. It's a matter of personal liking or disliking a specific update I guess. Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: email@example.com Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
Description: This is a digitally signed message part.