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

[Alan DeKok <[e-mail]>]

On Jul 19, 2023, at 12:36 PM, Heikki Vatiainen <[e-mail]> 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'll argue that RFC 7301 doesn't forbid the client from sending a 120 as the TLS alert.  But yes.. it's not in the expected use case.   RFC 8446 lists "no_application_protocl" with the error alerts in Section 6.2, and suggests that only the server sends it.

  So it's probably best to just remove that portion of the client behavior.

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

  I think Alex has a good point here, too.  The client has sent all of the ALPN protocols it supports.  The only possible answers from the server are (a) TLS alert 120, or (b) an all of an ALPN protocol which the client had already sent.

  So there's no need for the client to signal any "no_application_protocol" to the server.  I'll update and clarify the text.

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

  I think it's safe to send a "no_application_protocol" alert if the client doesn't send ALPN.  It's not officially suggested, but I can't see how it can hurt anything.  The server is going to close the connection anyways.  And if the client isn't expecting that TLS alert, it shouldn't do much other than complain and close the connection.

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

  Sure.  It's possible, but not always 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?

  I'm not sure what alternative would be possible.  It's difficult to do (or change) anything in the TLS layer.  It may be considered to be unfriendly to send non-RADIUS traffic inside of the TLS tunnel in a failure case.

  i.e. if the client or server determines that they are not going to do RADIUS, there isn't much harm in sending non-RADIUS traffic down the connection, such as a text string "Failed due to reason FOO".

  I suppose if we went down that path, we could suggest that the client or server sends a Protocol-Error packet which contains an appropriate Error-Cause attribute, and then closes the connection.

  The reason for doing that is to make it easy for administrators to tell exactly what's going on.  It's a serious problem when the administrator sets up complex applications with all kinds of crypto magic, and then things don't work, with an error message of "Failed".  It is much politer to give people a real, descriptive error message, so that they know exactly what went wrong, and how to fix it.

  Alan DeKok.