[radext] Re: Proposed Security Considerations Text

[Q Misell <[e-mail]>]

Moin,

> 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?>. How will the RADIUS layer determine
the identity of the connected peer, so that authorization can be performed?

This should reference RFC 9525 as an informative reference. Exactly how a
certificate is matched to an identity is local policy, but RFC 9525
provides some guidance on how someone might want to do that.

>  Integrity protection of messages

(D)TLS already provides strong integrity protection, there's no need to
reinvent the wheel, we'll probably get it wrong. The burden of integrity
protection can be removed entirely from the RADIUS layer.

> Hiding sensitive data in RADIUS message

Again, this a problem for (D)TLS, not RADIUS. We probably don't even need
to do the whole User-Password encryption dance, but I accept removing that
creates other problems elsewhere.

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

This one I'm less sure about. At the very least I think we need a note
about time of check vs time of use here.
With per-packet auth the access permissions of the client are checked on
every message; with per connection auth its possible that an implementer
would check access once at the start.
If the access of a client is changed or revoked during a session such an
implementer would then still allow the client to transact under its
original access permissions.
It is exceedingly unlikely (impossible?) for client identity to change
during a session, so I think checking that once at the start is fine.
We should therefore say that an implementer should check access permissions
on every message, or at least periodically during the session.

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

Suggested text:
RADIUS is an inherently hop-by-hop protocol in current deployments, and it
is expected that hops make modifications to RADIUS messages as they process
and forward them.
Channel binding (e.g. using TLS Exporter Keys) provides little to no value
in this scenario and is therefore not implemented in RADIUS over (D)TLS.
------------------------------

Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifically stated.
AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
registered in Wales under № 12417574
<https://find-and-update.company-information.service.gov.uk/company/12417574>,
LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
<https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU
VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
Digital, is a company registered in Estonia under № 16755226. Estonian VAT
№: EE102625532. Glauca Digital and the Glauca logo are registered
trademarks in the UK, under № UK00003718474 and № UK00003718468,
respectively.


On Fri, 26 Jul 2024 at 21:56, Margaret Cullen <[e-mail]> wrote:

> [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
>
>
>
>
>
>
> .
> _______________________________________________
> radext mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>