Nov 7th 2022 1300 UTC Mezzanine 1-4 Room
Chair: Stephen Farrell
Note taker(s): Stefan Winter, Vadim ...
ad 1.
Chair kicked off meeting at the minute. All preliminaries done, agenda
accepted as-is.
ad 2.
2.1: Alan DeKok presented his slide deck on Operational and
Implementation Experience.
Q&A. (No questions)
Next presentation: RAD-EXT-RA.
Q&A. General nodding in the room.
Karri Huhtanen: interoperability is important. Work should be done here
in the IETF. Radiator backs all the efforts discussed here.
Bernard Aboba: Is DTLS actually out there? A: Two AP vendors seem to do
this.
Russ Housley: Support the work - issues need fixing, and no other
solution on the horizon.
Next presentation: Deprecating RADIUS UDP/TCP.
Wes Hardaker: Backward compatability and difficulties for deployment.
Why would people switch now?
SW: ...
Will TLS-PSK really take off? A: Easy to generate meaningful secrets;
but if you really want to, you can still mess it up. Too bad for you,
then.
Karri Huhtanen: Accounting also important and needs to be secured.
Bernard Aboba: keep in mind that deployments may need to configure PSK
in many devices. Can still be hard (especially b/c need different PSKs
for every TLS version.) Alan: is a tough problem, being worked on.
Margaret Cullen: Also worried about downgrade attacks. Important to
consider background compatibility thoroughly; also between
patched-RADIUS and SRADIUS. Alan: SRADIUS is hop-by-hop, different
transports can be applied on every RADIUS hop.
Tom Vrancken: Can do Kerberos in TLS. Is this helpful? Alan: can be
helpful, better than making up shared secrets, interesting.
Ian Dickinson: Managing secrets in general - maybe include some BCP
text? Alan: Yes, useful for PSK management (classic shared secrets going
away anyway). Better to rely on other standards.
Next presentation: SRADIUS.
Next presentation: Extended ID.
Next presentation: reverse CoA.
Q&A: Heikki: Current drafts are already a reasonable start, interesting
to implement them. Interop, complexity? Alan: Extended ID probably most
complicated and possible issues; other drafts small and stand-alone.
2.2: RADIUS/TLS update. Presentation by Janfred Rieckers.
Q&A. Tom Vrancken. Raw Public Keys indeed interesting. GnuTLS supports
it! (second implementation in progress); openssl lacking still.
Heikki. Session Resumption? Is this necessary? Not discussed in RFC6614
currently. Janfred: let's think this through offline, complex topic.
Karri: could also consider text around "dynamic" TLS sessions (torn down
after a timeout) vs. permanenet ones (with keepalive). Draft needs some
work here and there (e.g. client authorisation checks not very useful
behind NAT). Operational comments: upgrading to RADIUS/TLS typically
takes a long time. Current draft may help in speeding this up (e.g.
PSK). Implementations need to coordinate among themselves for best
interop; working group would be the place for such.
2.3: RFC6421, presentation by Bernard Aboba.
Stefan Winter: good point about WFA certification. Happy to take this
forward once RFCs are available. On the fringe of WFA responsibility
maybe - defers AAA transport rules to IEEE 802.1X, and that does not
require any specific AAA transport to be used.
Alan DeKok: Solutions more of a political nature not technical.
ad 3 and 4.
Chair started. Draft charter presented - not ready for immediate
approval, but basis for thorough discussion in the BoF.
Mic open.
Karri Huhtanen: Add some text about Operational recommendations, and
coordinate work for each of the drafts.
Joe Salowey: compat between RADIUS and Diameter? Still? Suggest to drop
that. Group: No disagreement to that.
Also, don't deprecate before new solutions are out. Again, no
disagreement.
Chris Inacio. Transport agility? Alan: RFC3539 is old but relevant. If
not compatible, be sure to discuss why. Suggestion for change "if not
being compatible with 3539, update 3539 (or just explain why)".
Bernard Aboba. As author as 3539: was more about SCTP. Reference could
just as well go away. Thumbs up in the room. Best to remove this.
Stefan Winter. Some of the work is intentionally backward incompatible
(SRADIUS). Re-wording might be appropriate.
Janfred. Fate of RFC6613? Needs to be standards track as RFC6614 depends
on it; but at the same time is unencrypted and candidate for
deprecation. Better to downref maybe?
Bernard Aboba. Mandating TLS 1.3 for RADIUS/TLS premature. Better stick
with min 1.2 (but do support 1.3) and make the leap to min 1.3 with
SRADIUS only. Group agrees.
Margaret Cullen. If still supporting TLS 1.2, keep in mind that
certificate is exposed in the clear - privacy implications? Not a
charter question; but to be considered during draft work.
Paul Wouters. Look at UTA-TLS spec. Considerations to previous item to
be found in there. RFC7525-bis.
Margaret: in EAP, this is a more significant problem as client cert
properties are exposed. Maybe less so on transport level, to be
verified.
Stephen: maybe add a generic sentence in charter about TLS versions and
exposed cert properties/metadata leakage?
Rick van Rein: time-limit usage of TLS 1.2? Stephen: Not something for
this group.
Heikki: TLS 1.2 would seem good enough for client-server transports;
less so for EAP. Of course TLS 1.3 should be preferred if available.
Margaret: just remove the sentence? But then no guidance on versions at
all.
Alan: TLS 1.3 is out long enough - no reason not to require it.
Alan: my own text on SRADIUS bullet is wrong. Please delete last
sentence of that bullet. Suggestion from Margaret on the list, which is
fine.
Paul Wouters: how can removal of MD4/MD5 and retaining backwards compat
go together? Is this really pure transport work? Alan: intent is just
transport; text to be changed to make that clear, as per above.
Bernard: FIPS clarification. Algorithms are entirely turned off. No need
to deprecate attributes; just define how server reacts when presented
with such legacy attributes. Stephen: again, Margaret's text suggestion
seems suitable. Group nods.
Wes Hardaker: some text parts over-described (like TLS versions) - can
also relax wording towards more generic statements; keep details to
actual work.
Alexander Clouter: 64 bit datetime type interesting, but not crucial.
Could be deleted from charter - but still worked on. Philipp: 32-bit
even sounds sufficient. Stephen: delete from charter then? No
disagreement.
Vadim: could exchange "deprecating UDP and TCP" with "deprecating
insecure transports" (imagine someone specing RADIUS/QUIC which IS UDP
but could still be secure). Agreement in the room.
Janfred: could strike sentence about Server Name Indication - too
specific for charter text. Suggest to remove. No disagreement.
Margaret: Realm-Status work. Spec and implementation available - why not
add it directly to charter? "Improve operations for multi-hop RADIUS
networks: 'ping' and 'traceroute' equivalents, including loop
prevention". No disgreement on this work.
Roman Danylow: are those three additions sufficient? More to add?
Alternative wording from Margaret in chat (got group appraisal).
Margaret: not an invitation to open Pandora's box. Not every good idea
needs to get implemented from the outset. Restrict to most important
tooling.
Stefan: Consider error response codes? Existing mechanisms can be used
(Protocol-Error; +something in the realm-status draft). Doing so seems
okay for the group.
Philipp: note timescales - takes long to produce specs; so think early
about changes that might become needed in a decade, and consider them
right now.
ad 5.
Poll:
Q1 - Well specced? unanimous Raise Hand (29 / 0) towards Positive.
Q2 - IETF work? Raise Hand ( 35 / 1) towards Positive.
Q3 - Review drafts? about a dozen on-site plus four remote people show
hands
Q4 - Edit drafts? Five hands in the room, seven total.
Q5 - Form WG with refined charter? unanimous, 36 / 0.
Paul Wouters: one more poll please: "Vendors, expect to implement the
outputs of the working group?" 9 "Raise Hand", 1 "Do not raise hand"
Margaret: Another poll: "Expect to deploy the outputs?" 12 Raised Hands,
1 Not Raised Hand.
ad 6.
Paul Wouters. Good to see no controversy. WG forming will be discussed
within ADs and IESG. If you want to talk privately, can come to the ADs.
Thanks for editing the draft charter with the suggested edits discussed
earlier.
Paul: how about chairs? Ideally not document authors. Volunteers please
make yourselves known to the ADs.
The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol pending approval of the new work from the Area Director
and clarify its usage and definition.
Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
the following restriction is imposed on extensions considered by the
RADEXT WG:
The WG will review its existing RFCs' document track categories and
where necessary or useful change document tracks, with minor changes in
the documents if needed. Any changes to document tracks require approval
by the responsible Area Director.
Work Items:
The immediate goals of the RADEXT working group are to address the
following issues:
Deprecating UDP as a transport for RADIUS outside of secure
networks. This work updates RFC 6421.
Moving RFC 6613 (RADIUS/TCP), RFC 6614 (RADIUS/TLS), and RFC 7360
(RADIUS/DTLS) to Standards track. Mandate the use of TLS 1.3. Adding
TLS Server Name Indication to TLS-based transports.
Define best practices for RADIUS roaming, and roaming consoortiums
using based on experience with RADIUS/TLS.
extend the 8-bit RADIUS ID space to allow more than 256 "in flight"
packets across one connection. No changes to packet format are
permitted.
Allow for CoA / Disconnect packets to be sent in "reverse" down a
RADIUS/TLS or RADIUS/DTLS connection. This functionality permits the
forward and reverse path to be identical, and assists with transit
of NATs.
TBD - Add a 64-bit "date" type. The "date" type is a 32-bit unsigned
value, so it has a Y2106 problem, not a Y2038 problem.
Defining a secure variant of RADIUS which does not use deprecated
cryptographic methods such as MD4 and MD5. This variant will be
suitable for use in a FIPS compliant system. The transport will be
required to be TLS or DTLS. The packet format is unchanged from
RADIUS. However, the packets no longer need to be signed. The
attribute format is unchanged from RADIUS. However, attributes such
as User-Password no longer need to be obfuscated, and can be sent
as-is. Attributes which require MD4 or MD5 are forbidden. In short,
"RADIUS without MD4 or MD5".
1) Is the problem statement clear, well-scoped, solvable, and useful to
solve?
2) Is the IETF the right place for such work?
3) Who is willing to review drafts?
4) Who is willing to edit drafts?
5) Should the IETF form a WG with this charter?