[radext] Implementation independent ALPN selection for RADIUS versions

[Heikki Vatiainen <[e-mail]>]

Here's a suggestion of how to use ALPN in a way that lets the TLS stack's
ALPN implementation to do the most of the protocol selection work. I
think draft-ietf-radext-radiusv11-01
can be shortened by describing in detail only what's needed when the both
endpoints do not use ALPN. When they do, the TLS stacks' ALPN
implementations should already automatically do the right thing.

What's described in this message should also be compatible with different
TLS implementations. It only requires two things from the both TLS
endpoints. I think this is the minimum that is needed in order to use ALPN
at all:
1. A method to set supported ALPN protocols before a TLS handshake
2. When a TLS handshake completes successfully, a method to query if ALPN
chose a protocol and if yes, which protocol it chose

Specifically, no custom callbacks for ClientHello inspection or ALPN
selection are required. The TLS stacks ALPN implementation needs to simply
do what the ALPN RFC says
https://www.rfc-editor.org/rfc/rfc7301.html#section-3.2

   ... the server SHOULD select the most
   highly preferred protocol that it supports and that is also
   advertised by the client.  In the event that the server supports no
   protocols that the client advertises, then the server SHALL respond
   with a fatal "no_application_protocol" alert.

The table below, also attached as a screenshot, uses '1.0' and '1.1' for a
shorthand for 'radius/1.0' and 'radius/1.1', respectively. This brings back
the 'radius/1.0' protocol string that was is not seen as required by
selection logic, which is true, but it's helpful when used as ALPN input.
With 'radius/1.0' extra work by RADIUS/1.1 implementation is only needed
when RADIUS/1.1 is required and the other end does not support ALPN. In
this case the TLS handshake completes successfully, but an API call to find
out the selected ALPN protocol returns NULL, or whatever is used to
indicate that ALPN negotiation did not happen. When this happens,
Protocol-Error or some other action is needed to shutdown the TLS
connection.

The table summarises what TLS stack's ALPN implementation can automatically
do when the both TLS endpoints support ALPN and what remains for the
RADIUS/1.1 implementation to handle. The bottom row and the rightmost
column are what's not done automatically by ALPN. These are the cases that
RADIUS/1.1 implementation needs to handle.

One additional benefit of 'radius/1.0' ALPN protocol is that it allows the
client to make it unambiguous whether it supports ALPN at all. Currently
the client must advertise 'radius/1.1' or leave out the ALPN extension
completely. This does not:
a) Allow the client administrator to signal that the client is ALPN capable
but has RADIUS/1.1 currently turned off
b) Allow the server to easily use TLS alert 120 to refuse an incoming TLS
connection

Case a) might be useful when initially setting up ALPN capable TLS client.
It may also be useful in a case where there's an implementation bug or some
other reason to turn off RADIUS/1.1 for the moment.
Case b) is the one where the server TLS implementation does not support
inspecting ClientHello and triggering TLS alert when ALPN is required (but
not present in the ClientHello).

I also have the feeling that using ALPN protocol strings for all known
versions makes it easier to support RADIUS/1.2, should that be needed.

Here's the table I've mentioned above. I've also attached it as a
screenshot because it likely gets broken inline.

Server ALPN settings
1.1 1.1, 1.0 1.0 No ALPN
1.1 ALPN 1.1 ALPN 1.1 TLS alert 120 Client closes
Client ALPN settings 1.1, 1.0 ALPN 1.1 ALPN 1.1 ALPN 1.0 Implicit 1.0
1.0 TLS alert 120 ALPN 1.0 ALPN 1.0 Implicit 1.0
No ALPN Server closes Implicit 1.0 Implicit 1.0 Implicit 1.0
Implicit 1.0

RADIUS/1.0 is chosen because one TLS endpoint did not use the ALPN
extension and the other allows RADIUS/1.0
Client closes

The client requires RADIUS version 1.1 or later and the server did not use
the ALPN extension.
The client closes the TLS connection and sends a Protocol-Error. The client
logs the problem.
Server closes

The server requires RADIUS version 1.1 or later and the client did not use
the ALPN extension.
The server responds with TLS alert 120, if possible, or sends a
Protocol-Error, and closes the connection. The server logs the problem.

-- 
Heikki Vatiainen
[e-mail]