Revised Requirements for RADIUS crypto-agility

["David B. Nelson" <d.b.nelson@comcast.net>]

Herewith are the revised requirements for RADIUS Crypto-Agility,
based on the discussions held at IETF-68.

OVERALL APPROACH

1. RADIUS crypto-agility solutions are not restricted to utilizing
technology described in existing RFCs.  Since RADIUS over IPsec is
already described in RFC 3162 and 3579, this technique is already
available to those who wish to use it.  Therefore it is expected that
proposals will utilize other techniques.

SECURITY SERVICES

2. 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.
If possible, it is desirable for proposals to provide for the
encryption of existing attributes.  This includes existing "hidden"
attributes as well as attributes (such as location attributes) that
require confidentiality.

Included in negotiation techniques are "hint and consent" mechanisms
where the NAS provides a list of algorithms and the server selects
one.
 
3. Proposals MUST support replay protection.  The existing mechanisms
for replay protection are considered adequate and should be maintained.

4. Crypto-agility solutions MUST specify mandatory-to-implement
algorithms for each mechanism.

BACKWARD COMPATIBILITY

5. Solutions to the problem MUST demonstrate backward compatibility
with existing RADIUS implementations.  That is, a crypto-agility
solution needs to be able to send packets that a legacy RADIUS client
or server will receive and process successfully.  Similarly, a
crypto-agility solution needs to be capable of receiving and processing
packets from a legacy RADIUS client or server.

6. Crypto-agility solutions MUST avoid security compromise, even
in situations where the existing cryptographic algorithms utilized by
RADIUS implementations are shown to be weak enough to provide little or
no security (e.g. in event of compromise of the "legacy" RADIUS shared
secret). Included in this would be protection against bidding down 
attacks.

INTEROPERABILITY AND CHANGE CONTROL

7. Proposals MUST indicate a willingness to cede change control to
the IETF.

8. Crypto-agility solutions MUST be interoperable between independent
implementations based purely on the information provided in the
specification.

SCOPE OF WORK

9. Crypto-agility solutions MUST apply to all RADIUS packet types,
including Access-Request, Challenge, Reject & Accept,
Accounting-Request/Response, and CoA/Disconnect messages.
 
10. Proposals MUST include a Diameter compatibility section, although
it is expected that the work will occur purely within RADIUS or in the
transport, and therefore does not affect message data that is exchanged
with Diameter.
 
11. Crypto-agility solutions SHOULD NOT require fundamental changes to
The RADIUS operational model, such as the introduction of new commands
Or maintenance of state on the RADIUS server.  Similarly, a proposal 
Should focus on the crypto-agility problem and nothing else.  For 
example, proposals should not require new attribute formats or include
definition of new RADIUS services.  Unless modified, the restrictions
in the RADEXT WG charter apply.

Note that for the purposes of this work, the 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.

Regards,

Bernard Aboba
Dave Nelson

RADEXT Co-Chairs




--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>