Re: [radext] BoF request for IETF 115

[Alan DeKok <[e-mail]>]

On Sep 23, 2022, at 3:58 PM, Bernard Aboba <[e-mail]> wrote:
> [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. 

  I agree.  Some guidance here would be useful.  If we're depending on TLS-PSK for security, there isn't much point in having the PSK have low entropy.

> " 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. 

  I took a quick look at the expired I-Ds, and didn't see anything that leaped out at me as addressing this.  There may have been discussions on the WG list, but I don't recall anything specific.

> "  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. 

  Yes.

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

  Yes.  But I'd like to weasel out of as much of that as possible.  I don't feel comfortable designing new crypto.

  Picking some of the RFC 6421 requirements:

   Proposals MUST support the negotiation of cryptographic algorithms
   for per-packet integrity/authentication protection.  Proposals also
   MUST support per-packet replay protection for all RADIUS message
   types.  Crypto-agility solutions MUST specify mandatory-to-implement
   cryptographic algorithms for each defined mechanism.

  If we ban RADIUS / UDP and RADIUS / TCP, the solution here is TLS.

   Support for encryption of individual RADIUS attributes is OPTIONAL
   for solutions that provide encryption of entire RADIUS packets.

  Again, TLS.

   Solutions MUST demonstrate backward compatibility with existing
   RADIUS implementations.  That is, an implementation that supports
   both crypto-agility and legacy mechanisms MUST be able to talk with
   legacy RADIUS clients and servers (using the legacy mechanisms).

  This requirement is not met by TLS.  I would be OK with just banning RADIUS / UDP.

   Since RADIUS is a request/response protocol, the ability to negotiate
   cryptographic algorithms within a single RADIUS exchange is
   inherently limited.  Prior to receipt of a response, a requester will
   not know what algorithms are supported by the responder.  Therefore,
   while a RADIUS request can provide a list of supported cryptographic
   algorithms that can be selected for use within a response, prior to
   the receipt of a response, the cryptographic algorithms utilized to
   provide security services within an initial request will need to be
   predetermined.

  Avi Lior had a draft proposing capability negotiation in RADIUS.  There was a lot of discussion, but in the end it didn't get WG consensus.  I suspect because capability negotiation was just too complex for many RADIUS implementations.

   Crypto-agility solutions MUST apply to all RADIUS packet types,
   including Access-Request, Access-Challenge, Access-Reject,
   Access-Accept, Accounting-Request, Accounting-Response, Status-Server
   and CoA/Disconnect messages.

  Again, TLS.

  I think just "use TLS" and "ban RADIUS / UDP and RADIUS / TCP" would address all of the requirements of RFC 6421, except the requirement for backwards compatibility.

  Alan DeKok.