Re: [radext] Proposed charter text based on IETF-115 BoF

[Alan DeKok <[e-mail]>]

On Nov 24, 2022, at 10:14 AM, Bernard Aboba <[e-mail]> wrote:
> [BA] I'm wondering why negotiation is needed. Installations know whether they want to conform to FIPS or not. If they do, then failure of MD5 operations is not a bug, it's the desired outcome. 
> 
> For backwards compatibility, servers probably need to support RADIUS and the existing RADIUS over (D)TLS anyway.  So really we're talking about an "SRADIUS" configuration flag.  If a site requires FIPS, why can't it flip the SRADIUS flag and run its SRADIUS server on port 2083?  If some devices can't connect to an SRADIUS-configured server, then those devices don't support SRADIUS and presumably the site wants to point them at another server (one without the SRADIUS flag set), and eventually replace them with devices that support SRADIUS. 

  Pretty much, yes.  It would be very preferable to re-use port 2083.

  I looked into Alex's suggestion of TLS extensions, and the good news is that application layer protocol negotiation (ALPN) is defined in RFC 7301 [1], and is supported by OpenSSL [2].

  So we could require that SRADIUS is used (a) either via static configuration, or (b) signalled via ALPN.  If a both ends signal support for SRADIUS via ALPN, then that could be used.

  We don't have to worry much about down-bidding attacks, as there is no change in security when using RADIUS with MD5, or without MD5.  Everything is still protected by TLS.

  A server which accepts either kind of packet can signal support for both standard RADIUS and SRADIUS.  A server which only supports SRADIUS must necessarily signal that to the client, but can refuse to accept connections which don't signal SRADIUS support via ALPN.

  The benefit here is that there is no need for a "flag day".  People can upgrade (or not) their systems as they wish.  There's also no need to change RFC 7585 (dynamic peer discovery).

 
 I think that addresses all of the concerns around signalling, "new" protocols, and flag days.

  For me, the only thing left is the name.  If we're re-using port 2083, then the name "SRADIUS" is misleading.  It should instead be labelled as a variant of RADIUS, such as "RADIUS+" or "RADIUS2".  Or even "RADIUS+FIPS".

  Vendors supporting this variant can simply set a flag (required / allowed) to use RADIUS without MD5. 

  I would lean towards naming it something like "RADIUS+FIPS", in order to solve the political-layer problem of FIPS compatibility.  "See?  It's FIPS compatible, the name says so!"


  Alan DeKok.

[1] https://datatracker.ietf.org/doc/html/rfc7301

[2] https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_alpn_select_cb.html