Last Call Review of draft-ietf-radext-radiusv11-08
review-ietf-radext-radiusv11-08-secdir-lc-leiba-2024-06-26-00

Thanks for this important update: getting rid of MD5 is quite overdue, and will
make a long-term difference.

The Abstract seems longer and more detailed than necessary.  In particular, I
would strike the second paragraph completely, as it’s detail that doesn’t need
to be in the Abstract.  I also think the last two sentences of the first
paragraph add detail that’s unnecessary in the Abstract.

— Section 1 —

I am concerned that you do not UPDATE 2865 or 6613, yet you say this:

   While this document permits MD5 to be removed when using (D)TLS
   transports, it makes no changes to UDP or TCP transports.  It is
   therefore RECOMMENDED that those transports only be used within
   secure networks, and only used in situations where FIPS compliance is
   not an issue.

Without the update to 2865 and 6613, how are implementors of the UDP and TCP
transports supposed to be aware of the RECOMMENDED statement above?  I think
this document should update 2865 and 6613, and that the statement above should
be at a MUST level, not a SHOULD, as this:

NEW
   While this document permits MD5 to be removed when using (D)TLS
   transports, it makes no changes to UDP or TCP transports.  It
   therefore follows that those transports MUST NOT be used outside of
   secure networks, and MUST NOT be used in situations where FIPS
   compliance is needed.
END

Near the end of the section is this:

   This specification is compatible with all past and future RADIUS
   specifications.

You can’t possibly promise compatibility with all future versions.  Maybe you
could change “future” to “anticipated”, or maybe just reconsider mentioning
that at all.

— Section 3.3 —

   When set, this flag contains the list of permitted ALPN versions in
   humanly readable form.

The flag contains the list of permitted RADIUS versions, not ALPN versions.

I have to say that I find this section to be pretty confusing.  I write it off
to the fact that I’m not generally familiar with RADIUS and the associated
documents, and I hope that RADIUS practitioners do fint it clearer than I do. 
In particular, I don’t get the distinction between the Version flag and the
ALPN name, and why both are needed when they each seem to identify the same
thing.  But again, I’m sure this just reflects my lack of familiarity with this.

— Section 10 —

The one-sentence security considerations doesn’t show any actual consideration
of the security properties of the changes proposed here.  I think you need to
spend some time looking at what happens when someone gets the implementation
wrong, when someone tries to attack this… just as other protocols do when they
write their Security Considerations section.  But I’ll leave that to the
Security ADs to sort out with you when they ballot DISCUSS….

— References —

Nit: the appearance of BCP 14 at the start of the references section is
redundant to the RFC 8174 reference at the end of the section.  You can remove
the former.