Re: Thoughts on Requirements for RADIUS crypto-agility

[Hannes Tschofenig <Hannes.Tschofenig@gmx.net>]

Hi David,

here are my thoughts. Let me start with a differentiation between
a) authentication and key exchange  (including the negotiation of 
algorithms)
b) protection of the messages.

As you mention one could use IPsec (together with IKE/IKEv2) to make the 
entire discussion irrelevant.

Assuming that IPsec is not used one obviously needs to consider (a) and 
(b) to offer a complete solution.
So, here are useful options:

1) DTLS
Provides (a) and (b) in one proposal.
2) IKEv1 + DoI for RADIUS packet protection security
Uses IKEv1 for (a) and per-packet protection for (b)
3) DTLS + sort-of-DoI for RADIUS packet protection security (as used 
with DTLS based media security proposal)
Uses DTLS handshake for (a) and per-packet protection for (b)

Do I entirely miss something here?

Ciao
Hannes

I would deprecate the per-packet David B. Nelson wrote:
> As noted in the previous message, the first stage in the development of 
> a RADIUS crypto-agility solution is to formulate a requirements statement. 
>
> A straw-man set of requirements is included below:
>
> 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. 
>
> 3. Proposals MUST support replay protection.  It has been noted that 
> existing mechanisms for replay protection of Accounting-Request/Response, 
> CoA-Request/Response and Disconnect-Request/Response messages are 
> inadequate.
>
> 4. Crypto-agility solutions need to specify mandatory-to-implement
> algorithms for each mechanism.
>
> BACKWARD COMPATIBILITY
>
> 5. Solutions to the problem need to 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 need to 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 RADIUS shared secret).  
> Included in this would be protection against bidding down attacks. 
>  
> INTEROPERABILITY AND CHANGE CONTROL
>
> 7. Proposals need to indicate a willingness to cede change control to the 
> IETF. 
>
> 8. Crypto-agility solutions need to be interoperable between independent 
> implementations based purely on the information provided in the 
> specification. 
>  
> SCOPE OF WORK
>
> 9. Crypto-agility solutions need to 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. 
>
> 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, the addition of 
> new capabilities to the RADIUS protocol is out of scope; 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/>
>   


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