On Feb 25, 2024, at 9:15 PM, Paul Wouters <paul.wout...@aiven.io> wrote:
> I think in general this document is ready to go. I have some hopefully minor
> issues that would be good to resolve or clarify before starting IETF LC.
>
> As such, the PAC has been removed from this document.
>
> This reads a bit weird. Can it say PAC has been deprecated instead? This
> occurs twice in the document.
I'll fix that.
> draft-ietf-uta-rfc6125bis-15 -> RFC 9525
Fixed.
> I am a bit confused by:
>
> Server Certificates MAY be constructed with a SubjectDN containing a
> single element, "CN=" containing the FQDN of the server. It is also
> permissible for the server to have an empty subjectDN as recommended
> by {!{I-D.ietf-uta-rfc6125bis}}.
>
> That document (RFC 9525 now) actually says:
>
> The Common Name RDN MUST NOT be used to identify a service
> because it is not strongly typed (it is essentially free-form
> text) and therefore suffers from ambiguities in interpretation.
>
> For similar reasons, other RDNs within the subjectName MUST NOT
> be used to identify a service.
>
> It seems to me that RFC9525 says to only use subjectAltName (SANs) ?
I think that's reasonable. I'll rearrange the text to say:
Server Certificates MUST include a subjectAltName extension, with the dnsName
attribute containing an FQDN string. Server certificates MAY also include with
a SubjectDN containing a single element, "CN=" containing the FQDN of the
server. However, this use of SubjectDN is deprecated for TEAP, and is
forbidden in {{RFC9525}} Section 2.
> Now this document also follows with:
>
> Server Certificates MUST include a subjectAltName extension
>
> Perhaps some text can be added to the "Server Certificates MAY be constructed"
> text by saying that authentication decisions MUST NOT be made based on the
> SubjectDN ?
Sure. The next section of 7170bis is server certificate validation, and
suggests that RFC 9525 should be followed. I'll clarify.
> Note that since TLS client certificates are sent in the clear with
> TLS 1.2 and earlier
>
> Can "and earlier" be removed? Eg can this document say the TLS version MUST
> be 1.2 or later?
I think it's fine. In theory, people might have implemented TLS 1.0 and 1.1
for TEAP. But all known implementations are much more recent, and start with
TLS 1.2.
I'll update the introduction to match. And add a referenced to RFC8996
explaining why we don't do TLS 1.0 or TLS 1.1.
> The first Basic-Password-Auth-Req TLV received in a session MUST
> include a prompt, which the peer displays to the user.
>
> Should this receive some Security Considerations to avoid log4j/JNDI type
> issues?
I can add a few sentences. I think most EAP implementations are tied to
RADIUS implementations, and those have clear-text passwords flying around
everywhere.
> While [RFC8446] allows for the TLS conversation to be restarted,
>
> Maybe write "TLS 1.3" instead of "[RFC8446]" here? Or use both?
Both is fine
> The IANA considerations lists:
>
> 11,PAC TLV,(DEPRECATED) [RFC7170]
>
> As it is [THIS-DOCUMENT] that deprecates it, it should be added to the
> reference RFC as well, eg:
>
> 11,PAC TLV,(DEPRECATED) [RFC7170] [THIS-DOCUMENT]
Fixed.
>
> Protection against Man-in-the-Middle Attacks
>
> Maybe rename to "on-path attacks" ?
Fixed.
> Appendix C.4 should clarify the TLS version used (1.2). Should it be
> changed to use a TLS 1.3 example?
I think so, yes. I'll have to dig into that. I don't think I can get that
updated today before the deadline.
Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
