[radext] draft-ietf-radext-radiusdtls Certificate Identities

[Fabian Mauchle <[e-mail]>]

I almost forgot, at IETF118 I volunteered to provide a proposal for
applying RFC 9525 to section 4.2.1. Here we go:


4.2.1.  Authentication using X.509 certificates with PKIX trust model

All RADIUS/(D)TLS server implementations MUST implement this model.
RADIUS/(D)TLS client implementations SHOULD implement this model, but
MUST implement either this or TLS-PSK

If implemented it MUST use the following rules:
- Implementations MUST allow the configuration of a list of trusted
Certificate Authorities for new TLS sessions. This list SHOULD be
application specific and not use a global system trust store.
- Certificate validation MUST include the verification rules as per
[RFC5280].
- Implementations SHOULD indicate their trusted Certification
authorities (CAs).  See [RFC5246], Section 7.4.4 and [RFC6066], Section
6 for TLS 1.2 and [RFC8446], Section 4.2.4 for TLS 1.3

RADIUS/(D)TLS clients and server SHOULD generally follow [RFC9525] when
validating peer identities. Specific details are provided below:
- The Common Name RDN MUST NOT be used to identify peers.
- If configured by the administrator, the identity check MAY be omitted
after the [RFC5280] trust chain checks. The certificate MUST then be
validated using a certificate policy OID unless unless both peers are
part of a trusted network.
- Implementations MAY match wildcards in the identifiers of DNS names
and realm names, but only in the left-most label.
- RADIUS/(D)TLS clients validate the servers identity to match their
local configuration:
   * If the server was configured as a DNS name, the name is matched 
against the presented names from the subjectAltName:DNS extension.
   * If the server was configured by IP address, the address is matched 
against the presented addresses in the subjectAltName:iPAddr extension.
   * If the server was dynamically discovered as per  [RFC7585] it MUST
perform the following checks, accepting the identity on the first match.
If at any step the server presents the required extension but which does
not match, the servers identity MUST be considered invalid.
     o The realm which was used as input to the the dynamic discovery is
matched against the presented realm names in the subjectAltName:naiRealm
extension.
     o The SRV service name yielded by the discovery process is matched
against the presented service name in the subjectAltName:SRVName extension.
     o The DNS name yielded by the by the discovery process is matched
against the presented names from the subjectAltName:DNS extension
     o Since the discovery process by itself is not secured, additional
measures SHOULD be taken:
       - Implementations MAY require the use of DNSSEC [RFC4033] when
validating SRV service name and DNS name yielded by the discovery
process. In that case, any step for which the input was not DNSSEC
signed MUST be skipped.
       - Implementations MAY require additional verification of policy 
OIDs, preferably using a private CA.
- RADIUS/(D)TLS servers validate the certificate of the RADIUS/(D)TLS
client against a local database of acceptable clients.  The database may
enumerate acceptable clients either by IP address, by a DNS name.
   * For clients configured by DNS name, the configured name is matched
against the presented names from the subjectAltName:DNS extension.
   * For clients configured by their source IP address, the configured IP
address is matched against the presented addresses in the
subjectAltName:iPAddr extension
   Note: the source IP address MUST be matched exactly, a subnet match
is not possible.
-  Implementations MAY allow a configuration of a set of additional
properties of the certificate to check for a peer's authorizationvto
communicate (e.g. a set of allowed values in subjectAltName:URI or a set
of allowed X.509v3 Certificate Policies).
- When the configured trust base changes (e.g., removal of a CA from the
list of trusted CAs; issuance of a new CRL for a given CA),
implementations MUST reassess continued authorization of all active
connections.
   Note: with TLS1.3, renegotiation is no longer available to fulfill 
this requirement.



(hope the formatting doesn't get messed up too much).
It's just a proposal, please scrutinize carefully...

This section only talks about certificate/identity verification. I think 
there should also be some guidance how to issue said certificate (which 
subjectAltName to include under which circumstance).

-- 
Fabian Mauchle
Network
NOC:   [phone]
Direct:[phone]

Switch
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland