Re: [secdir] SECDIR review of draft-ietf-radext-radsec-11

[Stefan Winter <[e-mail]>]

Hello,

thanks for the review!

> -- I would strongly advise changing all instances of the phrase
> "acceptable Certification Authority" to "trusted Certification
> Authority" in order to be consistent with terminology in TLS 1.2 (RFC
> 5246). (I found instances of the phrase "acceptable Certification
> Authority" on the bottom of page 5 and the top of page 6.) I would also
> change "acceptable certificate" to "trusted certificate" in the
> fingerprint bullet on page 6.

Thanks, changed the occurences in my working copy (to be -12).

> -- In bulleted list number 2 on page 5 (Section 2.3), bullets 4 and 9
> seem to be redundant.

That's right, thanks for spotting. I deleted bullet 9.

> Furthermore, I find it unusual to have a normative
> mandate that compliant implementations MUST NOT negotiate ciphersuites
> that do not provide confidentiality protection. (It is very common when
> discussing ciphersuite negotiation to mandate that implementations
> support certain ciphersuites offer confidentiality protection, but
> saying that a user MUST NOT be able to configure the implementation to
> use a NULL-encryption cipher suite is quite unusual.) After reading the
> security considerations section, I believe that the reason you have this
> normative requirement is because RADIUS packets include user-passwords
> which always require confidentiality protection. However, because the
> normative requirement is unusual, I would either add a sentence to 2.3
> explaining the requirement or else put a forward reference to Section 6
> (Security Considerations) for explanation.

Forbidding NULL-encryption was indeed a conscious decision, for the
reasons you already stated. RADIUS, even if providing poor
confidentiality when looked at today, could not be deployed at all
without security. An empty shared secret was disallowed as per spec, and
every client had to be configured with a unique shared key. That
behaviour is equivalent to forbidding NULL-encryption. It would have
been a regression in security to allow NULL-encryption to happen with
RADIUS/TLS.

Given that there is already extensive text in Security Recommendations,
I think the easiest way to address your comment is by making the forward
reference to that section.

In my working copy, the bullet in 2.3 now reads:

       *  Negotiation of a ciphersuite providing for confidentiality as
          well as integrity protection is REQUIRED.  Failure to comply
          with this requirement can lead to severe security problmes,
          like user passwords being recoverable by third parties.  See
          Section 6 for details.

> -- I found the fingerprint bullet on page 6 to be a bit confusing. My
> understanding (after reading it several times) is that you are
> specifying a particular ASCII encoding for certificate fingerprints. In
> particular, you are mandating that each of the 20 bytes of the
> certificate fingerprint be encoded as a pair of hexadecimal digits and
> that the encoding for the fingerprint is the string "sha-1:" followed by
> the encodings of these 20 bytes separated by colons. I am not sure what
> the clearest way is to get across this meaning. However, the first time
> I read I read the current text it was not clear to me that the document
> was mandating a particular ASCII encoding of certificate fingerprints.
> (Question: Is there an interoperability failure if two RADIUS devices do
> not agree on the encoding of a certificate fingerprint? If the
> fingerprint is just something that is configured, calculated and used
> locally then it doesn't seem to matter whether one implementation uses
> the ASCII string: "sha-1:E1:2D:53 ... 9D" and another implementation
> uses the UTF-8 string "SHA-1:e1:2d:53 ... 9d".)

That is a very good question. Indeed the encoding of the hash is a local
configuration item and has no significance over the wire.

There could be situations where a common way of expressing such a
configuration item may make sense. I have another example of
fingerprint-based identification in mind: SAML metdata. Different
implementations have an easier time parsing configuration data if
there's a normative encoding to it. I could imagine an organisation to
have multiple RADIUS servers from different vendors, relying on the same
list of fingerprints for their accepted clients. For such cases, having
an agreed syntax might be beneficial.

That said, more than this text would be needed to achieve that goal, and
I guess it's not worth going into such detail at this stage.

I could live with taking away the prescribed syntax, which would
significantly shorten the paragraph:

	  Implementations SHOULD allow to configure a list of trusted
          certificates, identified via certificate fingerprint.
          Implementations MUST support SHA-1 as the hash algorithm.

Please let me know if that's okay for you.

(Note that the paragraph might get reshuffled slightly due to a comment
in Sam Hartman's security review; 5280 validation might be inadequate if
you trust manually configured fingerprints).

Greetings,

Stefan Winter

-- 
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: [phone]
Fax: [phone]