Thanks, Alan, for the quick response, and it all looks good. Barry On Wed, Jun 26, 2024 at 6:19 PM Alan DeKok <aland@xxxxxxxxxxxxxx> wrote: > > On Jun 26, 2024, at 3:17 PM, Barry Leiba via Datatracker <noreply@xxxxxxxx> wrote: > > Thanks for this important update: getting rid of MD5 is quite overdue, and will > > make a long-term difference. > > Thanks. It's been a long haul to get here. > > > 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. > > I'm OK with that. Deleted. > > > — 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, > > I'll leave it to the ADs. The discussion in the WG was that an experimental document shouldn't update a standards-track one. > > For implementations, they will already be reading https://datatracker.ietf.org/doc/draft-ietf-radext-deprecating-radius/ > > That document has similar text, and already updates 2865, etc. > > > and that the statement above should > > be at a MUST level, not a SHOULD, as this: > > I don't think it's good to have mandatory changes to a standards track document in a document labelled "experimental". > > There's also https://datatracker.ietf.org/doc/draft-ietf-radext-radiusdtls-bis/ > > Which is putting TLS transport into standards track. That document can mandate updates. > > So I think the text here is informative, and is likely OK as -is. > > > 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. > > Sure. > > > — 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'll clarify the text. The intent was to allow administrators to use version numbers, without reference to ALPN strings. i.e. if the ALPN string is "radius/1.0", and the administrator enters "RaDiuS/1.0", then negotiation won't work. > > It seems easier to allow "1.0" and "1.1" in an administration interface, and then rely on the implementation to translate that to the correct ALPN string. > > > — 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…. > > Sure. How about: > > > The primary focus of this document is addressing security considerations for RADIUS. This specification relies on TLS and associated ALPN negotiation for much of its security. We refer the reader to {{RFC8446}} and {{7360}} for discussions of the security of those protocols. The discussion in this section is limited to issues unique to this specification. > > Implementations should rely on the underlying TLS library to perform ALPN version negotiation. That is, implementations should supply a list of permitted ALPN strings to the TLS library, and let it return the negotiated value. > > There are few other opportunities for security issues. If an implementation gets ALPN negotiation wrong, then the wrong application data will be transported inside of TLS. While RADIUS/1.0 and RADIUS/1.1 share similar packet formats, the protocols are not mutually compatible. > > RADIUS/1.0 requests sent over a RADIUS/1.1 connection may be accepted by the RADIUS/1.1 server, as the server will ignore the ID field, and try to use portions of the Request Authenticator as a Token. However, the reply from the RADIUS/1.1 server will fail the Response Authenticator validation by the RADIUS/1.0 client. The responses will therefore be dropped. The client will generally log these failures, and an administrator will address the issue. > > RADIUS/1.1 requests sent over a RADIUS/1.0 connection will generally be discarded the the RADIUS/1.0 server, as the packets will fail the Request Authenticator checks. That is, all request packets such as Accounting-Request, CoA-Request, and Disconnect-Request will be discarded by the server. For Access-Request packets containing EAP-Message, the packets will be missing Message-Authenticator, and will therefore be discarded by the server. Other Access-Request packets contain obfuscated attributes such as User-Password will have those attributes decoded to nonsense, and will thus result in Access-Reject responses. > > RADIUS/1.1 Access-Request packets containing non-obfuscated attributes such as CHAP-Password may be accepted by a RADIUS/1.0 server but the response will contain a Response Authenticator (i.e. MD5 hash), and not a Token which matches the Token in the request. A similar analysis applies for Access-Request packets containing Service-Type = Authorize-Only. > > In conclusion, any mismatch of versions between client and server will result in most request packets being discarded by the server, and all response packets being discarded by the client. The two protocols are therefore incompatible, and safe from misconfigurations or erroneous implementations. > > > — 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. > > Done. > > Alan DeKok. > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
