Re: [radext] Extended IDs

["Brian Weis (bew)" <[e-mail]>]

Hi Alan,

> On Dec 11, 2017, at 5:52 PM, Alan DeKok <[e-mail]> wrote:
> 
> 
>> On Dec 11, 2017, at 8:08 PM, Brian Weis (bew) <[e-mail]> wrote:
>> 
>> I’ve read through the latest versions of both drafts, and I do prefer the approach taken in draft-chen-radext-identifier-attr.
>> 
>> From a protocol perspective, the two approaches do not seem very far apart to me. They both seem to do the following. (1) Define a new per-connection attribute as part of a Status-Server message. (2) Specify that a client chooses when to use a larger identifier. (3) Specify that when the server recognizes the “new extended field”, then it is obligated to return the original values of both identity field and the “new extended field”. (4) The server need not have any knowledge as to how the “new extended field” is determined.  (5) If the server does not recognize the new attribute, it ignores it. So in neither case do that the mechanism seem to unduly modify RADIUS.
> 
>  The differences are that the draft-chen proposal effectively modifies the RADIUS header, and that it has the opportunity for "leakage" of extended IDs in the case of error or misconfiguration.

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.)

> 
>  My draft has none of these issues.

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

> 
>> It seems to me that the real difference comes down to how the “new extended field” is carried — either in the new per-connection attribute, or by overloading the Request Identifier. 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
> 
>  Risks like... ?
> 
>  I must admit to being a little surprised at the dislike of "overloading" the Request Authenticator field.  As Peter Deacon pointed out, it's already "overloaded" for many, many, other things.
> 
>  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).

> 
>  So we're left with a field that we cannot change, but we can look at.  What is the risk in looking at it?  What is the risk in echoing it verbatim in a response packet?
> 
>  I understand that saying "we add a 32-bit ID" is conceptually simpler.  But I still don't get where any "risk" or concern with "overloading" of the field comes from.  Some additional explanation would be useful here.
> 
>> my preference is to adopt the explicit approach in 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.
> 
>  How?
> 
>  The draft goes through exhaustive enumeration of the possibilities.  It shows that the proposal is no worse than existing RADIUS, and in some cases is substantially better.

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.

>> However, I also believe that there is a lot of good background and explanatory text in draft-dekok that is valuable and if the working group takes draft-chen as the base then some of this would be valuable to bring that into the draft. This might address some of the concerns that draft-chen is under-specified.
> 
>  I agree.
> 
>  I think a large part of the concern here is due to the background and explanatory text in my document.  i.e. a proposal which describes the risks seems risky.   A proposal which ignores the risks seems less risky.

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.

Thanks,
Brian

> 
>  But I would still like to understand (a) what the risks are here, and (b) why there's a concern with "overloading" a field that cannot be changed, and is already used for many things.
> 
>  Alan DeKok.
> 

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: [phone]
Email: [e-mail]