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.
>
Looking at the current text, the following is said in normative (2.2):
" * The client MUST NOT negotiate cipher suites which only provide
integrity protection.
* The TLS session MAY use mutual PSKs for connection setup.
* Negotiation of compression for the TLS session is OPTIONAL.
* RADIUS over TLS implementations MUST support the mandatory to
implement cipher suites specified in TLS (i.e.
TLS_RSA_WITH_3DES_EDE_CBC_SHA). For purposes of compatibility
with some current deployments implementations SHOULD support
TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as
well (see Section 3.2 (1) )."
The following is said in informative (3.2):
"3.2. Ciphersuites and Compression Negotiation Considerations
Not all TLS ciphersuites in [RFC5246] are supported by available TLS
tool kits, and licenses may be required in some cases. The existing
implementations of RADIUS over TLS use OpenSSL as cryptographic
backend, which supports all of the ciphersuites listed in the rules
in the normative section.
The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to-
implement according to [RFC5246] and thus has to be supported by
RADIUS over TLS nodes.
The two other ciphersuites in the normative section are widely
implemented in TLS toolkits and are considered good practice to
implement."
This text doesn't contain any additional requirements to be mentioned in
normative text IMO (note that the one named ciphersuite here is also
already mentioned in the normative part).
The security considerations section has some additional text:
" Some TLS ciphersuites only provide integrity validation of their
payload, and provide no encryption. This specification forbids the
use of such ciphersuites. Since the RADIUS payload's shared secret
is fixed and well-known, failure to comply with this requirement will
expose the entire datagram payload in plain text, including User-
Password, to intermediate IP nodes."
and the constraint mentioned in that section is reflected in the MUST in
the first bullet of the normative section already.
I am unsure what specifically should be changed here, and suggest to
leave the text as-is.
> 2. When is it acceptable not to validate the SRV entry in the
> certificate?
>
To formulate it positively: it *only* makes sense when DNS SRV
resolution was used to arrive at this TLS peer. In all other cases, the
a subjectAltName:SRV can be ignored. The current text doesn't contain
this latter sentence. I suggest to add that sentence.
> 3. The section should state that matching should be done against locally
> configured names (as opposed to information retrieved from DNS).
>
I have extended the sentence in that section:
Certificate validation MUST include the verification rules as per <xref
target="RFC5280" />, using information from trusted sources only (e.g.
locally configured names).
I hope that addresses the issue.
> 4. Is there any particular URI type that would be useful for RADIUS?
>
I don't think there is any RADIUS-global answer to this question. A
roaming consortium decides which X.509 certificate holders to trust. It
will determine the eligibility via *some* handle in the certificate. A
plausible candidate for subjectAltName:URI is a URL pointing to some
kind of consortium policy.
It is also thinkable that a consortium defines a specific certificate
policy statement for its CA(s), and uses the Policy OID field to point
to these policies. A peer would then check for the presence of this
policy OID.
It just seems prudent for an implementation to expose as many fields
from the incoming certificate as possible to the application layer, so
that an Administrator has a handle to check the incoming connection for
eligibility according to whatever policy is defined for the consortium.
The same text as earlier in the document should be applicable here:
In X.509 certificate operation, at least the following parameters of
the TLS connection should be exposed:
o Originating IP address
o Certificate Fingerprint
o Issuer
o Subject
o all X509v3 Extended Key Usage
o all X509v3 Subject Alternative Name
o all X509v3 Certificate Policies
In TLS-PSK operation, at least the following parameters of the TLS
connection should be exposed:
o Originating IP address
o TLS Identifier
(this is from my proposed text for NAS Identity Issue)
Would the proposed changes address your concerns?
Greetings,
Stefan Winter
>
>
>
>
> --
> 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/>
>
--
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
Attachment:
signature.asc
Description: OpenPGP digital signature