Re: Capabilities: Summary

["Alan DeKok" <aland@ox.org>]

"Avi Lior" <avi@bridgewatersystems.com> wrote:
> First, cap-advert is a way for the NAS to indicate to the server
> what features it supports so the Server can return attribs to the
> NAS and be assured that the NAS won't discard them.  This has
> nothing to do with challenge or the auth scheme.

  I agree.

> Second the chalange issue does not arise from the cap-advert.  In
> one particular instance it arises from the way geopriv set up their
> location exchange.  That is, not sending the location info on the
> original access request.  Here the cap-advert helps the protocol by
> informing the server that the NAS supports location (and challenge)
> so that the server that requires (or needs) location does not
> challenge a nas that doesn't support location and/or a challenge.

  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?

  Alan DeKok.

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