Re: [Isms] Moving into some design /architectureissuesofExtendedVACM

[Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>]

On Thu, Jun 11, 2009 at 03:28:34PM +0200, Dave Nelson wrote:
> Randy Presuhn writes...
> 
> > I think the disadvantage is that of introducing yet another special case.
> > There is no way to tell the difference between "useless," "eroneous,"
> > and "I got there before the configuration updated was pushed to that
> > particular node."  (Operationally, the user-group mapping will go out
> > before there is any guarantee that all nodes for which that policy will
> > be relevant have been updated to include that policy in their repertoire.)
> > 
> > If we distinguish this case with special handling and counters, do we want
> > to propagate an error back to RADIUS-land?  (We have no mechanism for
> > delivering any special indication to the SNMP conversation partner.) What
> > is the recovery strategy upon receipt of this error, and is it any
> > different from any other access-denied situation?
> 
> All good questions.  We do need to define behavior for all the corner cases
> as part of this effort.

No, the behaviour is already defined in VACM. Just be happy with what
it does and the lets move on. ;-)

> If there is a mismatch in policy/group names between the RADIUS server and
> the network devices, users will get authenticated, an SNMP session will
> start, e.g. over SSH, but the VACM will not provide any access to MIB
> objects.  Is there an SNMP-level error message that will inform the user
> where the problem lies?

According to RFC 3413 section 3.2. (page 11), I think this should
result in an authorizationError.

But more important: SNMP has defined ways to handle this situation,
which can occur due to manual mis-configuration of VACM tables. It
should not make any difference whether the "broken" group name was
manually configured or installed by a RADIUS client.

But there are some interesting questions to work out: What is the
behaviour if a RADIUS client receives a policy attributes but the
vacmSecurityToGroupTable has already a (different) entry for the
(securityModel, securityName) tuple? Who wins in this situation - or
does this even cause the authentication of the incoming request to
fail? What happens if no new entries can be created anymore due to
resource limitations? These are examples of new error situations
that we have to deal with.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>