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

[Alan DeKok <[e-mail]>]

On Nov 22, 2022, at 10:38 AM, Bernard Aboba <[e-mail]> wrote:
> [BA] That's my take as well.  RADIUS over (D)TLS won't need MD5 in the authenticator anyway, so why not specify how to avoid this usage within the specs?  Why is it necessary to define an entirely new protocol??

  RFC 6614 (TLS) and RFC 7360 (DTLS) both mandate the use of packet signing with MD5, and the shared secret of "radsec".  See https://www.rfc-editor.org/rfc/rfc6614#section-2.3

   4.  start exchanging RADIUS datagrams (note Section 3.4 (1)).  The
       shared secret to compute the (obsolete) MD5 integrity checks and
       attribute encryption MUST be "radsec" (see Section 3.4 (2)).

  If we wanted to remove MD5 from TLS/DTLS transports, the time to do it would have been when those standards we published.  I must confess I was one of the people saying "meh, leave MD5 in TLS transport".  In hindsight, that decision looks to be wrong.

  I'm not sure that we want to re-define the meaning of RADIUS/TLS and RADIUS/DTLS to allow for removal of MD5 from RADIUS packet signing.  It's not clear how we would modify those protocols to allow for secure negotiation of "use MD5 or not".

  If such negotiation was possible, it would be subject to down-bidding attacks.  It could be difficult to debug interoperability issues.

  The SRADIUS proposal doesn't just say "remove MD5".  It also requests a new port from IANA.  At which point there is no negotiation of capabilities, and no confusion over what traffic on that port means.

  If we can find a way to re-use port 2083 for "RADIUS without MD5", I'm all for it.  But I'd like to see how we can implement and deploy that without breaking existing systems.

  Alan DeKok.