Re: [Isms] SNMP "access control" terminology

On Sun, Jul 02, 2006 at 10:40:02PM -0700, Randy Presuhn wrote:

> > From: "Juergen Schoenwaelder" <j.schoenwaelder@iu-bremen.de>
> > To: <isms@ietf.org>
> > Sent: Sunday, July 02, 2006 1:14 PM
> > Subject: Re: [Isms] SNMP "access control" terminology
> ...
> > > So how do you think snmpCommunityTransportTag as defined in RFC 3587
> > > fits into the picture? I believe this object does authorization by
> > > matching IP addresses. And the way it is described, this happens in
> > > the message processing model (processIncomingMsg ASI, see RFC 3587
> > > section 5.2.1). Perhaps this RFC is wrong according to the
> > > architecture (or is the architecture wrong? ;-)
> > > 
> > > You like to see authorization in the ACM. I think authorization does
> > > not really exist as a concept - except perhaps in RFC 3587.
> > 
> > I got the RFC number wrong - I was referring to RFC 3584 and not RFC
> > 3587. Sorry for the confusion.
> ...
> 
> The function of snmpCommunityTransportTag is to to provide a bridge
> of sorts between the SNMPv1/SNMPv2c world and the SNMPv3 world.
> That it might exhibit some discrepancies from the SNMPv3 architecture
> is not surprising, given that it processes incompatible message wrappers.

Sure. But the point is that (a) a clean architecture and the real
world must align reasonably well to be useful and (b) that I consider
this IP address filtering in the community-based security model as a
kind of authorization step. You simply don't get into the SNMP engine
if this authorization step fails, regardless what VACM later on would
allow or disallow.

While having no authorization and having no access right might
practically mean the same thing, they are still different in terms of
how far you get into the system and so far I always considered
authorization as something that happens at the entrance. Once you have
passed authorization and you are inside, access control controls what
you can do.

While I might be wrong with my world model, I see the following
potential three usages of RADIUS in an ISMS environment:

a) authentication backend for password/keyboard-interactive
   (transparent for ISMS as far as I can tell, easy)

b) authorization (once authenticated)
   (easy when you use RADIUS for authentication, difficult when you
   use public keys or kerberos since in this case authorization is
   different from authentication and RADIUS does not seem to like
   it (and I still have to understand what the difference between
   RADIUS and DIAMETER is in this aspect since the later seems to
   like it better))

c) mapping of security names to group names (roles)
   (requires to call radius within VACM or cached information must be
   passed to VACM from somewhere, requires to work out how such
   dynamic information coexists with provisioned VACM security to
   group mappings)

I think this is what <draft-narayan-isms-sshsm-radius-00.txt>
discusses.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms