RE: Issue 282: cert validation, proposed text

["Joseph Salowey (jsalowey)" <jsalowey@cisco.com>]

Hi Stefan,

Some comments below. 

> -----Original Message-----
> From: Stefan Winter [mailto:stefan.winter@restena.lu] 
> Sent: Wednesday, February 11, 2009 1:13 AM
> To: Joseph Salowey (jsalowey)
> Cc: radiusext@ops.ietf.org
> Subject: Issue 282: cert validation, proposed text
> 
> 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.
> 
[Joe] Where is the SRV entry present in the certificate?  What does it look like? What is the value in the certificate validated against?  

>        *  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.
> 
[Joe] I would suggest specifying a format for interop here.  You might want to take a look at 
http://tools.ietf.org/html/draft-ietf-syslog-transport-tls-14 which is somewhat similar and has some text on fingerprint matching.  

>        *  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.
> 
[Joe] In the syslog document referenced above we made it mandatory to support subjectAltName:DNSname matching.   Other places for the identity are allowed.  

>        *  Implementations SHOULD allow to configure a set of 
> acceptable
>           values for subjectAltName:URI.
> 
[Joe] What does the URI look like?  

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