[radext] ALPN alert use with RADIUS Version 1.1

[Heikki Vatiainen <[e-mail]>]

I've looked at RADIUS Version 1.1 implementation and there are a some
implementation related topics I'd like to hear opinions on. I'll start with
ALPN alert use with this message.

The draft currently states this about TLS alert 120 use:
https://www.ietf.org/archive/id/draft-ietf-radext-radiusv11-01.html#section-3.3-9

If a client or server determines that there are no compatible application
protocol names, then as per [RFC7301] Section 3.2, it MUST send a TLS alert
of "no_application_protocol" (120), which signals to the other end that
there is no compatible application protocol.


The table in section 3.3.1 then helpfully describes all combinations of
client and server ALPN configuration policy and capability.

First, regarding client behaviour: I don't think RFC 7301 describes the
possibility for a client to send alert 120.
https://datatracker.ietf.org/doc/html/rfc7301#section-3.2

While this would be useful for debugging and troubleshooting, it seems that
for example OpenSSL, that I've used, doesn't readily support it. I've also
talked to someone who knows about Rust native TLS, and it seems impossible
there too. What client can do is to do a normal shutdown and send a
'close_notify' alert. It seems that even OpenSSL does not provide an API
function to send a specific alert. Other TLS implementations may also not
be capable sending alert 120 for TLS client connections.

Second, OpenSSL provides a callback for examining ClientHello and then
triggering an alert if the handshake shouldn't proceed. This can be used to
handle the upper right corner case in the table where the Client supports
'No ALPN' and Server policy is 'require'. This again seems to go against
ALPN RFC 7301 because the RFC only discusses alert 120 in the case where
the server supports no value that the client offers with ALPN. The upper
right corner is the case where the client sends no ALPN extension.

With Rust native TLS there's apparently no similar ClientHello callback and
the server needs to later examine if ALPN was negotiated and then close the
connection. In other words, with Rust TLS, the handshake finishes first
before ALPN status is available.

With both OpenSSL and Rust TLS, the libraries can be made to send alert 120
when there's no overlap with ALPN protocols the client and server support.
In other words, only the case where the both client and server use ALPN,
alert 120 can be sent without any extra work.

To summarise: the requirement to use TLS alert 120 by both client and
server in every case where the table in section 3.3.1 of the current draft
requires 'Close' seems to be hard to implement. It also seems to be not
what the ALPN RFC states about alert 120 usage. It would be beneficial for
troubleshooting if the alert could be used for all 'Close' cases, but
should we think about an alternative for those cases where the TLS
implementation can't be made to send alert 120 as the application needs?

-- 
Heikki Vatiainen
[e-mail]