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

[Alan DeKok <[e-mail]>]

On Jul 20, 2023, at 10:16 AM, Heikki Vatiainen <[e-mail]> wrote:
> 
> >  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.
> 
> One option is that the server completes the handshake and returns no ALPN extension in its ServerHello. OpenSSL server appears to ignore client's ALPN extension by default and returns no ALPN extension in ServerHello. In other words, the TLS connection is opened but no ALPN was negotiated.

  Yes, that's true.

> Testing with OpenSSL's 'openssl s_client ...' works well. The client program shows that alert 120 was received. In other words, the alert returned from TLS server ClientHello callback is visible to the TLS client.

  That's good.  Taking a quick (!) look at the OpenSSL source, the client hello callback happens after the ALPN callback.  So it should be possible to set the client hello callback, and check the ALPN status, and then do... something.

  However, the OpenSSL documentation says that the client hello callback can only return success / error / retry.  So it's not possible to send a TLS alert even then.  :(

> One option could be to add some text why it's important to use 'allow' as the default policy.
> https://www.ietf.org/archive/id/draft-ietf-radext-radiusv11-01.html#section-3.3-6.1.1
> 
> As the table in section 3.3.1 shows, it's the only value that never triggers a failure. Once the person maintaining the configuration has some experience with the new behaviour, they can go and update it to a different value

  I agree.  I'll add some text.

> >   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.
>  
> And if possible, make it visible on both sides of the connection too.

   So if no one else objects to the idea, I'll add some text.  Perhaps something like:

---
When ALPN negotiation fails, it is not always possible to send TLS alert of "no_application_protocol" (120).  [RFC7301] suggests that this alert can only be sent by the server which supports ALPN, in response to a client which requests ALPN.  However, if either party does not support ALPN, then there are no provisions for sending this alert.  In addition, the TLS implementations may not permit an application to send a TLS alert of its choice, at a time of its choice.  So if one party supports ALPN while the other does not, it is not possible for the system supporting ALPN to send any kind of TLS alert which informs the other party that ALPN is required.

The only possible method for one party to signal the other then, is application data inside of the TLS tunnel.  Therefore, for the situation when a one end of a connection determines that it requires ALPN while the other end does not support ALPN, the end supporting ALPN MAY send a Protocol-Error packet inside of the tunnel, and then close the connection.  If this is done, the Response Authenticator field of the Protocol-Error packet MUST be all zeros, as this packet is not in response to any request.  The Protocol-Error packet SHOULD contain a Reply-Message attribute with a textual string describing the cause of the error.  The packet SHOULD also contain an Error-Cause attribute, with value Unsupported Extension (406).

As this packet is an unexpected response packet, existing implementations will ignore it.  They may either log an error and may close the connection, or they may discard the packet and leave the connection open.  In which case the end support ALPN will close the connection.  While using a Protocol-Error packet in this way is unusual, it is both informative and safe.

The purpose of this packet is not to have the other end of the connection automatically determine what went wrong, and fix it.  Instead, the packet is intended to be (eventually) seen by an administrator, who can then take remedial action.
----

  That seems ugly as heck, but informative.  If this suggestion isn't too terrible, we may also want to allocate a new value for Error-Cause: ALPN Unsupported.

  Alan DeKok.