RADIUS Extensions (radext) WG Meeting Notes for IETF 116: Yokohama, Japan AGENDA: **\_\_**\_\_ * Administrivia and Agenda Bashing — Chairs (3 min) * Note-Well * Agenda Bashing * WG Charter & Milestones Review — Chairs (10 min) https://datatracker.ietf.org/doc/charter-ietf-radext/ * Reverse COA — Alan (5 min) https://datatracker.ietf.org/doc/draft-dekok-radext-reverse-coa/ (If the WG is approved) Accept as WG Document? * ALPN for RADIUS — Alan (10 min) https://datatracker.ietf.org/doc/draft-dekok-radext-radiusv11/ (If the WG is approved) Accept as WG Document? * TLS-PSK — Alan (5 min) https://datatracker.ietf.org/doc/draft-dekok-radext-tls-psk/ * TLS (and DTLS) to Standards Track — Alan (5 min) https://datatracker.ietf.org/doc/draft-rieckers-radext-rfc6614bis/ * Deprecating Insecure uses of RADIUS — Alan (5 min) https://datatracker.ietf.org/doc/draft-dekok-radext-deprecating-radius/ * Status-Realm/Loop Prevention — Josh? (5 min) https://datatracker.ietf.org/doc/draft-cullen-radextra-status-realm/ * 8-bit ID Space — Alan (10 min) ——————————————————————————————————————————————— 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 {#meeting-notes} No agenda bashing ### Reverse CoA {#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 {#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 {#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 {#radiusdtls-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 {#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 {#status-realmloop-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-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 {#aob} Comment from Mark: Using RADIUS to expand on virtual MAC addresses. Feedback requested on [draft-grayson-radext-rabble][1]. [1]: https://datatracker.ietf.org/doc/draft-grayson-radext-rabble/