[Gen-art] Re: Genart last call review of draft-ietf-radext-radiusv11-08

[Alan DeKok <[e-mail]>]

On Jun 27, 2024, at 7:50 AM, Christer Holmberg via Datatracker <[e-mail]> 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.