# RADEXT WG @ IETF 118, Prague {#radext-wg--ietf-118-prague} Friday, 10 November 2023, 13:00 - 15:00 CET (12:00 - 14:00 UTC) Notes: MCR, Janfred ## Administrivia and WG Status: (Chairs, 10 min) {#administrivia-and-wg-status-chairs-10-min} * Note Well and IPR statements * Agenda bashing * Document status update Liaison Letter from WBA received few days before this meeting, too close to have it as an agenda item. Document is available in Datatracker. Some discussion on the list started, how do we respond? Paul (AD): We should send a response, want to pull some more IESG people in before responding. Wolfgang: Used for emergency calls? A: This is more on the type of connectivity they want you to have Alan: Also Geolocation, localized advertising, billing, etc. Bernard: Correction: Not used for emergency calling, that's specified by regulatory agencies. We were confused, never adoptedby regulatory agencies. ## WG Documents: {#wg-documents} ### (Datagram) Transport Layer Security (D)TLS Encryption for RADIUS (Janfred, 25 min) {#datagram-transport-layer-security-dtls-encryption-for-radius-janfred-25-min} draft-ietf-radext-radiusdtls-bis * Status and open issues Many todos mentioned. Trying to avoid another -bis in two years. In addition to Jan2024 plan, there is a need to reference this from Wifi Alliance by June 2024. Bernard Adoba(BA): WifiAlliance does extensive tests, and getting them to test reveals many bugs/issues in the document. Margaret: when we think it's ready, then asking them to review it would help AD: will take a task to put RFC6613, 6614 on radext github so that issues can be raised against those documents. Wolfgang: there are some lack of clarity when having multiple clients on a single machine, and it suggests using a proxy. Jan: if this is because the client wants to open 15 ports to maximize entropy(?) then that's fine? Fabrian: some hackathon results, the certificate validation of server certificates is a mess... we just turned it off. \{general snarky giggles} Fabian: RFC9525 just published (DNS-ID/RFC6125bis) --- what to specify in your own document. Not only what to validate, but we need to make sure to specify how to issue these certificates. (ACTION) MC: can we just point to the other documents, and just move them to standards track. Janfred pointed out the reason to have both documents, was that we can specify the MTI for (servers/clients), which we can't do that with one document. KarriHunt: also want to comment on open-roaming, and we need to say how to do the certificate validation. But at the hackathon, some of the certificates did not follow the current rules. Missing CN/subjectAltName/... Valery: ... server identity is important. Also rely on RFC9525 and RFC9325. ### RADIUS Version 1.1 (Alan, 15 min) {#radius-version-11-alan-15-min} draft-ietf-radext-radiusv11 * Status and open issues Based on Heikki's comments re-added "radius/1.0" ALPN Implemented in FreeRADIUS, to be enabled with with compile time option, not on by default. Can publish this experimental independet of 6614bis or wait on 6614bis and publish as Proposed Standard. Paul (AD): If published as experimental, then please put a time frame in it when you expect this to be moved to standards track BA: do not see a value as publishing as experimental, because others need to point to it. But, nothing should stop anyone from implementing it. ### Deprecating Insecure Practices in RADIUS (Alan, 20 min) {#deprecating-insecure-practices-in-radius-alan-20-min} draft-dekok-radext-deprecating-radius * Status and open issues PAP is better than CHAP, but no document says that. BA: most of that usage is legacy junk. (like dialup stuff?) Is there still any need to do PAP/CHAP? Alan: Esp. in eduroam there are million of users on PEAP/MSCHAPv2 MC: (trusted identity hat)... recommended practices for eduroam. MCR: PPTP is still a thing, they use password inside a not very good authenticated IPSEC tunnel, but that then goes over . This would be useful because it would show up on an audit report. BA: Exception for secure networks. Bad thing, everyone thinks their network is secure Janfred: the NOC VLAN might be "secure", there should be strong wording anyway MC: plenty of bandwidth available in a cross-over cable to do encryption. ### Reverse CoA in RADIUS (Alan, 10 min) {#reverse-coa-in-radius-alan-10-min} draft-dekok-radext-reverse-coa * Status and open issues summary: you can send CoA in the reverse direction for client->server, but TLS tunnel works in reverse too. Definitely should be experimental. Wolfgang: just call it session reuse Paul (AD): If we have more WGs who can say we already have 3 vendors shipping this, i'd be happy, but you say you need additional review. Maybe you don't need more review? Alan: Given that we haven't received much feedback on that, publish as experimental and review in ~2 years and fix issues in standards track issues Sebatian: proposes name: CoA piggyback. ## Proposed WG documents: {#proposed-wg-documents} ### Status-Realm and Loop Prevention for the Remote Dial-In User Service (RADIUS) (Mark, 10 min)) {#status-realm-and-loop-prevention-for-the-remote-dial-in-user-service-radius-mark-10-min} draft-cullen-radextra-status-realm Open Questions: * MTU constraints for additional server ID information * Comments about errors for max-hop count, esp. depending request type, call for help * Max Hop Count, should this only be in status-realm or also in access requests Alan: There are good reasons for the Hop Count to be in Access Requests, there are good reasons for leaving them out. MC: Question is if we want to forbid it in Access Requests or not. MC (Chair Hat): Discussion on the ML has come to an end, trying to get a sense of the room whether or not this document should be a WG document. Result of the Show of Hands: 13 Yes, 0 No, 14 No Opinion. ## Request for WG Review: {#request-for-wg-review} ### RADIUS Accounting Assurance (Ryan, 15 min) {#radius-accounting-assurance-ryan-15-min} Project in the Wireless Broadband Alliance (WBA) on how to deal with misreporting of usage. Several issues with RADIUS accounting came up: * Acct-Session-Id and Acct-Multi-Session-Id are not unique enough * Meaning of Acct-Multi-Session-Id is not well-defined * Limit of the Number of class attributes allowed * How to signal internal errors of the AP? BA: we should include "don't use accounting over insecure networks" to the insecure practices draft. ## Closing: (Chairs, 5 min) {#closing-chairs-5-min} Alan: To continue on issues and fixes: Finish the current docs first and then look over the other documents. One issue raised: Supplicants flood networks with retries after rejects, causing a high load on proxies/server. Example: invalid realm, expired certificates. Can cause congestion, triggers load balance action, exhausts server resources. MC: Could talk about exponential back-off, proxy duplicate retransmission Alan: Some discussion about an operations considerations document for RADIUS, i.e. for things like Fail-Over. MC: Failing over within an EAP session, the EAP session will mostly fail.