Re: [radext] Proposed new charter text

[Peter Deacon <[e-mail]>]

On Tue, 24 Mar 2015, Stefan Winter wrote:

> I like that way out, if everyone else can live with it. I'd appreciate
> comments from the working group on that topic, particularly from the
> three of you of course :-)

+------+    +-------+   +-------+   +-------+   +-------+   +----------+
| Home | -  | RoamA | - | RoamB | - | RoamC | - | Visit | - | VisitNAS |
+------+    +-------+   +-------+   +-------+   +-------+   +----------+

My best estimation of how this would work was simply to specify a generic 
state attribute.. Dynamic-Proxy-State and call it a day.

Any administrative domain (RoamA-C or Visit) requiring verification 
injects Dynamic-Proxy-State into Access-Request.

Dynamic Auth Clients are required to forward this information when issuing 
DM/CoA requests.

Any admin domain in the path requiring verification then checks 
Dynamic-Proxy-State.. ideally at the border (RoamA) where the identity of 
sender is well established but intra-domain implementations can coordinate 
however they want.  If attribute is missing but required and triplet of 
proxy state, identity and session identifiers of request do not add up the 
request is rejected.

It would have the following general properties:

- Injectable by anyone in proxy path via Access-Request .. "0+"
-- Ideally once per admin domain implying some form of implementation 
dependant Intra-domain coordination.

- DACs must transmit ALL Dynamic-Proxy-State atttributes from access 
request.
- Recommendations to keep size and number of Dynamic-Proxy-State 
attributes as low as possible but specify no cutoff or required minimum.

This is basically it.. implementations can do whatever they want to 
implement it... They can keep a state table or stuff the attribute with 
source, session identifying hints, cryptographic signatures and not have 
to keep much of any state at all.

It should provide general advice on design options, tradeoffs, 
recommendations and perils of which I'm sure we call all dream up plenty.

I prefer a solution that does not depend on keeping secrets.. Even if 
competitors sniffed out Dynamic-Proxy-State from my wires and know all of 
the session identifiers for my customers it would be preferable if 
re-injecting this information (often sent in the clear right now): not 
yield fruit.

regards,
Peter