Minutes IETF116: radext: Tue 08:00
minutes-116-radext-202303280800-00

Meeting Minutes RADIUS EXTensions (radext) WG
Date and time 2023-03-28 08:00
Title Minutes IETF116: radext: Tue 08:00
State Active
Other versions markdown
Last updated 2023-03-28

minutes-116-radext-202303280800-00

RADIUS Extensions (radext) WG Meeting Notes for
IETF 116: Yokohama, Japan

AGENDA:
____

———————————————————————————————————————————————
IF TIME ALLOWS (otherwise, please provide feedback via email)

Request for feedback from the RADIUS community:
RADIUS Profile for Bonded Bluetooth Low Energy peripherals
https://datatracker.ietf.org/doc/draft-grayson-radext-rabble/

Meeting notes

No agenda bashing

Reverse CoA

Reverse CoA is a method to send CoA packets over an existing TLS
connection to a NAS that would otherwise be unreachable due to FW/NAT.

Operator-Realm is used to select the correct reverse TLS connection.

Aruba, Cisco, and FreeRadius have already implented this for ~1y.

Q from Heikki: concerns regarding the name, perhaps consider "CoA over
existing transport"
A: TLS and DTLS already allow CoA in the forward direction. Reverse CoA
is not a good name but unclear on better options.

Q from chairs: who has read the document
A: very few

Asking people who haven't read to adopt it is questionable, call for
adoption will happen on the list after the meeting.

Q from Mark: Caution that not all roaming federations use tag 1 for
identifying operators, suggests OpenRoaming uses tag 4
A: Tag 1 is what is standardsed in the IETF, it would be worth adding to
the document a note that this is not always the case

Action items: Call for adoption on the ML

ALPN for RADIUS

MD5 is dead, properly dead.

Use (D)TLS ALPN on port 2083 to remove the dependency on MD5 for the
session transport.

"RADIUS/V1.1" profile. User-Password is encoded as text, protected by
TLS. CHAP etc can still be transported as proxies treat them as black
boxes.

Home servers can still do MD5 authentication if they so wish.

This allows proxies to be FIPS compliant.

16-octet unused field in the packet header. Used to add a 32-bit
request/reply token, and flags to indicate if a packet was transport
securely.

Implemented on a per packet basis. Per-realm etc out of scope for now.

Author considers document mostly done.

Q from Janfred: Strict Transport Security flag may be worthwile, same
basic effect as HTTPS-STS.
A: How does the NAS know to set this flag? We can put the flag in, and
leave the rest to "implementation magic".

Q from Heikki: Password field will be text type, passwords are not
always UTF-8, would it be safer to treat it as a binary blob?
A: Unsure if we want to change that much from RFC. We should consider a
note about possible malformed non-UTF-8 passwords.

Q from chairs: Who has read this document?
A: all two of you! Will go to list for adoption.

Action items: Call for adoption on the ML

TLS-PSK

Certificates are hard, expire, etc. We all know this.

PSK is simpler to manage, it would be worthwile to document how to use
PSK.

Changes from shared secret: we need identity, not just a secret.

Ongoing discussions on the ML about sharing identity between NASes.

Q from Heikki: §4 discusses guidance for RADIUS clients, does this also
include server-server proxies?
A: Yes

Q from Heikki: Document should be updated to be consistent about TLS
version number
A: Agreed

Q from Heikki: Document should contain a discussion on the good parts of
certificates as well.
A: Agreed

Q from Janfred: PSK is one use case for those who just want to move to
something familiar from UDP. Is this true?
A: It is

Comment chairs: As the operators of the US NREN TLS-PSK would be a much
easier transition.

RADIUS/(D)TLS to Standards track

Fun fact from Germany: they run their own eduroam CA.

RFC6614 only discusses TLS and not DTLS, probably worth including both.

Updates to TLS versions have happened. Reference to TLS BCP added.

TLSv1.3 is RECOMMENDED not MANDATORY so as not to change the spec too
much.

Work to be done on thinning down section on TLS-PSK.

Raw Public Key needs expansion.

SNI needs development.

Disscussion still needed on credential sharing.

TLS-PSK: REQUIRED or RECOMMENDED?
TLS-RPK: RECOMMENDED, OPTIONAL, or even REQUIRED?

Question to the room: is anyone using subjectAltName:naiRealm?

Q from chairs: how many people have read?
A: 3 or 4

Recommendation from chairs to read this document as it is pretty core to
the WG.

Q from Alan: Happy to merge DTLS, although concern about too large of a
document.
A: Throwing TLS and DTLS in the same document is a good idea, dynamic
discovery in a separate document however.

Q from Heikki: Should we mandate TLSv1.3
A: RFC6614 mandates TLSv1.2 and we don't want to change too much, no
objection if the WG feels otherwise.

Take question on TLSv1.3 to the ML.

Deprecating insecure uses of RADIUS

Once again for everyone: MD5 is a trashfire.

Sensitive location and device data is sent in the clear.

Proposal: just use TLS or IPSec.

Some cloud providers (not naming names) care less about security and
just throw UDP over the internet.

There seems to be experience with TLS, less so with DTLS.

Some widely used servers do not support TLS at all.

Q from Heikki: There was discussion on the ML about IPSec being
problematic as the RADIUS server may not be aware that the connection is
happening over an IPSec tunnel
A: TLS would be better

Status-Realm/Loop Prevention

Operating a multi-hop RADIUS network is stuck in the 1970s, we want to
bring it into the 1980s or 1990s, with things such as multi-hop pings
(revolutionary!).

Basic functionality is already implemented in FreeRADIUS.

There was a suggestion to add a timestamp to Status-Realm. Would require
work defining a high resolution timestamp type, and clock skew would be
a concern.

WG needs to ask IESG/IANA for a packet type code. Some confusion about
how to progress this. No objections to making a request for this.

Q: how many people have read the ID?
A: co-author and one other guy, possibly as many as 3!

Q from Alexander: On the topic of timestamps, we cannot have asymetric
routing in RADIUS so the delta would still be useful.
A: No objection to doing the work, if it useful.

Comment from Alan: Call it an int and describe it as "delta in ms"

8-bit ID Space

8-bits is really not enough. We already have the authenticator field we
can use as a unique ID for RADIUS packets.

Negotiation of this is a bit of a nightmare. It needs simplification or
entirely removing it.

Preliminary implementations have been done.

Do we even need this or do we just say "everyone use TLS?".

Comment from chairs: It would be nice to have one less document.

The current 8-bit ID space is per packet type. This causes problems with
protocol errors. "There's a lot of trauma there".

Comment from Alexander: Would approve getting rid of this in favour of
ALPN.

Comment from Janfred: Would also support forgetting about this.

AoB

Comment from Mark: Using RADIUS to expand on virtual MAC addresses.
Feedback requested on draft-grayson-radext-rabble.