Dear radext issue tracker, all,
below is a discussion of all the requirements. It is somewhat verbose; I
wonder if it should go into the document in its entirety or if a
condensed "I believe it's allright" statement would be enough.
Note that I'm not sure whether TLS_RSA_WITH_3DES_EDE_CBC_SHA is a
two-key or a three-key 3DES algorithm. This condition would be the only
one that could downgrade the proposal from "unconditionally compliant"
to "conditionally compliant". Note also that there's a proposed
mitigation for that in the text below.
Here goes:
The Requirements
================
4.2: Security Services
MUST support the negotiation of cryptographic algorithms for per-packet
integrity/authentication protection.
-> Check, TLS allows negotiation of cipher suites and thus cryptographic
algorithms.
MUST support per-packet replay protection for all RADIUS message types.
-> Check, TLS allows for replay protection.
MUST specify mandatory-to-implement cryptographic algorithms for each
defined mechanism.
-> Check, see section 2.3.2
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
-> Check, the RADIUS shared secret is of no cryptographic significance
RECOMMENDED that mandatory-to-implement cryptographic
algorithms be chosen from among those classified as "Acceptable" with
no known deprecation date.
-> UNKNOWN:
The mandatory-to-implement alogrithm is TLS_RSA_WITH_3DES_EDE_CBC_SHA,
is a three-key Triple DES Encryption and Decryption algorithm ** IS THIS
TRUE??? **,
which is classified as "Acceptable" without deprecation date in the
document in question.
Can be mitigated; TLS 1.2 makes TLS_RSA_WITH_AES_128_CBC_SHA
mandatory-to-implement,
which fulfills the NIST "Acceptable" in any case. Could raise TLS
requirements to strictly 1.2 and above.
RECOMMENDED that solutions provide support for confidentiality
-> Check, encryption of entire RADIUS packets is supported.
MUST support the negotiation of cryptographic algorithms for encryption.
-> Check, TLS allows negotiation of cipher suites and thus cryptographic
algorithms.
REQUIRED to generate fresh session keys for use between the RADIUS
client and server
-> Check, TLS session keys fulfill requirement.
RECOMMENDED to support Perfect Forward Secrecy (PFS) with respect to
session keys
negotiated between the RADIUS client and server.
-> Check, TLS supports PFS when negotiating appropriate ciphers.
RECOMMENDED that a RADIUS crypto-agility solution
support X.509 certificates for authentication between the NAS and
RADIUS server.
-> Check.
SHOULD also support pre-shared key credentials.
-> Check.
4.3: Backwards Compatibility
MUST demonstrate backward compatibility with existing RADIUS
implementations.
-> Check, there are multiple implementations which support RADIUS and
RADIUS/TLS,
and can act as a translator between the two
After legacy mechanisms have been compromised, secure algorithms MUST be
used,
so that backward compatibility is no longer possible.
-> Check, RADIUS clients always need to manually configured (IP and
shared secret needed),
and can thus be de-configured after the compromise.
4.4: Interoperability and Change Control
MUST indicate a willingness to cede change control to the IETF.
-> Check, change control is at IETF.
MUST be interoperable between independent implementations based purely
on the
information provided in the specification.
-> Check, at least one implementation was created according to draft
specs only.
4.5: Scope of Work
Crypto-agility solutions MUST apply to all RADIUS packet types
-> Check, crypto-agility is achieved on transport layer, and agnostic to
RADIUS content.
message data exchanged with Diameter SHOULD NOT be affected.
-> Check, the solution is Diameter-agnostic.
MUST discuss any inherent assumptions about, or limitations on,
client/server operations or deployment
-> Believed to be a check, as I don't think I have unarticulated
assumptions in my head,
hence nothing to be discussed.
SHOULD provide recommendations for transition of deployments from legacy
RADIUS to
crypto-agile RADIUS.
-> Check, see Security Considerations.
Issues regarding cipher-suite negotiation,
legacy interoperability and the potential for bidding down attacks,
SHOULD be among these discussions.
-> Check, see Security Considerations.
4.6: Applicability of Automated Key Management Requirements
As a result, support for Automated Key Management is RECOMMENDED within a
RADIUS crypto-agility solution.
-> Check; TLS supports PFS and thus supports AKM.
automated key management is REQUIRED for RADIUS crypto-agility
solutions that use cryptographic modes of operation that require
frequent key changes.
-> Check.
Am 29.04.2011 18:48, schrieb radext issue tracker:
> #93: Compliance with Crypto-Agility Requirements
>
> The Crypto-Agility Requirements document now in WG last call (see
> http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements )
> includes the following in Section 1.4:
>
> In the initial phase, crypto-agility solutions adopted by the working
> group will be published on the Experimental Track. Experimental
> Track documents should contain a description of experimental
> deployments and implementations in progress, as well as an evaluation
> of the proposal against the requirements described in this document.
>
>
> The RADSEC document currently does not include this information.
>
--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - RÃseau TÃlÃinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
Tel: +352 424409 1
Fax: +352 422473
Attachment:
signature.asc
Description: OpenPGP digital signature