lift and shifted (d)tls crypto-agility into draft-ietf-radext-radiusd…

…tls-bis.git

draft-ietf-radext-deprecate-radius.md

@@ -882,17 +882,7 @@ In contrast, (D)TLS gives the RADIUS application completely knowledge and contro
 
 ## Crypto-Agility
 
-The crypto-agility requirements of {{RFC6421}} are addressed in {{RFC6614}} Appendix C, and in Section 10.1 of {{RFC7360}}.  For clarity, we repeat the text of {{RFC7360}} here, with some minor modifications to update references, without changing the content.
-
-Section 4.2 of {{RFC6421}} makes a number of recommendations about security properties of new RADIUS proposals.  All of those recommendations are satisfied by using TLS or DTLS as the transport layer.
-
-Section 4.3 of {{RFC6421}} makes a number of recommendations about backwards compatibility with RADIUS.  {{RFC7360}} Section 3 addresses these concerns in detail.
-
-Section 4.4 of {{RFC6421}} recommends that change control be ceded to the IETF, and that interoperability is possible.  Both requirements are satisfied.
-
-Section 4.5 of {{RFC6421}} requires that the new security methods apply to all packet types.  This requirement is satisfied by allowing TLS and DTLS to be used for all RADIUS traffic.  In addition, {{RFC7360}} Section 3, addresses concerns about documenting the transition from legacy RADIUS to crypto-agile RADIUS.
-
-Section 4.6 of {{RFC6421}} requires automated key management.  This requirement is satisfied by using TLS or DTLS key management.
+The crypto-agility requirements of {{RFC6421}} are addressed in {{RFC6614}} Appendix C, and in Section 10.1 of {{RFC7360}}.  We refer readers to those documents for details on crypto-agility.
 
 We can now finalize the work began in {{RFC6421}}.  This document updates {{RFC2865}} to state that any new RADIUS specification MUST NOT introduce new "ad hoc" cryptographic primitives to authenticate packets as was done with the Request / Response Authenticator, or to obfuscate attributes as was done with User-Password and Tunnel-Password.  We allow legacy RADIUS-specific cryptographic methods existing as of the publication of this document to be used for historical compatibility.  However, all new cryptographic work which is specific to the RADIUS protocol is forbidden.