Re: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )

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

Emile van Bergen <openradius-radextwg@e-advies.nl> wrote:
> >   I would also expect that NASes will *not* want to send all of the
> > available information for all capabilities.  
> 
> Seriously though, if that's information that's actually relevant at
> authentication time, ie. required to determine the level of access, why
> not?

  The NAS may not know it's required for authentication, so the NAS
may not send it.

> If it's efficiency, extra round trips and extra state are far more
> costly than a few more bytes in an access request.

  Yes.

> The only purpose I see for any sort of capability advertising in RADIUS
> is that a NAS can tell in advance that it will act on an authorization
> attribute.

  For extensions to RADIUS (i.e. NAS is required to properly use
attribute FOO in Access-Accept), the only way to ensure correctness is
some kind of extended capability ACK/NAK.  This was discussed
previously.

> Normally the value is used as a hint for the response, but it also tells
> the server that the NAS knows about the attribute. It does not seem a
> big change to specify that the NAS MUST NOT include hints in access
> requests for attributes that it does not support in access accepts.

  Sure.  But most NASes already don't include hints.  So using the
lack of hints as information is inappropriate.

> If even that's is too much to ask, and you want to transport the list of
> supported attributes in a slightly more compressed way, I suggest a
> variable length bitmap, where each numbered bit from LSB to MSB conveys
> the supported status ('NAS will heed') of the correspondingly numbered
> IANA attribute. But you'd need similar language anyway ("Do not set the
> bit unless you actually intend to honor the attribute").

  That makes sense.  But you still need an extended ACK/NAK to ensure
that the RADIUS server knows the NAS will enforce it.

  And you will need something else for values.  e.g. Service-Type FOO
is supported, but Service-Type BAR is not.  (That example doesn't make
sense for Service-Type, but it may make sense for other capabilities.)

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