Subject: Re: Issue RADSEC certificate handling

From: Stefan Winter <[email-masked]>
Date: Mon, 01 Mar 2010 15:27:58 +0100

Hi,

> Requested change:
>
> 1. The discussion of TLS cipher suites is broken apart into several
> places in the document, some of them normative and some of them
> informative.  I believe the normative and informative information is
> reversed.  The implementation requirements for supported cipher suites
> should go in this section.
>   

Looking at the current text, the following is said in normative (2.2):

"       *  The client MUST NOT negotiate cipher suites which only provide
          integrity protection.

       *  The TLS session MAY use mutual PSKs for connection setup.

       *  Negotiation of compression for the TLS session is OPTIONAL.

       *  RADIUS over TLS implementations MUST support the mandatory to
          implement cipher suites specified in TLS (i.e.
          TLS_RSA_WITH_3DES_EDE_CBC_SHA).  For purposes of compatibility
          with some current deployments implementations SHOULD support
          TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as
          well (see Section 3.2 (1) )."

The following is said in informative (3.2):

"3.2.  Ciphersuites and Compression Negotiation Considerations

   Not all TLS ciphersuites in [RFC5246] are supported by available TLS
   tool kits, and licenses may be required in some cases.  The existing
   implementations of RADIUS over TLS use OpenSSL as cryptographic
   backend, which supports all of the ciphersuites listed in the rules
   in the normative section.

   The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to-
   implement according to [RFC5246] and thus has to be supported by
   RADIUS over TLS nodes.

   The two other ciphersuites in the normative section are widely
   implemented in TLS toolkits and are considered good practice to
   implement."

This text doesn't contain any additional requirements to be mentioned in
normative text IMO (note that the one named ciphersuite here is also
already mentioned in the normative part).

The security considerations section has some additional text:

"   Some TLS ciphersuites only provide integrity validation of their
   payload, and provide no encryption.  This specification forbids the
   use of such ciphersuites.  Since the RADIUS payload's shared secret
   is fixed and well-known, failure to comply with this requirement will
   expose the entire datagram payload in plain text, including User-
   Password, to intermediate IP nodes."

and the constraint mentioned in that section is reflected in the MUST in
the first bullet of the normative section already.

I am unsure what specifically should be changed here, and suggest to
leave the text as-is.

> 2. When is it acceptable not to validate the SRV entry in the
> certificate? 
>   

To formulate it positively: it *only* makes sense when DNS SRV
resolution was used to arrive at this TLS peer. In all other cases, the
a subjectAltName:SRV can be ignored. The current text doesn't contain
this latter sentence. I suggest to add that sentence.

> 3. The section should state that matching should be done against locally
> configured names (as opposed to information retrieved from DNS). 
>   

I have extended the sentence in that section:

Certificate validation MUST include the verification rules as per <xref
target="RFC5280" />, using information from trusted sources only (e.g.
locally configured names).

I hope that addresses the issue.

> 4. Is there any particular URI type that would be useful for RADIUS? 
>   

I don't think there is any RADIUS-global answer to this question. A
roaming consortium decides which X.509 certificate holders to trust. It
will determine the eligibility via *some* handle in the certificate. A
plausible candidate for subjectAltName:URI is a URL pointing to some
kind of consortium policy.

It is also thinkable that a consortium defines a specific certificate
policy statement for its CA(s), and uses the Policy OID field to point
to these policies. A peer would then check for the presence of this
policy OID.

It just seems prudent for an implementation to expose as many fields
from the incoming certificate as possible to the application layer, so
that an Administrator has a handle to check the incoming connection for
eligibility according to whatever policy is defined for the consortium.
The same text as earlier in the document should be applicable here:

 In X.509 certificate operation, at least the following parameters of
the TLS connection should be exposed:

   o  Originating IP address

   o  Certificate Fingerprint

   o  Issuer

   o  Subject

   o  all X509v3 Extended Key Usage

   o  all X509v3 Subject Alternative Name

   o  all X509v3 Certificate Policies

   In TLS-PSK operation, at least the following parameters of the TLS
   connection should be exposed:

   o  Originating IP address

   o  TLS Identifier

(this is from my proposed text for NAS Identity Issue)

Would the proposed changes address your concerns?

Greetings,

Stefan Winter

>
>
>
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>   

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