Re: [radext] Proposed new charter text

[Peter Deacon <[e-mail]>]

On Sun, 22 Mar 2015, Alan DeKok wrote:

> On Mar 22, 2015, at 3:35 PM, Peter Deacon <[e-mail]> wrote:

>> While I generally support approach and associated draft 
>> draft-dekok-radext-coa-proxy-00.txt have some concerns and would prefer 
>> to keep some prescriptive details out of the charter.

>  What exactly is the benefit of making the charter more vague?  You have 
> “some concerns”.  Well.. I would appreciate discussing those concerns 
> openly, instead of changing the charter to address unspecified issues.

My understanding this would be a new item rather than change to an 
existing WG work item currently on the charter.  Stefan solicited feedback 
and I gave it.  The CoA draft as written would certainly continue to fall 
under my proposed change.  I am aware of nothing lost by proposed text.


Concern regards intent of Operator-NAS-Identifier.

Dynamic authorization allows multiple sessions to be influenced with 
single requests.  Sufficient / required session identifying attributes 
varies between NASes and sometimes across access technologies within the 
same NAS.  There are no further constraints expressed in draft on both 
required / acceptable session identifying attributes and method of initial 
authentication proxy (realm based or other policy based)

So I'll throw the question back at you.. how the heck is this supposed to 
work?

Proxy of DM following initial realm based auth proxy:

Operator-Name
Operator-NAS-Identifier
Acct-Session-Id
NAS-IP

Proxy of DM following initial policy based auth proxy:

Operator-Name
Operator-NAS-Identifier
User-Name
NAS-IP

When the upstream proxy in a forwarding chain gets the request how is it 
supposed to know whether it is safe to pass up the chain without either 
keeping a lot of state or verifying some kind of secure stateless 
signature/token conveyed within Operator-NAS-Identifier?

Section 3.1 of the draft makes it clear Operator-NAS-Identifier is not 
just a fungible label for a generic state attribute with the "20 octets" 
language and associated removal of NAS-Identifying attributes.


I see two opportunities:

Get to working by constraining both means of authentication proxy and 
session identifying attributes.

Or you can get there by keeping state at which point the language of 
Operator-NAS-Identifier in my judgment is insufficient.  While it may 
well resolve any ambiguities as to "where" the request is going it does so 
while missing the larger problem.

> The idea has been presented at meetings going back 3-4 years, IIRC.
> The only discussion of this topic has been supportive of this approach 
> taken here.

As earlier I also support the general "idea".

regards,
Peter