RADEXT WG Interim Meeting

October 8th, 2024, from 18:00 to 20:00 UTC

Administrivia and WG Status: (Chairs, 5 min)

• Note Well and IPR statements
• Agenda bashing
• Document status update

WG Documents:

(Datagram) Transport Layer Security (D)TLS Encryption for RADIUS (Janfred, 100 min)

draft-ietf-radext-radiusdtls-bis
Status and open issues

Notes

Janfred reviewed open PRs.
There has been a substantial amount of discussion around the PRs
Substantial secdirreview from Russ Housley

TODOs in the document not covered by PRs. Needs further discussion from
the WG.

load balancing

Margaret: does load balancing, etc. belong here?

Alan: maybe it's worth just dropping all discussion of load balancing
etc. and saying "it's hard"

Fabian: seconded. Maybe mention it in the deprecating-insecure-practices
doc?

Alan: maybe in another doc? Janfred agrees. the security document
shouldn't include discussions of load balancing

Janfred: perhaps also we need a new doc for best practices

Margaret: agree with these points: later consider third document, but
not in tlsbis or deprecating doc

Valery: load-balancing are not specific to RADIUS, but shouldn't put too
much here?

Alan: except for EAP, which is specific to RADIUS.

Margaret: out of scope of this document

Alex: EAP can go over other protocols not just RADIUS, so maybe we need
EAP guidelines. So load-balancing etc. is out of scope

Klaas: there should be some guidance in this doc. Will suggest text.

Janfred: parallel connections, etc. fall into issues of load balancing

SNI and Server identity

Q: What to do when all servers are marked down? How is that decided by
the client?

it's not clear what to do here. We could rely on configuration
controlled by the admin, or on crypto to prove identities

Michael: TLS 1.3 mandates that SNI be sent. So it's good to say what
should be in it

Margaret: whole parts of the code don't know if the transport is UDP,
TCP, TLS, etc.

Alan: perhaps again this is an operational considerations document, and
may not belong here.

Margaret: there are ways to know

Janfred: perhaps just remove the current text, and maybe the
load-balancing text is related, and can also help here?

Fabian: agree we're again in the load balancing regime. perhaps just
define one connection being up and down, and if you have multiple
connections, they might not be the same server. be careful. don't define
"server down" in this document

Margaret: perhaps implementation considerations section which discusses
these issues

Alan: agrees

Alex: agrees, this all goes back to load balancing

Margaret: leave it out of scope. does anyone on the call disagree? ...
silence, will be confirmed on the list

9525 for validation

Janfred: merge PR 4 unless there are objections, and take a closer look
at loopback / selfie attack

Margaret: is this specific to RADIUS?

Janfred: Selfie is specifically problematic for RADIUS proxies, because
they act as client and server for the same protocol. It's harder to do
with HTTP, and is a bigger issue for RADIUS.

Fabian: +1

Alex: OpenSSL supports reading back what the client random number is.
you might be able to read it and double-check the bytes you sent against
the bytes you receive? Just an idea

Fabian: suggested text "don't accept your own cert", and check
certificate digest. Implementation is done. One remark for wildcard
certs, based on requests from e.g. OpenRoaming.

Margaret: any objections to adopting text in PR4

Janfred: accept PR4 as-is, with changes as made by Fabian. Then need to
look into security considerations. Unsure about "don't accept your own
cert". not sure if we should rule out all use-cases that support this

Mark Donnely: maybe cloud clients want to talk to each other?

Alan: those are different roles, and should have different identities

Margaret: does anyone object to PR4? no comment. Comments on loopback
attack? silence. Margaret suggests adding discussion in the security
considerations section. And then suggest that clients && servers should
have different identities.

Heikki: isn't Selfie only for TLS-PSK?

Fabian: let's drop suggestion for "do not accept your own cert"

Margaret: concur, and closed.

Trust list considerations

Don't ship with pre-configured trust anchors!

Janfred: suggest to merge PR15

Margaret: perhaps not? Maybe SHOULD NOT, instead of MUST NOT? Can we
even add trust anchors?

Alan: there are large issues with using commonly known trust anchors.
perhaps use-specific CAs.

Alex: maybe pre-install, but disable for a agiven client by default.

