Re: [radext] Extended IDs

[Peter Deacon <[e-mail]>]

On Tue, 12 Dec 2017, Brian Weis (bew) wrote:

> draft-chen. With the same thought process I’m a little worried about 
> defining "behavior previously left open to implementation 
> interpretation” (as mentioned in Section 2.1 of draft-dekok). I cannot 
> disagree that it “should" be OK, but the lack of certainly does add some 
> risk.

Partially why I prefer draft-dekok-radext-request-authenticator.

Mitigates existing ambiguity that remains intact /w 
draft-chen-radext-identifier-attr.

> I appreciate the arguments in draft-dekok that indicate that there 
> should not be a problem with overloading, but because overloading 
> protocol fields can carry unexpected risks my preference is to adopt the 
> explicit approach in draft-chen.

Both drafts are "overloading" payload of RADIUS packets to carry 
identifiers that clearly belong in header.  This has objectively 
articulable consequences.

Due to "overloading" it is no longer possible to route and correlate 
packets based on header information.  Implementations are now required to 
decode attribute payloads to perform this function.  Possible new risks of 
request and response attributes being mishandled or misinterpreted in 
mixed environments.

Of the two draft-dekok-radext-request-authenticator appears to carry LESS 
"overload" risks as only responses are modified.  Most importantly ORA is 
native header information being used for header purposes unique to one and 
only one specific request packet.  The major reason I support 
draft-dekok-radext-request-authenticator it is intentionally designed to 
mitigate "overload" risk.


On "Overloading" invoked by transmission of ORA.. RFC2865 Section 3 
describes RA:

---
"In Access-Request Packets, the Authenticator value is a 16 octet random 
number"

...

"The value SHOULD be unpredictable and unique over the lifetime of a 
secret"

...

"Since it is expected that the same secret MAY be used to authenticate 
with servers in disparate geographic regions, the Request Authenticator 
field SHOULD exhibit global and temporal uniqueness."
---
For acct/dyn auth MD5 sum over packet.

I am aware of no objectively articulable consequences of using 
authenticator for this purpose.  There are no architecturally pure options 
on the table except time honored tradition of throwing more connections at 
the problem.

regards,
Peter