Re: [radext] ALPN alert use with RADIUS Version 1.1

[Alexander Clouter <[e-mail]>]

On Wed, 19 Jul 2023, at 17:36, Heikki Vatiainen wrote:
> 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 

I do not think this is necessary as 'client' is not RADIUS client, it is TLS client.

The TLS client already has sent all the ALPN protocols it is willing to do, the server is doing the checking.

If the client sends 'radius11' and the server is okay with it and responds with "showtime, lets do radius11", the client really should not be rejecting it at this point.

So maybe the 'client or' in section 3.3.9 should be removed?

> 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.

Erlang supports the hook via ssl:handshake_continue/2 and ssl:handshake_continue/3; I used it to implement RFC8737.

Erlang only uses OpenSSL for crypto operations but otherwise is its own independent TLS library.

> 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.

I do not think it is meaning for a client to send this as it has already declared what it wants to do in the ClientHello.

> 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?

I think we should ignore incomplete implementations. They will fix these and other limitations as demand for that functionality pops up.

I agree though it should be highlighted in this document that the server needs the ability to inspect the ClientHello mid-handshake and if you cannot, do a hard and fast shutdown of the socket post handshake.

Not convinced close_notify is the right approach, as there is a lack of client support (even in OpenSSL) there we all discovered whilst contributing to RFC9427....I really think "server shuts down immediately the connection and logs a very grumpy message to the logging subsystem" will suffice here.

I think it would be worse to force all RADIUS implementors to write code to handle two different types of connection shutdowns. This spec is meant to make things easier :)

Afterall, the RADIUS client operators will have the ability to talk to the RADIUS server operator and ask "your server dislikes me, can you tell me why?"

Cheers