search

radext-wg / draft-ietf-radext-radiusdtls-bis

Other
1 stars 3 forks source link

Security Consideration: Crypto-Agility #18

Open ethan-thompson opened 2 months ago

ethan-thompson commented 2 months ago

Added some basic text to reference the Deprecating Insecure Practices in RADIUS document (to address RFC 7360 Section 10.1)

alandekok commented 2 months ago

Perhaps

Crypto-Agility

Crypto-agility requirements were discussed extensively in {{RFC6421}}. {{RFC6614, Appendix C}} described how these requirements were met for RADIUS/TLS. {{RFC7360, Section 10.1}} described how these requirements were met for RADIUS/DTLS. The final outcome of the {{RFC6421}} crypto-agility requirements are discussed in {{?I-D.ietf-radext-deprecating-radius, Section 6.3}}.

This specification defers to {{?I-D.ietf-radext-deprecating-radius}} for all discussion of crypto-agility in RADIUS. In short, TLS satisfies the requirements of {{?I-D.ietf-radext-deprecating-radius}}, and there is no need to define RADIUS-specific cryptographic primitives.

ethan-thompson commented 2 months ago

Yes, I like your suggestion much better

Janfred commented 1 month ago

I also like the suggestion from Alan. I'd reference the deprecating radius draft as normative and have them published as cluster. (But that's editorial. The content looks good to me)

alandekok commented 1 month ago

I'd prefer to publish the deprecating document first. It's essentially done. Given issues like the BlastRADIUS vulnerability, I think it's preferable to have an official RFC describing what to do. Otherwise as we've seen, implementors may do "inventive" things.

The TLSbis document is likely to take a while to settle.

Janfred commented 1 month ago

Fine by me, in this case it's even easier to reference it as normative.