RE: Thoughts on Requirements for RADIUS crypto-agility

["Avi Lior" <avi@bridgewatersystems.com>]

Given the charter and specifically:

"- No new security mechanisms will be defined for protecting RADIUS." 

Why do you think we can do this work?


-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of David B. Nelson
Sent: Thursday, February 22, 2007 6:23 PM
To: 'radext mailing list'
Subject: Thoughts on Requirements for RADIUS crypto-agility

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