IETF 117, San Francisco

July 24th, 2023, 9:30 - 11:30 PDT (16:30 - 18:30 UTC)

• Administrivia and WG Status (Chairs, 15 min)

• (Datagram) Transport Layer Security (D)TLS Encryption for RADIUS
  (Janfred, 30 min)
  draft-janfred-radext-radiusdtls-bis

• RADIUS Version 1.1 (Alan, 15 min)
  draft-ietf-radext-radiusv11

• RADIUS and TLS-PSK (Alan, 10 min)
  draft-dekok-radext-tls-psk

• Reverse CoA in RADIUS (Alan, 10 min)
  draft-dekok-radext-reverse-coa

• Deprecating RADIUS/UDP and RADIUS/TCP (Alan, 10 min)
  draft-dekok-radext-deprecating-radius

• RADIUS Attributes for 3GPP 5G AKA Authentication Method (Sri, 20
  min)
  draft-gundavelli-radext-5g-auth

• Closing (Chairs, 10 min)

draft-janfred-radext-radiusdtls-bis

Reminder of consensus calls on the ML before this meeting, agreed to
merge RADIUS/DTLS and RADIUS/TCP into one document.
This document is the result of that.

The document is a more or less complete specification, albiet with many
comments and unanswred technical questions.
Security Considerations are yet to be completed.

Open questions:

• Implementation Guidelines?
• Design Decisions
• Timeouts?

Alan is in favour of adding implementation guidelines and design
decisions.

Wherever the current text is ambiguous or unclear, we should update
protocols to match what is currently implemented.
Current implementaions to base off include: Radsec proxy, Radiador,
FreeRadius.

Should it be mandatory to implement RADIUS/TLS, RADIUS/DTLS, or both?

Alan strongly suggests to implement both. Given most people have
implemented TLS, that should be mandatory, with a strong recommendation
to implement DTLS. Q seconds.

Show of hands in the room: TLS mandatory, DTLS mandatory, or both.
Plurality for TLS, with a smaller amount for both, and none for DTLS. To
confirm on the list.

Should a single port be used for authentication and accounting? Alan
says everyone does this, so it should stay this way.

Different ports would be useful for load balancing auth/accounting
differently. Alan says this should be a site local decision and left to
implementations.

Show of hands in the room: single port is the favourite, to be confirmed
on the list.

Did anyone implement MIBs? Alan says MIBs don't tend to be widely used,
even if implemented. To be followed up on the ML.
Alex says we have better things to do than try to force everyone to
measure the same.

Merging all documents has created conflicting texts about watchdogs. Q
suggests Status-Server should be used for both TLS and DTLS, in spite of
DTLS heartbeat. Aaron agrees.

Aaron suggests watchdogs should be sent periodically, not as and when
the remote end might be down. He will follow up on the ML with a
suggested text.

Should Status-Server requests use an ID of 0 to preserve the limited ID
space? Alan says implementations currently do this, so should be part of
the standard. Janfred agrees.

Should the document reference RFC9325? Suggestion from the chair to just
do it, no dissent from the room.

draft-ietf-radext-radiusv11

Updates since IETF 116:

• flags removed
• signalling in the error case

Should the Protocol-Error packet be used to signal ALPN negotiation
failed? Would be more useful for administrators, although current
implemantions will no nothing of what to do with it, they might log it
anyway, or the reason could be discovered with a Wireshark decryption.

Any indication back is better than no indication back. "What the hell?!"
is not actionable.

Aaron suggests should TLS alerts be used instead? How would a client
alert a server that doesn't support ALPN?

RADIUSv1.1 is 99% done, the most difficult remaining portion is working
around OpenSSL.

draft-dekok-radext-tls-psk

Updates since IETF 116:

• discussion on why to use PSK
• guidance on how to use it

Largely agreement on how to use it, pretty close to last call.

draft-dekok-radext-reverse-coa

No updates since IETF 116.

Aruba, Cisco, and FreeRadius already support it. There doesn't seem to
be much in the way of implementation issues.

Last call to be completed on the ML once updated.

draft-dekok-radext-deprecating-radius

Document is largely done. It should be published after 6614bis.

Needs a section added on how to make plaintext UDP/TCP more secure, if
its use is unavoidable.

Last call on ML after meeting.

draft-gundavelli-radext-5g-auth

This document aims to standardise entity in accessing private network
architectures across 5G, WiFi, and Ethernet.

Reuse much of the deployed AAA infrastructure in enterprises.

New attributes prefixed with '5G-' for 5G-AKA specific values.

Question about how this relates to EAP-AKA? 5G supports both EAP based,
and non EAP based. This standard allows use of non EAP based.

Security considerations need to be written.

Chairs: this document needs review from the 3GPP, this WG does not have
the expertise to fully review this document.