[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Hi,
On Fri, Sep 09, 2005 at 07:08:10PM -0400, Alan DeKok wrote:
> 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.
The NAS should send all it has, unless there are definitive reasons not
to.
You have other options than enabling information sets per individual
authentication. You can either
1. configure the included information set statically, at the NAS.
2. if you want to use a different set per upstream proxy or home AAA,
have the NAS send all and filter the set at the local proxy.
3. if you really, really need a different set per individual user,
then you need a challenge, for which the following applies.
> > 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.
Are you sure?
The only case is where a NAS must indicate support for a certain
attribute, is when that support is a prerequisite in the home AAA's
policy for an access accept.
And the only way for the home AAA to obtain that information sure enough
for a reject is a change in NAS implementations.
And the simplest change at the NAS is to actually start using the hints
mechanism.
Keep in mind that making a NAS answer challenges with that information
is also a change. The hint is a smaller change and more efficient.
> > 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.
Why isn't the hints mechanism enough?
If you need to reject every NAS that does not yet implement ack/nak to
tell you about its support for an attribute, you can as well reject
every NAS that does not implement the hint.
In both cases you need a change at the NAS. The process and migration
problems are exactly the same.
If the hints seem inefficient because you only need to test the
attribute's presence, consider a bitmap to compress them.
> 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.)
Capabilities is a bit vague. You mean that there can be standard
attributes where a home AAA would want to make his accept conditional on
the range of values that the NAS would act upon?
I say a NAS can only be compliant with the standard that specifies a
session-limiting attribute if it implements all values that make sense
in the context.
Remember that this whole mechanism only makes sense for attributes or
values that limit a user's session in some way.
I don't see a need to make this more fine grained than the attribute
level.
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/>