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)

• 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:

(Datagram) Transport Layer Security (D)TLS 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)

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)

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)

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:

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:

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)

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.