Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap

["Joseph Salowey \(jsalowey\)" <jsalowey@cisco.com>]

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.

[Joe] Algorithms within the proposal are identified so they can be
replaced.  The client can specify the algorithm it wishes the server to
use.  

 
3. Proposals MUST support replay protection.  The existing mechanisms
for replay protection are considered adequate and should be maintained.

[Joe] Existing replay protection mechanisms are maintained

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

[Joe] Mandatory to implement algorithms are specified (AES-CBC,
AES-Keywrap, HMAC-SHA1)

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.

[Joe]  The proposal requires the use of new RADIUS attributes.  All
other aspects of the RADIUS protocol can remain the same, so backward
compatibility is possible.  However it is important to note that if
stronger that current security algorithms are required then backwards
compatibility is not possible.

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.

[Joe] Depending upon the selection of the key the new protection can be
completely separate from the existing protection.  The selection of the
key is currently a deployment choice.  


INTEROPERABILITY AND CHANGE CONTROL

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

[Joe] Change control can be cede. An informational RFC may be published
to document existing implementations. 

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

[Joe] Interoperable implementations exist based on this specification.
These implementations use VSAs instead of standard attributes. 

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.
 
[Joe] The attributes described can be added to any of these mechanisms. 

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.

[Joe] A Diameter compatibility section will need to be added. 
 
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.

[Joe] This solution works well with the existing implementations.  It
does not require major changes to the RADIUS protocol.  In particular it
does not necessarily introduce new "session" state maintenance
requirements on the server.  

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. 

[Joe] This is what the proposal does.  It is very close to existing
RADIUS protection mechanisms requiring minimal change to existing
implementations. 

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