Re: [radext] BoF request for IETF 115

[Bernard Aboba <[e-mail]>]

Alan said:

"My preference would be to just punt the problem to TLS. That is also the
historical approach (chosen implicitly) by prior discussions in RADEXT."

[BA] Leaving the crypto-agility problem to TLS makes sense.  However, there
are some security issues that TLS alone cannot solve.

For example, there has been discussion of adding support for shared secrets
to RADIUS over (D)TLS, so as to allow configuration to be familiar to
RADIUS server administrators.

My concern is that the "shared secrets" used in today's RADIUS deployments
often have little entropy, leaving them open to password-guessing attacks.
So some additional thinking may be required here.

" To my recollection, the RADEXT WG never seriously discussed any of those
points. Instead, once the RADIUS / TLS work was started, all of the crypto
agility requirements were silently dropped. The preference was to not
design any new cryptographic primitives in RADEXT."

[BA] The crypto-agility requirements were not dropped or ignored.  There
were quite a few submissions that claimed to meet the RADIUS crypto-agility
requirements, but after evaluation against the RFC 6421 criteria, only the
RADIUS over (D)TLS proposals went forward for publication as Experimental
RFCs.

" That is, RFC 6421 was published, and was resoundingly ignored. It would
be worth perhaps explaining why in a new document. Perhaps the one which
deprecates RADIUS / UDP."

[BA] It is true that the (now closed) RADEXT WG ignored its
responsibilities under RFC 6421 to publish a crypto-agile version of RADIUS
on the standards track.

But that's what that the WG proposed in this BOF is trying to fix, right?