Re: Capabilities: Moving forward

[Emile van Bergen <openradius-radextwg@e-advies.nl>]

Bernard, others,

On Mon, Oct 17, 2005 at 09:14:15PM -0700, Bernard Aboba wrote:

> After dozens and dozens of messages, there is very little to show for the 
> discussion of Capabilities Solutions, so it's time to take a step backward 
> and focus for a while on The Problem.  Let's all take a breather from 
> solution discussions for a while.
> 
> I'd note that we've taken this approach before in RADEXT WG, with 
> encouraging results.  Discussion on the CUI document seemed hopelessly 
> wedged until we were able to focus on the problem statement, which turned 
> out to be relatively straight forward.
> 
> A good problem statement is not just the union of all possible needs;  
> shopping lists make poor design documents.   Rather, a good problem 
> statement seeks to get at the one or two core issues, which, if addressed, 
> will enable solution of mutiple important problems.
> 
> As a result, the goal in coming up with a problem statement is not to 
> enumerate every possible corner condition and scenario, regardless of 
> relevance;  doing so will merely drive the development of as complex and 
> unwieldly a solution as possible.
> 
> Rather, the hallmark of a good problem statement is brevity, leading to 
> solutions which do what is necessary and little more.

This is an excellent idea, and I'd be happy to provide a kickoff. 

From the earlier exchanges here, I see two non-imaginary problems for
which a form of capabilities advertising has been proposed. 

1. A NAS may withhold information required for proper authorization from
   its access requests, because it is only allowed to provide that
   information after some indication from the server.

   (Case in point: GEOPRIV, where a NAS is only allowed to provide
   Location information if the RADIUS server indicates that the user
   allows that information to be transmitted; at all, or specifically
   from the specific NAS, RADIUS client or combination thereof).

   The problem is that a server that intends to make its response
   dependent on the initially withheld information cannot
   unconditionally challenge the NAS for it.

   (Note that this scenario only applies if the server's response to the
   Access-Request packet is in any way dependent on the information
   that's initially withheld. If only the sending of the information in
   accounting requests is to be controlled, the indication to allow
   sending it can simply be put in the Access-Accept).

   The rationale for a capabilities advertising capability in this
   scenario is as follows:

   - A server needs to know in advance how the NAS will respond to a
     for the withheld information, because a NAS may not support
     challenges, causing premature rejection of the user per RFC 2685
     section 4.4 ([44]), or it may misunderstand the reason for the
     challenge, causing other unintended behaviour.

     To expand on this, according to [44], a NAS that supports PAP but
     that is not willing or able to forward the challenge in the of
     Reply-Message to the user, MUST treat the Access-Challenge as an
     Access-Reject. A NAS that supports classic challenges for PAP
     requests to implement one time passwords, would effectively forward
     the challenge to the user, which is not intended here.

   The required semantics for a capability advertisement capability in
   this scenario is that a NAS indicates:

     a. that it supports a challenge for withheld information, using
        a mutually understood mechanism for the server to identify the
	wanted information (eg. GEOPRIV information)

     b. the list of withheld information elements (eg. GEOPRIV Location
	attributes) -- it makes no sense to create this capability for
	one feature alone. (But on the other hand, I cannot think of any
	other case that desires that the NAS withholds available
	information from its initial access request).

2. The second problem: some server policies require an Access-Accept
   conditional on the NAS' support for certain session limiting
   attributes, and on the proxy chain's transparency for them.

   If the NAS and/or proxy chain are in an administrative domain that's
   different from the home AAA's, the home AAA has no way of knowing
   whether the NAS will implement a given session limit. 
   
   This is a real world problem that I've had to deal with (if you're
   curious: the limited EUNet self-subscription accounts on Nokia 9110
   communicators that would allow access through a large number of 3rd
   party dialup POPs, but only to access one particular web server. Ah,
   those were the days).

   Current examples of such session limiting attributes are packet
   filtering (Filter-Id and the new ones), bandwidth control (TBD), and
   volume capping attributes (currently vendor specific).

   An somewhat extensive analysis of this case has been posted earlier.

   The core issue here is that a response attribute filtering proxy
   must modify the NAS' advertisement in order for the advertisement to
   be correct when it is received by the home server.

   If advertising is be done using the well understood hints mechanism,
   response attribute filtering proxies are be required to reflect that
   in their request attribute filtering as well.

   The problem with that is that some attributes that a proxy may wish
   to filter from responses, cannot be filtered from Access-Requests.
   The most prominent case is User-Name, which may be present in
   responses to ask the NAS to change the User-Name to be used in
   accounting requests for the session. Many NASes support this, and
   some roaming contracts such as WISPr even require it. CUI or better
   use of Class may obsolete that practice, but both contracts with
   User-Name overwriting and NASes without CUI still exist.

   One point to add is that in the case of a server requiring certain
   Filter-Ids with certain names to be present, both the namespace
   (defining a name to semantics mapping) and the list of names will
   have to be advertised, in order for a NAS advertising its support for
   Filter-Id to be of any use.

   Modern server defined packet filters may be less problematic in this
   respect, but the advertising of values in addition to attributes may
   be required for other cases as well. A proposed mechanism should have
   provisions for that where that's required. It does not have to be
   complex, the hints mechanism eg. already allows a list of values to
   be sent by virtue of it using standard response A/V pairs in access
   requests.

Of course, a well mapped migration path is crucial for capabilities
advertising to offer any help in solving either of these problems, and
some of the proposals seem to assume a magic big bang update.

I hope that was brief enough. It would be great if followup posts would
tell me whether I've missed a real problem or whether I'm stating either
of the two incorrectly.

Best regards,


Emile van Bergen.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>