Requirements and Selection Process for

RADIUS Crypto-AgilityDecember 5, 2007

David B. NelsonIETF 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 agilitywork 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 withoutadding some form of automated key management doesn't have a lot ofvalue and may not be worth doing.

However if there are users and implementers who see the value in doingthe crypto agility updates, then perhaps it makes sense to do.

So, my question to you is what is driving this work besides a desireto be good security citizens?

Discussion points…Follow up discussion on the RADEXT list:

David> Well, besides that, some folks at Cisco expressed a desireDavid> to replace the crypto elements of RADIUS (e.g. key wrap,David> MAC, etc.) with algorithms and modes that would allowDavid> systems including RADIUS to receive FIPS certification, forDavid> solutions in government and financial services markets.

David> Additionally, the folks behind the EduRoam consortium inDavid> Europe have deployed RADIUS over TLS for inter-universityDavid> roaming authentication.

Sam: I think automated key management is important for both of these use cases.

Feedback?