|
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 RADIUS/TLS server and the RADIUS/TLS 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. * Negotiation of compression for the TLS session is OPTIONAL. * RADIUS/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) ). [BA] Several issues with this: a. There is no statement about mandatory to implement TLS version (e.g. MUST support TLS 1.0 and later). b. There is no statement about mandatory to implement authentication mechanism (e.g. mutual TLS with certificates). Recommend re-writing as follows: " 2. negotiate TLS sessions. The following restrictions apply: * Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2 [RFC5246]) is REQUIRED. * Support for compression is OPTIONAL. * Support for certificate-based mutual authentication is REQUIRED. * Support for TLS-PSK mutual authentication [RFC4279] is OPTIONAL. * Negotiation of mutual authentication is REQUIRED. * Negotiation of a ciphersuite providing for confidentiality as well as integrity protection is REQUIRED. * RADIUS/TLS nodes MUST NOT negotiate ciphersuites with NULL encryption (e.g. [RFC4785]). * Negotiation of compression is OPTIONAL. * RADIUS/TLS implementations MUST at a minimum support negotiation of the TLS_RSA_WITH_3DES_EDED_CBC_SHA ciphersuite, and SHOULD support TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.2 (1) ). * In addition, RADIUS/TLS implementations MUST support negotiation of the mandatory-to-implement ciphersuites required by the versions of TLS that they support." * Certificate validation MUST include the verification rules as per [RFC5280], using information from trusted sources only (e.g. locally configured names). If service names as per [RFC4985] are present in the certificate and dynamic discovery utilizing SRVs in DNS is used (see [I-D.winter-dynamic-discovery]) and the TLS implementation supports evaluation of the extensions in [RFC4985], the SRV entry MUST be validated. In cases where no DNS SRV resolution took place to arrive at the TLS peer, subjectAltName:SRV entries can be ignored. [BA] I'm not clear what "using information from trusted sources only" means, exactly. Given the MUST here, the reference to dynamic discovery is probably normative. My suggestion is to move this material to the dynamic discovery draft so as to remove the normative dependency. Among other things, moving this to the dynamic discovery document will provide some additional time to think through the security issues. Use of the extensions in [RFC4985] does not necessarily address the problem of forgery of DNS SRV RRs unless some kind of name constraint is also applied. For example, an attacker could forge an SRV RR that indicates that the RADIUS/TLS server for example.com is hosted with the evilhacker.com domain, and the fradulent RADIUS/TLS server could provide a valid certificate with a service extenion indicating its acting as the RADIUS/TLS server for example.com. The problem is that the certificate chain will not include a trust anchor within the example.com domain. 2.3. Connecting Client Identity In RADIUS/UDP, clients are uniquely identified by their IP address. This does not permit to determine whether the connecting entity is a NAS or a different server which proxies a request. When NAT is used on the path to the server, it also does not permit to determine whether there is more than one entity connecting from the same IP address. [BA] The NAS is identified by the NAS-Identifier/NAS-IP-Address/NAS-IPv6-Address attributes, no? Since RADIUS identifies entities by IP address, by definition all packets originating from a given IP address are assumed to come from the same entity. Suggest rewriting as follows: " In RADIUS/UDP, clients are uniquely identified by their IP address. Since the shared secret is associated with the origin IP address, if more than one RADIUS client is associated with the same IP address, then those clients also must utilize the same shared secret, a practice which is inherently insecure as noted in [RFC5247]." RADIUS/TLS makes it possible to preserve this traditional RADIUS semantics by identifying a connecting client by the IP address which initiated the TLS connection. In addition, it permits a much more fine-grained identification. The parameters of the TLS connection can be attributed to the RADIUS packets inside the TLS connection. An implementation of RADIUS/TLS should expose as many details of the TLS connection which belongs to an incoming RADIUS packet as possible to the application layer to allow the administrator to define the identification criteria which are applicable to his desired operational model. 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 [BA] It seems to me that the above text is somewhat too vague in that it doesn't precisely define what parameters should be used to differentiate RADIUS clients and servers from each other. 2.4. RADIUS Datagrams Authentication, Accounting and Authorization packets are sent according to the following rules: RADIUS/TLS clients handle the following packet types from [RFC2865], [RFC2866], [RFC5176] on the connection they initiated (see Section 3.3 (3) and (4) ): o send Access-Request o send Accounting-Request o send Status-Server o send Disconnect-ACK o send Disconnect-NAK o send CoA-ACK o send CoA-NAK o receive Access-Challenge o receive Access-Accept o receive Access-Reject o receive Accounting-Response o receive Disconnect-Request o receive CoA-Request RADIUS/TLS servers handle the following packet types from [RFC2865], [RFC2866], [RFC5176] on the connections they serve to clients: o receive Access-Request o receive Accounting-Request o receive Status-Server o receive Disconnect-ACK o receive Disconnect-NAK o receive CoA-ACK o receive CoA-NAK o send Access-Challenge o send Access-Accept o send Access-Reject o send Accounting-Response o send Disconnect-Request o send CoA-Request [BA] This assumes that the RADIUS server is also a Dynamic Authorization Client. This is not necessarily the case. CoA-Request and Disconnect-Request packets can also be sent by a DAC that originates its own TLS connection, no? My suggestion is that you separate the DAC/DAS roles from the RADIUS client/server roles in this section. I'd also note that the RADIUS over TCP document does not recommend that Dynamic Authorization traffic be sent over TLS. |