[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue 282: cert validation, proposed text
> 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
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
* The TLS session MAY use mutual PSKs for connection setup.
* The cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA MUST be
* The cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and
TLS_RSA_WITH_RC4_128_SHA SHOULD be supported. (see Section 3.2
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.
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
Tel: +352 424409 1
Fax: +352 422473
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.