Subject: Re: [radext] #93: Compliance with Crypto-Agility Requirements

From: Stefan Winter <[email-masked]>
Date: Mon, 27 Jun 2011 09:15:23 +0200

Hi,

> This material might be appropriate for inclusion in an Appendix so
> that it wouldn't clutter the main text.
>
> Interesting point with respect to TLS_RSA_WITH_3DES_EDE_CBC_SHA. 
> Since later TLS RFCs provide recommendations on implementations of
> algorithms that would be "Acceptable" with
> no known deprecation date, would it make sense for the document to
> incorporate that guidance (even though it only requires earlier
> versions of  TLS)?

Well, guidance is alright, but not sufficient. The Crypto-Agility
Requirements speak of

> RECOMMENDED that mandatory-to-implement cryptographic
> algorithms be chosen from among those classified as "Acceptable" with
> no known deprecation date.

So it's about mandatory-to-implement algorithms; not
recommended-to-implement algorithms. Of course, the draft could be
changed to make TLS_RSA_WITH_AES_128_CBC_SHA the required-to-implement
algorithm. That would fix the crypto-agility-req point; but it might
render some TLS 1.1 implementations not compatible to that new draft
spec because in 1.1, that ciphersuite was optional.

Greetings,

Stefan

>
> > Date: Fri, 13 May 2011 15:51:13 +0200
> > From: [email-masked]
> > To: [email-masked]
> > CC: [email-masked]; [email-masked]
> > Subject: Re: [radext] #93: Compliance with Crypto-Agility Requirements
> >
> > 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
> >
> >

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