[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Revised Requirements for RADIUS crypto-agility
Herewith are the revised requirements for RADIUS Crypto-Agility,
based on the discussions held at IETF-68.
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.
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
Included in negotiation techniques are "hint and consent" mechanisms
where the NAS provides a list of algorithms and the server selects
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.
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
INTEROPERABILITY AND CHANGE CONTROL
7. Proposals MUST indicate a willingness to cede change control to
8. Crypto-agility solutions MUST be interoperable between independent
implementations based purely on the information provided in the
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
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.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.