I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Security Area
Directors.  Document authors, document editors, and WG chairs should
treat these comments just like any other IETF Last Call comments.

Document: draft-ietf-radext-radiusdtls-bis-02
Reviewer: Russ Housley
Review Date: 2024-09-28
IETF LC End Date: Unknown
IESG Telechat date: Unknown

Summary: Not Ready


Major Concerns:

Section 3.3 contains a TODO.  It needs to be resolved.

Section 4.1 contains a TODO.  It needs to be resolved.  Also, the
TODO note and the next sentence are munged together.

Section 4.2 is confusing.  To align with the discussion of
connected identity, I think that four cases need to be discussed
in this introductory section: TLS-X.509-PKIX-TRUST-MODEL,
TLS-X.509-FINGERPRINTS, TLS-RAW-PUBLIC-KEY, and TLS-PSK.

In Section 4.2.1 Please reference RFC 5280 for the definition of
Certification Authorities (CAs).  It might be better to talk about
trust anchors instead of Trusted CAs.

Section 4.2.1 includes:

      -  If the expected RADIUS/(D)TLS server was configured as a
         hostname, the configured name is matched against the presented
         names from the subjectAltName:DNS extension; if no such exist,
         against the presented CN component of the certificate subject

      -  If the expected RADIUS/(D)TLS server was configured as an IP
         address, the configured IP address is matched against the
         presented addresses in the subjectAltName:iPAddr extension; if
         no such exist, against the presented CN component of the
         certificate subject.

There is no "subjectAltName:DNS extension".  It would be better to say
that the subjectAltName extension contains a domain name system label
in the dNSName as an IA5String.  This means that an Internationalized
Resource Identifier (IRI) is put in the certificate in the ASCII form
(punycode).

Likewise, there is no "subjectAltName:iPAddr extension".  It would be
better to say that the subjectAltName extension contains an IP address
in the iPAddress as an OCTET STRING.

Section 4.2.1 includes:

         o  The realm which was used as input to the discovery is
            matched against the presented realm names from the
            subjectAltName:naiRealm extension.

         o  If the discovery process yielded a hostname, this hostname
            is matched against the presented names from the
            subjectAltName:DNS extension; if no such exist, against the
            presented CN component of the certificate subject.
            Implementations MAY require the use of DNSSEC [RFC4033] to
            ensure the authenticity of the DNS result before relying on
            this for trust checks.

There is no "subjectAltName:naiRealm extension".  I assume this is based
on  RFC 7585.  If that is correct, then a reference is needed.  Assuming
that is correct, it would be better to say that the subjectAltName
extension contains an other name containing a NAIRealm as a UTF8String. 

Likewise, there is no "subjectAltName:DNS extension".  I discussed this
point above.

Section 4.2.1 includes:

   *  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 SHOULD renegotiate the TLS session to reassess the
      connecting peer's continued authorization.

I suspect that performing the certificate path validation again is good
enough.  That said, I am not sure that is practical.  The information
from the handshake might not be kept around.

Section 4.2.3 says:

   RADIUS/(D)TLS implementations SHOULD support using Raw Public Keys
   [RFC7250] for mutual authentication.

I do not understand how raw public keys are used to support mutual
authentication.  More information needs to be included in this section.
Further, Section 4.2 talks about authentication using X.509 certificates
with the PKIX trust model and authentication using TLS-PSK.  If support
for raw public keys is needed, then this introduction must include some
discussion of this alternative.

Section 4.3 is confusing.  I think that four subsections might be helpful:
TLS-X.509-PKIX-TRUST-MODEL, TLS-X.509-FINGERPRINTS, TLS-RAW-PUBLIC-KEY,
and TLS-PSK.

Section 4.4 contains a TODO.  It needs to be resolved.

Section 5.1 contains a TODO.  It needs to be resolved.

Section 6.3 contains a TODO.  It needs to be resolved.

Section 6.4 contains a TODO.  It needs to be resolved.

Section 6.4.1.1 contains two TODOs.  They need to be resolved.

Section 6.4.2 contains a TODO.  It needs to be resolved.

Section 7.1 contains a TODO.  It needs to be resolved.


Minor Concerns:

Section 1 begins with:

   The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176]
   and others is a widely deployed authentication, authorization and
   accounting solution.

I find this very difficult to understand.  Please make this two sentences.
One that says what the RADIUDS protocol is about, and a separate sentence
about where it is defined.

Section 1.2 includes:

   *  RFC6614 only requires support for the trust model "certificates
      with PKIX".  This document changes this.  For servers,
      "certificates with PKIX" and "TLS-PSK" is now mandated and clients
      must implement one of the two.

Please add pointers for these two terms.  This is the first place in the
document where these terms are used.  I'm unsure if it would be better to
point to the right part of Section 4.2 or the other documents.

Section 3.3 includes:

   For RADIUS/TLS, the peers MAY send TCP keepalives as described in
   [RFC9293], Section 3.8.4, for RADIUS/DTLS connections, the peers MAY
   send periodic keepalives as defined in [RFC6520], as a way of
   proactively and rapidly triggering a connection DOWN notification
   from the network stack.

This is hard to parse.  Please break into two sentences, one for
RADIUS/TLS, and a separate sentence for RADIUS/DTLS.  Please make them
parallel in structure.


Food for thought:

I do not expect a response to this part of the review.  I am just planting
a seed of an idea.  I ask the authors to think about it.

Section 4.2 talks about authentication using X.509 certificates with the
PKIX trust model and authentication using TLS-PSK [I-D.ietf-radext-tls-psk].
Please consider a third alternative based on RFC 8773, which mixes
certificate-based authentication with an external PSK.  This alternative
would provide protection from a record-now-decrypt-later attack from the
future invention of a cryptographically relevant quantum computer (CRQC).


Nits:

Section 1.2: s/usage of TLSv1.3/usage of TLSv1.3./

Section 1.2: s/been updated/been updated./

Section 3.1: s/See Section 7 or/See Section 7 of/

Section 3.1: s/further in Section 6/further in Section 6./

Section 3.3: s/It is REQUIRED that implementations utilize/
              /RADIUS/(D)TLS clients MUST use/

Section 3.3: s/It is REQUIRED that RADIUS/(D)TLS clients implement/
              /RADIUS/(D)TLS clients MUST implement/

Section 4: s/(D)TLS session/(D)TLS session./

Section 4.1: s/clients must establish/clients MUST establish/

Section 4.2.1: s/Certificate Authorities/Certification Authorities (CAs)/

Section 4.2.1: s/certificate subject/certificate subject./

Section 4.2.1: s/certificate MAY Be/certificate MAY be/

Section 4.2.1: s/trust chain checks/certificate path validation/ (more than once)

Section 4.2.2: s/trusted certificates/trust anchors/

Section 4.5.1: s/Acct-elay-Time/Acct-Delay-Time/

Section 7.2: s/to any middle-person/to any party/

Section 7.3: s/bogous/bogus/ (more than once)


Note:

I did not review the Appendices.