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: stefan.winter@restena.lu > > To: radiusext@ops.ietf.org > > CC: trac+radext@zinfandel.tools.ietf.org; bernard_aboba@hotmail.com > > 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
Attachment:
signature.asc
Description: OpenPGP digital signature