[radext] Proposed Security Considerations Text

[Margaret Cullen <[e-mail]>]

[I am sending this message incomplete because the WG meeting is now…. I will pick it up again and add more on the way home or over the weekend.  Contributions very welcome!]


Hi All,

I am working on additional Security Considerations text for RADIUS/(D)TLS to capture the discussion we have been having for  the past couple of days.  Please note that I have written this text as though the text of the TLS-PSK document were included in RADIUS/(D)TLS, as we previously established WG consensus to incorporate it.

There are some places below where I need help knowing what to say…. Either because I lack specific knowledge or because I am unsure of how certain things will work.  

Please help!

—

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

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.

In RADIUS/(D)TLS, a peer is authenticated as part of TLS session establishment, because a TLS connection will not be established unless the peer has acceptable credentials.  When certificates are used, TLS authentication is established by the fact that a peer has a current, valid, unrevoked certificate where the value in <what field?> matches <what value?>.  When (D)TLS-PSK is used, TLS authentication is established when the peer has a PSK value that matches the PSK configured in the TLS configuration in use by RADIUS.  When a TLS connection has been established, the RADIUS layer will infer that authentication has been successful, .  How will be RADIUS layer determine the identity of the connected peer, so that authorization can be performed?

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

X.1.2 	Integrity protection of messages

X.1.3	Hiding sensitive data in RADIUS message

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


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

—
Anything to contribute to the above text? Any thoughts or questions?

Thank you in advance for your help,
Margaret






.