Requirements and Selection Process for RADIUS Crypto-Agility December 5, 2007 David B. Nelson IETF 70 Vancouver, BC

The Goals To develop one or more backward compatible, interoperable mechanisms for the negotiation of cryptographic algorithms within RADIUS. To satisfy the mandate from the Security Area Directorate for all IETF working groups to evaluate the feasibility for adding crypto-agility to existing IETF protocols, and propose solutions where feasible.

Process Steps (1/2) Discuss and refine the requirements for a solution to the problem, coming to consensus at IETF 68 in Prague - DONE Issue a call for document submissions meeting the problem requirements, during IETF 68, requesting documents be submitted for consideration within 30 days – DONE Authors to submit evaluation of proposals against the requirements – DONE Address the Automated Key Management requirement of RFC 4107, and discussion on the list from Sam Hartman.

Process Steps (2/2) Discussion of the proposals at IETF 69 ^H^H 70 and on the RADEXT WG mailing list. If consensus emerges, adoption of the winning proposal as a Standards Track WG work item. If consensus does not emerge, acceptance of one or more documents with substantial support as Experimental Track WG work items. Completion of work and submission of documents to the IESG.

Requirements (1/5) Proposals are not restricted to utilizing technology described in existing RFCs. Proposals MUST support the negotiation of cryptographic algorithms for per-packet integrity/authentication protection. Support for confidentiality of entire RADIUS packets is OPTIONAL. However, proposals MUST support the negotiation of algorithms for encryption (sometimes referred to as "hiding") of RADIUS attributes. It is desirable for proposals to provide for the encryption of existing attributes.

Requirements (2/5) Proposals MUST support replay protection. Existing mechanisms for replay protection of RADIUS messages are inadequate. Crypto-agility solutions need to specify mandatory-to- implement algorithms for each mechanism. Proposals need to demonstrate backward compatibility with existing implementations. A solution needs to be able to send packets that a legacy RADIUS client or server will receive and process successfully. A solution needs to be capable of receiving and processing packets from a legacy RADIUS client or server.

Requirements (3/5) Proposals need to avoid security compromise, even where the RADIUS shared secret is exposed. This includes protection against bidding down attacks. Proposals need to cede change control to the IETF. Proposals need to be interoperable between independent implementations based purely on the information provided in the specification. Proposals need to apply to all RADIUS packets. Proposals MUST include a Diameter compatibility section.

Requirements (4/5) Proposals SHOULD NOT require fundamental changes to the RADIUS operational model. Addition of new capabilities to the RADIUS protocol is out of scope; a proposal should focus on the crypto- agility problem and nothing else. Proposals should not require new attribute formats or include definition of new RADIUS services. RADEXT WG charter restriction against definition of "new security mechanisms" should be interpreted as prohibiting changes to the basic RADIUS packet format (e.g. headers), but permits new crypto- algorithms to be substituted for use in existing security mechanisms.

Requirements (5/5) - new Proposals MUST address the requirements of RFC 4107 for Automated Key Management. Is this the consensus of the WG? If this requirement would result in a blocking DISCUSS in IESG review, do we want to go forward? If we agree with this requirement, then all submitted proposals need a write-up as to how provide Automated Key Management.

Discussion points… Sam Hartman (Security Area AD) wrote on the RADEXT mailing list: I think that the applicability of RFC 4107 to radius crypto agility work is kind of complicated. I guess my main question is who is driving the work, who will use it. My personal opinion is that updating radius crypto agility without adding some form of automated key management doesn't have a lot of value and may not be worth doing. However if there are users and implementers who see the value in doing the crypto agility updates, then perhaps it makes sense to do. So, my question to you is what is driving this work besides a desire to be good security citizens?

Discussion points… Follow up discussion on the RADEXT list: David> Well, besides that, some folks at Cisco expressed a desire David> to replace the crypto elements of RADIUS (e.g. key wrap, David> MAC, etc.) with algorithms and modes that would allow David> systems including RADIUS to receive FIPS certification, for David> solutions in government and financial services markets. David> Additionally, the folks behind the EduRoam consortium in David> Europe have deployed RADIUS over TLS for inter-university David> roaming authentication. Sam: I think automated key management is important for both of these use cases.

Feedback?