[radext] Re: Proposed Security Considerations Text

[Alan DeKok <[e-mail]>]

On Jul 26, 2024, at 3:56 PM, Margaret Cullen <[e-mail]> wrote:
> X.1		Security implications of well-known “secret” value 
> 
> In addition to defining how a single RADIUS message transmitted over (D)TLS, this document specifies that the RADIUS “secret” value will be hard-coded to one of two well-known values (“radsec” of “radsec/dtls”).  The “secret” value is used for several things in RADIUS/UDP:
> 
> - authentication of a RADIUS peer,
> - authorization of a RADIUS peer to assume a particular role (client, server, CoA sender, etc.)
> - integrity protection of the message contents, and 
> - hiding sensitive data in a RADIUS messages

  I don't agree with item 2.  The authorization of a system has little to do with the secret.

  i.e. systems usually have a set of data associated with a client to server relationship:

	IP address (client or server)
	shared secret
	purpose of this connection (Access-Request, Accounting-Request, etc).

  When a packet is received by a server, the source IP is used to look up the associated tuple.  Then packets which are not authorized are dropped, even if they can be authenticated.  So the secret isn't necessarily involved here.

  The secret is used to:

* authenticate packets received from a peer
* verify per-packet integrity checks
* obfuscate sensitive data


> X.1.1 	Authentication and Authorization of a RADIUS Peer
> 
> When a RADIUS/UDP message is received, the “secret” value and the remote IP address are used to authenticate the RADIUS peer.  Once the peer has been authenticated, the RADIUS server will look up the configured policy for that peer, and determine whether the peer is authorized to send the type of message that was just received.  Assuming authentication and authorization are successful, the RADIUS server will process the message.  Otherwise, it will be discarded.  Each RADIUS message is separately authenticated and authorized as it is received.

  But the "peer" is never authenticated.  Instead, each individual packet is authenticated.  Perhaps:


  When a RADIUS/UDP message is received, the remote IP address is used to verify that the packet is coming from a known peer.  The IP address is also used to look up the shared secret associated with this peer.  Other information may be associated with the peer, such as a set of packet codes which the receiving system is prepared to accept.  For example, a server may accept only Access-Request packets on port 1812, but not accept Accounting-Request packets on that port.  Similarly, a client will access Access-Accept from the server in response to an Access-Request, but will not accept an Accounting-Request response for that Access-Request.

  If the packet is from a known peer and passes any authorization checks, the shared secret is used to authenticate the packet.  Packets which fail authentication are silently discarded.  Packets which pass authentication are processed according to local site policies.

  The process for RADIUS/TCP is similar, except that the peer IP address is only checked on the initial TCP connection.  After that, the shared secret and any authorization rules are associated with that connection, and are checked as described above.

  For RADIUS/(D)TLS, the connection is authenticated as part of TLS session establishment.  Connections which fail authentication are closed, and no RADIUS traffic passes.  Peers can be authenticated via certificates, via a PSK, or by any other method supported by TLS.  RADIUS/(D)TLS imposes no restrictions on TLS authentication methods.

  Once a (D)TLS session is established, the peer identity (not peer IP) is used to find any associated authorization policies.  RADIUS traffic received over a (D)TLS connection then follows the above process for which kinds of packets will be accepted, and how those packets will be processed.

  The result of this design is that the processing of individual packets (e.g. Access-Accept) is essentially independent of the transport protocol.  The transport protocol may permit only certain peers to connect, or it may permit only certain kinds of packets to pass any authorization rules.  However, once a peer has determined that it will accept a packet, further packet processing is independent of any transport protocol.  For example, User-Name and User-Password validations can be performed without using knowledge of the underlying transport in which those attributes were received.

> [Note:  We should probably also have something in the normative part of the RADIUS/(D)TLS document that explains what a RADIUS implementation should do, when RADIUS is run over (D)TLS, anywhere that RADIUS/UDP and/or other RADIUS-adjacent specifications (such as the CoA documents) indicate that implementations should “check the secret” for any reason, as that is not a useful thing to do in RADIUS/(D)TLS.]

  While 6614 and 7360 use a fixed shared secret, the pre-existing rules still apply.  i.e. discarding packets which fail validation.  The only difference is that it's likely best to close the TLS session, too, if the shared secret is wrong.

> X.1.2 	Integrity protection of messages
> 
> X.1.3	Hiding sensitive data in RADIUS message

  TLS does those, we don't need to do much more than mention it.

> X.2	Security implications of connection-based vs. per-packet authentication and authorization

  I don't think there's much to say here?  Q's message also covers this.

  There's only one difference I can see between "authorized client" checking either per-message, or once at the start of a connection.  That difference is what to do when the "authorized client" configuration changes.

  For per-message checks, the new configuration is applied to the next received message.  For per-connection checks, there is now a choice for existing connections:

a) keep the existing connection up, and ignore the configuration change

b) double-check the existing connection against the new "authorized client" rules.  If pass, do nothing, otherwise close the connection

c) always close the connection, and make clients reconnect using the new authorization rules.

  There are good arguments for all 3 of these behaviours.

> 
> X.3	Explanation of why TLS channel binding is not needed in RADIUS/(D)TLS

  I agree with Q here: channel bindings offer no additional security.

  If we did add TLS channel bindings, we would have to somehow glue that into the RADIUS packets inside of the tunnel.  i.e. mandating connections start with Status-Server with channel binding.

  This would create additional complexity for no additional benefit.

  Alan DeKok.