Re: Issue RADSEC certificate handling

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

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

Indeed, some cipher suites were enumerated in the informative section
and only referenced-to from the normative section. This is bad; in the
upcoming -05 draft, they are mentioned in the normative part directly.
Same goes for the optional support of compression.

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

When it's there, it should be validated. The reason for my SHOULD was
that an implementation might support TLS, but not the validation of the
SRV extensions in RFC4985. The SHOULD was supposed to express that under
such circumstances, validation doesn't have to happen. But that was
rather clumsy wording; I changed it to

"If service names as per <xref target="RFC4985" /> are present in the
certificate and dynamic discovery utilizing SRVs in DNS is used (see
<xref target="I-D.winter-dynamic-discovery" />) and the TLS
implementation supports evaluation of the extensions in <xref
target="RFC4985" />, the SRV entry MUST be validated."

(and if the implementation does not support RFC4985 then it quite
obviously can't validate the entry, and it is just some opaque
SubjectAltName:otherName for this implementation which will be ignored)
I wonder if the text in parentheses should be in the draft or if that's
superfluous?

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

I changed the sentence to

"Peer validation always includes a check on whether the locally
configured expected DNS name or IP address of the server that is
contacted matches its presented certificate."

to make clear that the authoritative trusted information is the local
configuration.

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

This was discussed in the room last time, IIRC; the conclusion being
that this is a decision of the operators of an infrastructure what
scheme to deploy for validation. So, any type of URI could occur. An
implementation that could check the presented URI against a locally
configured regular expression of expected URIs would be flexible.

As an example, in the eduroam case, we would have a URL designating the
purpose of the server bearing the certificate in the URI field, with a
fixed prefix:

X509v3 Subject Alternative Name:
                URI:https://registry.edugain.org/resolver?urn=urn:geant:eduroam:component:...


(the three dots indicating that everything below that is variable (hence
the suggested regexp matching). In my own concrete example, the national
RADIUS proxy for Luxembourg (operated by RESTENA) contains:

X509v3 Subject Alternative Name:
                URI:https://registry.edugain.org/resolver?urn=urn:geant:eduroam:component:proxy:Europe:RESTENA:FTLR


I'm not sure if there should be more text about this in the draft than
currently is.

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