Re: [radext] New WGLC for RADIUSv11

[Alan DeKok <[e-mail]>]

On Mar 7, 2024, at 10:29 AM, Matthew Newton <[e-mail]> wrote:
> Introduction, (Page 6 paragraph 1):
> 
> "A major benefit of this extensions is that a home server which implement it can also be more easily verified for FIPS-140 compliance."
> 
>  -> (extensions -> extension, implement -> implements)
> 
> "A major benefit of this extension is that a home server which implements it can also be more easily verified for FIPS-140 compliance."

  Fixed, thanks.

> Section 3.5, (Page 18 paragraph 8):
> 
> "Similarly, when a server does resumption for a session which had previously negotiated "radius/1.1", If the client attempts to resume the sessions without signaling the use of RADIUS/1.1, the server MUST close the connection."
> 
>   ", If" -> ", if"

  Fixed, thanks.

> ("signaling" rather than "signalling" throughout the document grates rather, but I suspect those over the pond would disagree!)

  It is definitely a point of concern, albeit a minor one.

> This paragraph is not clear to me. I think it is trying to say that multiple Codes are permitted per connection, but the Token is unique on that connection connection (e.g. you can NOT have an Access-Request with Token A and an Accounting-Request with the same Token A). However the last sentence seems to say that an implementation sending both Access-Requests and Accounting-Requests on the same connection is not permitted.

  The first part of that is right.  But the second part isn't.  An implementation can send multiple codes over the same connection. It cannot use the same Token value for two different Codes.

  How about this:

In contrast, the Token field MUST be managed solely on a per-connection basis, independent of any packet Code.  An implementation can, for example, send both an Access-Request and an Accounting-Request over one connection at the same time, but those two packets MUST use different values for the Token field.  That is, the method for generating new Token values MUST be independent of the packet Code.

Systems generating the Token can do so via any method they choose.  For simplicity, it is RECOMMENDED that the Token values be generated from a 32-bit counter which is unique to each connection.  Such a counter SHOULD be initialized to a random value, taken from a random number generator, whenever a new connection is opened.  The counter can then be incremented for every new packet that the client sends.  This method ensures that the Tokens are unique, and are also independent of any packet Code.

  Alan DeKok.