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