Subject: RE: Issue 282: cert validation, proposed text

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 3 Mar 2009 08:43:17 -0800

Hi Stefan,

Some comments below. 

> -----Original Message-----
> From: Stefan Winter [mailto:[email-masked]] 
> Sent: Wednesday, February 11, 2009 1:13 AM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]
> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Stefan Winter <[email-masked]>
Date: Wed, 04 Mar 2009 08:42:06 +0100

Hi,

> [Joe] Where is the SRV entry present in the certificate?  What does it look like? What is the value in the certificate validated against?  

Right, sorry, I should have expanded on "reference x.y.z" :-) This is
about RFC4985: "Internet X.509 Public Key Infrastructure - Subject
Alternative Name for Expression of Service Name".

It defines a subjectAltName - otherName that's supposed to contain the
SRV record. I understood that so far, checking this is not in popular
TLS implementations yet, but it looks useful and deserves to be
mentioned IMHO. I'll update the reference in the draft.

> http://tools.ietf.org/html/draft-ietf-syslog-transport-tls-14 which is somewhat similar and has some text on fingerprint matching.  

Looks good, I'll add corresponding text to the next version of the draft.

> [Joe] In the syslog document referenced above we made it mandatory to support subjectAltName:DNSname matching.   Other places for the identity are allowed.  

Ok, thanks for the pointer. That text looks good, and I might be tempted
to copy&paste from it :-). Just one question on it: if both a
subjectAltName:DNS and a CN are present, what if they differ? Which of
the entries gets precedence? Or is a match of any of the entries good
enough? My text emerged due to the impression that CN is regarded as
deprecated when subjectAltName:DNS is present, and consequently gives
subjectAltName:DNS precedence.

> [Joe] What does the URI look like?  

This is not constrained and defined by the users of the spec. As an
example, for the eduroam roaming consortium, we use a URL containing a
URN (due to subjectAltName:URI constraints, we can't use a URN directly):

The identity provider for the domain restena.lu has, for example:

URI:https://registry.edugain.org/resolver?urn=urn:geant:eduroam:component:idp:Europe:RESTENA:restena.lu

This enables checking on "urn:geant:eduroam:component:" as authorisation check. Plus, putting this URL into a browser will yield the registration data from the authoritative URN registry.

Other roaming consortia can define their own acceptable URI schemes.

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