Requirements%20and%20Selection%20Process%20for%20RADIUS%20Crypto-Agility

1
Requirements and Selection Process for RADIUS
Crypto-Agility

• December 5, 2007
• David B. Nelson
• IETF 70
• Vancouver, BC

2
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.

3
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.

4
Process Steps (2/2)

• Discussion of the proposals at IETF 69 HH 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.

5
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.

6
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.

7
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.

8
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.

9
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.

10
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?

11
Discussion points

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

12
Feedback?