Issue 282: cert validation, proposed text

[Stefan Winter <stefan.winter@restena.lu>]

Hi,

> 2.  I think the certificate handling and authorization section needs to
> be more specific for supporting mandatory to implement options.
> Currently, the document implicitly requires trust root based
> authorization where all certs issued by a given trust root are
> authorized.  Some more specific rules are discussed in an informative
> section.  I believe some of this needs to be normative and more specific
> in order to have interoperable implementations.  This should also be
> discussed in the security considerations. 
>   

Section 2.2 now reads:

2.2.  Connection Setup

   RadSec nodes

   1.  establish TCP connections as per [I-D.dekok-radext-tcp-transport]

   2.  negotiate TLS sessions according to [RFC5246] or its predecessor
       TLS 1.1.  The following restrictions apply:

       *  The authentication MUST be mutual, i.e. both the RadSec server
          and the RadSec client authenticate each other.

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

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

       *  The cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA MUST be
          supported.

       *  The cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and
          TLS_RSA_WITH_RC4_128_SHA SHOULD be supported. (see Section 3.2
          (1) )

   3.  If TLS is used in an X.509 certificate based operation mode, the
       following list of certificate validation options applies:

       *  Implementations MUST allow to configure a list of acceptable
          Certification Authorities for incoming connections.

       *  Certificate validation MUST include the verification rules as
          per [RFC5280].  If an SRV entry is present in the certificate
          and dynamic discovery based on DNS is used, the SRV entry
          SHOULD be validated. refence x.y.z here.

       *  Implementations SHOULD indicate their acceptable Certification
          Authorities as per section 7.4.4 (server side) and x.y.z
          ["Trusted CA Indication"] (client side) of [RFC5246] (see
          Section 3.1 (1) )

       *  Implementations SHOULD allow to configure a list of acceptable
          certificates, identified via certificate fingerprint.

       *  Peer validation always includes a check on whether the DNS
          name or the IP address of the server that is contacted matches
          its certificate.  DNS names and IP addresses can be contained
          in the Common Name (CN) or subjectAltName entries.  For
          verification, only one these entries is to be considered.  The
          following precedence applies: for DNS name validation,
          subjectAltName:DNS has precedence over CN; for IP address
          validation, subjectAltName:iPAddr has precedence over CN.

       *  Implementations SHOULD allow to configure a set of acceptable
          values for subjectAltName:URI.

There's no additional text in Security Considerations since was not sure
if additional text was needed with this new text.

Please comment if this text can satisfactorily close this sub-issue.

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: +352 424409 1
Fax: +352 422473


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>