On Jun 27, 2024, at 7:50 AM, Christer Holmberg via Datatracker
<nore...@ietf.org> wrote:
> Major issues:
>
> Q_MAJ_01:
>
> Section 7.3 says that future standards can "inherit" the RADIUS/1.1
> procedures,
> but they do not need to mention RADIUS/1.1 explicitly.
>
> What exactly is meant by "inherit"? If RADIUS/1.1 is not mentioned, does that
> mean that the future standards need to copy/paste the RADIUS/1.1 procedures?
Perhaps instead:
Future work may define new attributes, packet types, etc. It is important to
be able to do such work without requiring that every new standard mention
RADIUS/1.1 explicitly. This document defines RADIUS/1.1 as having functional
overlap with legacy RADIUS: the packet header Code field is unchanged, and the
attribute format is largely unchanged. As a result, any new packet Code or
attribute defined for RADIUS is explicitly compatible with RADIUS/1.1: the
field contents and meanings are identical. The only difference between the two
protocols is that obfuscated attributes in RADIUS are not obfuscated in
RADIUS/1.1, and this document defines how that mapping is done.
> ----
>
> Q_MAJ_02:
>
> Section 7.3 specifies rules for defining RADIUS extensions.
>
> Is this specification (especially since it is Experimental) the right place to
> define such generic RADIUS extension procedures? Can the WG e.g. reject future
> extension proposals purely because they do not comply to this specification?
I'll weasel out of this one by saying (a) the WG consensus is OK with this
statement, and (b) the document is experimental. If the WG later decides to
create future proposals, it still can.
But I suspect it won't. TLS transport is 10+ years old, and has proven to
work well. There is no need for additional cryptographic work in RADIUS over
UDP.
> Q_MAJ_03:
>
> Section 9 says: "All the insecure uses of RADIUS have been removed".
>
> I don't think that is true, as no changes are done to RADIUS/UDP and
> RADIUS/TCP, i.e. they are still as unsecure as before.
Perhaps:
This specification requires secure transport for RADIUS. RADIUS/1.1. has all
of the privacy benefits of RADIUS/TLS {{RFC6614}} and RADIUS/DTLS {{RFC7360}},
and none of the privacy or security issues of RADIUS/UDP {{RFC2865}} or
RADIUS/TCP {{RFC6613}}.
> Minor issues:
>
> Q_MIN_01:
>
> It is stated that RADIUS/1.1 is not a new protocol, but rather a transport
> profile. In my opinion it is more than a transport profile, but I will respect
> the decision of the community.
It likely fits in between a new protocol and transport profile.
The key thing for implementors is that it's a ~2k LoC patch to RADIUS/TLS
implementations. The protocol state machine doesn't change. The packet
encoding has only trivial changes. The attribute encoding as only trivial
changes.
As a result, implementations can tweak their transport layer, and change
almost nothing else. So it's closer to a transport profile than a brand new
protocol, packet encoding, state machine, etc.
> Q_ED_1:
>
> I think the Abstract is too long. Any explanations, clarifications and details
> should be removed.
Fixed.
Alan DeKok.
_______________________________________________
Gen-art mailing list -- gen-art@ietf.org
To unsubscribe send an email to gen-art-le...@ietf.org
