[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Hints and End-to-End capabilities
Hi,
Sorry for replying to my own post yet again, hopefully you'll consider
this addition worthwhile, since we're drifting in the general direction
of another capabilities effort:
http://www.watersprings.org/pub/id/draft-lior-radext-end-to-end-caps-01.txt
On Fri, Sep 09, 2005 at 11:58:16PM +0200, Emile van Bergen wrote:
> 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.
>
> Most prominent example (and a real world one I had to deal with): if a
> NAS does not support IP filtering attributes, it's allowed to ignore
> them (like any other attribute), while the home AAA would want to make
> its accept/reject decision conditional on whether or not the NAS will
> actually apply the filter.
>
> But at the RADIUS level, we already have a mechanism for that: the
> inclusion of the relevant response attribute, possibly with a dummy or
> null value, in the access request.
>
> 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.
>
> 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").
Other than backwards compatibility, the hints mechanism has another
advantage: it can allow the home AAA to discover the capabilities of the
whole chain, because proxies can, and often unintendedly do, indicate
their policies with respect to response attribute filtering by
performing request attribute filtering in the same way.
However, there are cases it may be undesireable for a proxy to filter an
attribute from a request that it does intend to filter from any
response. Attributes that are required in access requests or that only
make sense in those will be among them.
The most prominent example is User-Name, even: no NAS can leave it out,
and no proxy can filter it from the request, but both may want to
indicate that they do not support User-Name overwriting (a deprecated,
pre-Chargable-User-Identity practice, granted, but it may be a condition
for an accept in older deployments. It's also in some roaming contracts
that won't expire for a while).
Looking at all that, the dedicated bitmap attribute seems better: the
proxy can clear bits that correspond to attributes it doesn't allow the
home AAA to set, without filtering required request attributes.
On the other hand, there will be proxies that will filter response
attributes but that do not (yet) know about the NAS-will-heed-bitmap.
And those will still cause access accepts to be received by the NAS that
are less restricted than the home AAA intended them to be.
I plan to file a proposal that's an alternative to Avi Lior's End-to-End
capabilities document, based on clear and pure per-attribute 'NAS will
heed' semantics, however transmitted, with proxies required to indicate
their filtering policy, and aimed primarily at response attributes that
function to limit to user's session.
I would appreciate to hear though it if people think I would waste my
time because Lior's approach is better, and whether you have a
preference towards the hints or bitmap approach, if any, especially
considering existing filtering practice and behaviour in a heterogenous
network of NASes and proxies.
I'll then research the situation wrt. request attributes that cannot or
should not be filtered from the request but are routinely filtered from
responses. I think what's best ultimately depends on the number of
attributes that are routinely used in both requests and replies, the
number of optional-but-limiting attributes among them, and existing
practice with respect to filtering in either direction.
At any rate, I think that 'NAS-through-proxies-will-obey-attribute-X'
advertisements are the only capability advertisements that really add
something to the protocol. The home server may want to know what the
NASes plans are with the session limiting attributes it intends to send
in its Access Accept before sending it.
Server advertisements, on the other hand, effectively tell the RADIUS
client about part of the server's policy in advance, at the cost of
preauthentications, CoA or caching from other sessions (which is only
possible if the advertisement is home AAA wide in scope), and the NAS
applying part of the policy, without too much benefit.
The whole idea with RADIUS is offloading policy to a central place, by
asking the server about each individual session that's about to take
place. And you only even get to see a user's policy if you supply that
user's credentials. No pushing or publishing of parts of it up front.
That's an aspect of RADIUS that should remain unchanged, I think. It
makes security analysis so much easier.
Kind regards,
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/>