Re: [radext] Extended IDs

[Alan DeKok <[e-mail]>]

On Dec 1, 2017, at 11:15 AM, Jakob Heitz (jheitz) <[e-mail]> wrote:
> 
> What if the quantum computers turn out to live up to their promises? Then we can throw out all this authentication stuff and decide to not share our Ethernets with the attackers instead. No more request authenticator.

  I'm sorry, but that just isn't realistic.

  If quantum computers can crack encryption, then RADIUS security will be the least of our issues.

> The request authenticator is already overloaded. It may be used for the CHAP challenge. Now, you want another overload?

  I'd like to use an existing field, yes.

  The draft explains why this works.  In detail.

> The request authenticator is not reflected back in any return packets. The response authenticator is a different number. Suppose the client has several requests outstanding with the same id. When it receives a response, it has to hash it with every request authenticator from these outstanding requests to figure out which one the response is for.

  Please don't claim there are problems with the draft until you read it.

  The draft EXPLICITLY STATES that the request authenticator is echoed back in a new attribute.  It has many, many, pages to discuss all possible issues with that practice.

> Conflicting requests: if the server receives a request identical to one it received before and has a cached response, then retransmit the cache, else process it again. How to determine “identical request” is a local matter.

  Those are duplicate requests.  They were defined 10 years ago in RFC 5080, Section 2.2.2, including how to determine what a "duplicate request" is.

 https://tools.ietf.org/html/rfc5080#section-2.2.2

  RFC 5080 also defines what RADIUS servers should do with these requests.  My comment was about *conflicts*.

  i.e. a RADIUS server receives an Access-Request from a client (src/dst, IP/port, ID 0, request authenticator A).  While the server is processing that packet, the client (for whatever reason) sends a *different* packet with the same src/dst IP/port.  ID 0, but a *different* request authenticator.

  Should be server respond to the first packet?  Or should the server respond to the second packet?  Or should it respond to both?

  Again... this issue is discussed in detail in my draft.

> Comparing ID alone is clearly not enough. Comparing anything less than the whole request packet risks misidentified duplicates.

  That simply isn't true.

  Again, please read the draft.  This is discussed in excruciating detail.  Including the possibility of false positives, false negatives, etc.

> If the short cut misleads, then don’t take the short cut.

  I think the only short cut here is the decision to skip reading the draft before commenting on it.

  Alan DeKok.