Margaret: there are multiple equivalent cases here

Janfred: if we use the web PKI, then they will trust any cert by default

Margaret: we would need good justification to use pre-installed CAs, and
would need to know that they're secure.

Fabian: the goal should be to encourage the admin to make an informed
decision about what the trust anchors should be, rather than an unknown
default.

Margaret: rough consensus is to merge PR 15

Janfred: rephrase it based on Fabians comments. trust decision by admin,
and don't default to list which is unknown to the admin

Connection timeouts

Janfred: proposal is to unify text around connection timeouts, and
suggest that it be configurable by admins

Margaret: anyone disagree with this recommendation?

Alan: maybe ala 2865, if you're not sending any traffic, it may be OK to
close all connections

Heikki: some may want to leave connections open, to see if things are
still working, which will help with faster fail-over if things go wrong

Margaret: any objections to text? Hearing none, we go with the changes,
and Janfred decides about reverse CoA text.

Downgrade / duplicate IPs

RADIUS/UDP and RADIUS/DTLS from same source IP, such as behind a NAT

less likely to mis-identify same client / relying party for TCP / TLS,
as they are connection based

Margaret: do clients use same source port for different destination
ports?

Michael: absolutely, yes, for UDP. This happens all of the time with
IPSec port 500

Margaret: then this is a potential attack

Fabian: whether it is an attack is implementation-specific. If we do
src/dst ip/port, then the DTLS layer will see it's not DTLS, and will
discard it

Mark: how does TLS-PSK interact with this issue

Alan: shouldn't make a difference

Janfred: 2 clients behind NAT, one used RADIUS/UDP, other uses
RADIUS/DTLS. So server might be sending responses to same destination
port with different protocols, but perhaps different server source
ports?

Alex: you need to consider server IP/port, too.

Alan: we're asking here for down-bidding, if the same IP can be used for
RADIUS/UDP and RADIUS/DTLS, then we are subject to down-bidding attacks
for this source IP

Margaret: we have no way of knowing what protocols are used in other
hops, so reference deprecating-insecure-practices here, too

Alex: problem is accepting UDP and DTLS on the same port on the same
server? Maybe just forbid that in the security considerations section?

Margaret: may not be useful to enumerate this.

Fabian: +1

Alan: server port doesn't matter, it's a downbidding attack from the
source IP

Fabian: for clients, don't mix TLS with non-TLS servers, or you could be
downgraded

... much discussion on what the issue is, and what we need to fix.

Margaret: leave this to talk about in November. cross-protocol proxies
exist

connected sockets

Alan: DTLS avoids the race condition I was worried about, we can use
connected sockets for DTLS

Janfred: put in text for connected socket as per slides

Margaret: put it in implementation considerations section

Janfred: connected sockets helps simplify implementations. OK with
putting text in "implementation guidelines", but it's short, so it can
go elsewhere

Margaret: any objection to Janfred cleaning it up, and then talk more in
november?

Other issues

Janfred: for now, have more review of PR 18 on crypto agility.

Janfred: no comments on PR 6, seems straightforward

Janfred: reply with Protocol-Error to unwanted Accounting-Request
packets? What about backwards compatibility?

Alan: it depends on what client would do

Margaret: some clients send 1000s of accounting requests for every
Authentication Request. Perhaps we should take the connection down? or
if we don't use accounting for this connection

Alan: this is likely an admin issue, and can't be resolved on a protocol
basis

Janfred: 6614 already has specific text on receive unwanting
accounting-request, should reply with Accounting-Response with
Error-Cause, and client should honor it

Alex: stop sending packets on "this connection". what happens if the
config changes?

Alan: I don't know of any client or server which implements the
suggestion of 6614

Margaret: unwanted packets is not a TLS specific issue.

Fabian: TLS or DTLS does not change the RADIUS properties, so we should
likely not define new responses in this draft.

Janfred: add to list of "lets' fix RADIUS", and mark this as not TLS
specific. For UDP we have different ports, but for TLS we use the same
port for everythng. So it is somewhat TLS specific. Not responding may
lead to availability issues?

Margaret: we have to be able to throw away packets in any case, e.g.
with bad secret.

Open Mic (10 min)

Closing: (Chairs, 5 min)