Hello, the topic of re-chartering radiusext to accomodate the RadSec work has been a continuous topic in the last two meetings, the mailing list and in several offline discussions. The last meeting in Vancouver suggested to move the three most promising crypto-agility suggestions (keywrap, dtls, radsec) to EXP status within radext. RadSec is being implemented in various independent codebases and is in production use today. The points above make me think that it is about time to seriously consider that the radext charter is modified to include RadSec into the working group scope. The DTLS draft led to consensus that TLS-style payload encryption is not considered being a new security mechanism for protecting RADIUS (which would be excluded by the charter as-is). Then, the same holds true for the TLS part of the radsec draft, which in turn means this part of the charter does not need changing. The only part in the charter that would need to be changed is, obviously, the line "- No new RADIUS transports (e.g. TCP, SCTP) will be defined." which I request to purge from the charter. After being included in the radext WG scope, the radsec draft would certainly be rewritten for more normative wording. Because up to now, it was meant as an FYI description of existing implementations, not in any way a standard. When EXP is a target, language should change accordingly. I volunteer to do this to the best of my knowledge - it is my first I-D at all. 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.