Requirements and Selection Process for RADIUS CryptoAgility

1
Requirements and Selection Process for RADIUS
Crypto-Agility

• July 26, 2007
• David B. Nelson
• IETF 69
• Chicago, IL

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

4
Process Steps (2/2)

• Discussion of the proposals at IETF 69 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/4)

• 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/4)

• 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/4)

• 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/4)

• 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
Feedback?