Re: Capabilities: Summary - refined proposal

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

Alan,

On Wed, Oct 12, 2005 at 07:50:36PM -0400, Alan DeKok wrote:

>   The capability being advertised, then, isn't location, but "can
> handled Access-Challenge responses to PAP, CHAP, MSCHAP requests".
> 
>   Once an implementation supports that, any server can challenge the
> client with "hints", as described above.  A possible workflow is:
> 
>   C -> S: Access-Request
> 		User-Name = foo
> 		User-Password = bar
> 		Capability = yes
>   S -> C: Access-Challenge
> 		Require-Location = yes    
> 		State = abcd
>   C -> S: Access-Request
> 		User-Name = foo
> 		User-Password = bar
> 		Capability = yes
> 		location = "moe's tavern"
> 		State = abcd
> 
>   That proposal removes all of the functionality advertisement from
> the capability exchange.  I think the potentially infinite list of "I
> support functionality foo" is the source of the disagreement.
> 
>   In most situations, one party or other other will care about 10% of
> the advertised capabilities, meaning the other 90% are irrelevant.
> And having a potentially infinite list is problematic for
> implementations to manage, to say nothing of IANA.
> 
>   The above proposal should keep all of the capability exchange within
> the current RADIUS data model, and won't require a new bit-array.
> 
>   Comments?  Does this match your needs?

I think this is an excellent idea, but a problem arises where a NAS does
support the 'Capability = Yes' (or more accurately, 'Challenge-Supported
= Yes') scheme, but does not understand the particular cause for the
challenge, which may be given in the challenge by an attribute or value
it does not know about. 

If you create a generic mechanism for NASes to indicate their support
for challenges for more information, then at some point NASes will exist
that support the generic mechanism, but not the particular challenge
cause. In your example, they will send Capability = Yes, but will not
understand the Require-Location attribute and therefore ignore it.

So, the question is what a NAS should do when it is challenged for
something it does not know about or something it does not have for that
particular session. It should definitely not reject, otherwise we're
back to square one.

My suggestion is that instead of a scheme-dependent and potentially
unknown response attribute, a single response attribute must be used to
describe the challenge cause, one that MUST be supported if
Challenge-Supported = Yes is sent.

The semantics for Challenge-Cause would be that *if and only if* a NAS
sent Challenge-Supported, *and* it sees Challenge-Cause *and* it does
not understand its value (eg. Location-Required), the NAS MUST repeat
its initial access request (adding the received State and updating
Authenticator and Id as per RFC 2865, of course), *without prompting the
user*.

This is quite specific, but it only has to be defined in a single
document describing NAS inquiries using these two attributes, and does
not require any retroactively updated behaviour to operate smoothly in a
heterogenous environment.

Note that a NAS that sends Challenge-Supported = Yes cannot always
resend its access request if it does not understand from the response
packet why it was challenged, because it needs to distinguish a
challenge for information it does not have (resend as-is) from a classic
one time password challenge (prompt user first). Hence Challenge-Cause.
It also helps debugging by server administrators, I guess.

When seeing State in an authentication request that still lacks the
wanted information, the server can conclude that it won't get anymore
information than it just got, and that it will have to make its decision
based on what it has (modulo unfinished EAP conversations, of course).

The server will only have to be careful to avoid sending a challenge for
the missing information if the presence of State indicates that the
challenge has already been done, to prevent endless ping-pongs.

However, I think that with this addition, your idea completely solves
the 'unknown NAS may withhold needed information' issue as present in
GEOPRIV, and also paves an excellent way for future authentication or
authorisation schemes that require tentative challenges.

Cheers,


Emile.

-- 
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/>