Re: [radext] Extended IDs

[Alan DeKok <[e-mail]>]

On Dec 11, 2017, at 9:39 PM, Brian Weis (bew) <[e-mail]> wrote:
> From your comments I see that the point that the draft effectively modifying the RADIUS header is due to requiring that the Extended-Identifier be the first attribute. That seems to be an optimization that does not appear to be necessary, and could be removed to address this point. (I assume either draft would undergo change if it became a WG draft.)

  It still is effectively a modification of the RADIUS header.  i.e. the 25 year-history of "look at the first 20 octets" is now changed.

  In contrast, draft-dekok changes *nothing* about request packets.

> Regarding leakage, does a proxy normally replace the Request Authenticator field with a new value? (I’m asking for information.)

  Yes.  draft-dekok is hop-local by design.  There is no possibility to leak data which is never in the packet...

>> Given the existing definition of the Request Authenticator field, it is *impossible* at this time to change how it's calculated.  Similarly, it's impossible to change the meaning of the field for packet signatures.  And, it's impossible to change the usage of the field within other attributes.
> 
> I’m missing where draft-chen does any of these things (assuming that the “MUST be first attribute” is removed).

  It doesn't.  But neither does draft-dekok.  My comment was about risk, not about draft-chen.

  i.e. draft-dekok changes nothing about Request Authenticator, but it's risky.  Or, draft-chen adds a 32-bit ID which may leak across proxy boundaries, and has undefined behavior when an extended ID is re-used.  But that's less risky.

> I appreciate the enumeration, and I’m not implying that you’ve missed any known risk. But so often overloading fields leads to unforeseen results (due to bad assumptions by a developer or future specification writer) and that’s the basis for my concern.

  The exhaustive enumeration of possibilities was intended to mitigate the risk, by explaining and understanding all possible situations.

  As for unforeseen results, RFC 2865 Section 3 says:

         ... the Request Authenticator field
         SHOULD exhibit global and temporal uniqueness.

  That sure sounds like a unique ID to me.  The draft then proposes that:

1) if a server receives a request that matches a "live" one (src/dst IP/port, code, ID), then it MAY also use the Request Authenticator to differentiate the packets
2) as a result of (1), the original Request Authenticator is echoed back in response packets.

  That's really it.  I'll remind the WG that the behaviour of (1) is currently *undefined* in RADIUS.  So the draft is arguably mitigating the existing risk by defining that behaviour.  Not only for the new proposal, but also for existing RADIUS.

> Personally, I did not find the background and explanatory text to make draft-dekok seem seem more risky. I’m reacting to the overloading, where given similar outcomes I prefer not to introduce additional semantics to an existing field.

  The concern here is that we *already* have these semantics on the Request Authenticator.   Implementations *cannot* inter-operate without choosing some semantics for Request Authenticator.  

  So draft-dekok just explains these semantics, documents existing practice, and explains how existing semantics can be leveraged to gain new functionality.

  I think the main difference here is that it's simple to say "add a 32-bit attribute".  In contrast, it seems weird to use the Request Authenticator like this.  But as an implementor... it's already being used like this in ever server implementation in the world.

  Alan DeKok.