Re: [radext] Small issues in the ALPN draft

[Alan DeKok <[e-mail]>]

On Mar 18, 2024, at 4:34 PM, Jan-Frederik Rieckers <[e-mail]> wrote:
> In Section 1 Introduction:
> 
> "All attributes which have simple encodings (i.e. without using MD5 obfuscation), all have the same encoding and meaning as before,"
> 
> remove ", all" in the middle.
> Also I'd remove the "i.e." and replace it with "meaning" or something similar, since only attributes with shared-secret-based MD5-obfuscation are encoded differently.

  Fixed:

* All attributes which have simple encodings (that is, attributes which do not use MD5 obfuscation) have the same encoding and meaning as before,


> In Section 2 Terminology:
> 
> I'd reorder the terminology, so "historic RADIUS/TLS" is ordered after "RADIUS over TLS" and I'd also replace the "RADIUS/TLS" in the description for "Historic RADIUS/TLS" with "RADIUS over TLS", since "RAIDUS/TLS" is defined as RFC6614 and "RADIUS over TLS" as RFC6614 or RFC7360

  I've tweaked this to be clear that "RADIUS over TLS" is used in reference to TLS issues.  i.e. "anything like RADIUS" over "anything like TLS"  In contrast, "historic RADIUS/TLS" is limited to 6614 / 7360 implementations.

  I've taken a pass through the document to confirm / update the uses of both of those terms,

> In Section 3.3:
> 
> One paragraph states that implementations which are set to forbid RADIUS/1.1 behave like RFC6614/RFC7360 implementations, but that is not completely accurate.
> Those implementations may still send "RADIUS/1.0" ALPN in the TLS Client Hello, in fact it is specified (without an RFC2119 modifier) that clients should do that.

  Added a note to that effect:

We reiterate that systems implementing this specification, but which are configured with setting that forbid RADIUS/1.1, will behave largely the same as systems which do not implement this specification.  The only difference is that clients may send the ALPN name "radius/1.0".

> Section 3.3.1:
> 
> As far as I read this section, the text assumes that the packet format of the Protocol-Error packet is equal to RADIUS/1.0, since it mentions the Response Authenticator. The Response Authenticator does not exist in RADIUS/1.1.
> It may be worth to explicitly state which packet format should be used and explicitly state what packet identifier should be used and if other attributes than the one specified are allowed.

  Updated:

... If this is done, the Identifier and Token fields of the Protocol-Error packet cannot be copied from any request, and therefore those fields MUST be set to all zeros.

The Protocol-Error packet SHOULD contain a Reply-Message attribute with a textual string describing the cause of the error.  The packet SHOULD also contain an Error-Cause attribute, with value Unsupported Extension (406).  The packet SHOULD NOT contain other attributes.


> Section 3.3.2:
> 
> "The server ACKs with..."
> I think the "ACK" should be replaced, it's always good to assume that not everyone understands terminology, and although I think most implementers will understand what "to ACK something" means, some may not.

  Updated:

The client sends the ALPN string "radius/1.1.  The server acknowledges this negotiation with a reply of "radius/1.1", and then RADIUS/1.1 is used.

> Section 4.2.1:
> Typo: "For An implementation" -> "For an implementation"

  I can't see that.

> Section 4.2.2:
> The first section states "e.g. TLS transport" for deduplication, but with DTLS we may still need deduplication.
> Since we introduced "TLS" as "TLS or DTLS" in the terminology, it would be good to explicitly exclude DTLS here.

  Updated:

... Where RADIUS does not require deduplication (e.g. TLS transport), the server SHOULD NOT do deduplication.  However, DTLS transport is UDP-based, and therefore still requires deduplication.

> After having read the document again, I'm also not exactly clear about the reasoning behind the 3rd paragraph (closing a connection that re-uses token values).
> Having a rationale behind this specification would be good.

  Updated:

  ...  If it determines that the sender is re-using Token values for distinct outstanding packets, then an error should be logged, and the connection MUST be closed.  There is no way to negotiate correct behavior in the protocol.  Either the parties both operate normally and can communicate, or one end misbehaves, and no communication is possible.


  The idea is that you can't negotiate your way out of protocol violations.  If a server receives two packets at the same time, with the same Token but different packet contents, then the client is broken.  There's no way to say "please follow the spec".

  Alan DeKok.