Re: [Isms] charter proposal user-group mapping

["Tom Petch" <nwnetworks at dial.pipex.com>]

<below>
Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <j.schoenwaelder at iu-bremen.de>
To: "David B Harrington" <ietfdbh at comcast.net>
Cc: <isms at ietf.org>
Sent: Tuesday, August 02, 2005 9:36 PM
Subject: Re: [Isms] charter proposal


> On Tue, Aug 02, 2005 at 01:21:02PM -0400, David B Harrington wrote:
>
> > From my limited experince looking at the problem,
> >
> > If we start to discuss HOW the SSH will support AAA, then we will need
> > to discuss
> > 1) which AAA protocol?
> > 2) which AAA attributes contain the authorization information
> > 2a) should we use filterID, which is supposed to be for packet
> > filtering, not policy management
> > 2b) should we define a new standard attribute for this purpose, since
> > the only attributes available don't provide the granularity we need?
> > 2c) should vendors develop their own VSAs to provide this granularity?
> > 3) will we standardize the naming mechanisms for ACM policies?
> > 4) will we support user-to-group mappings or user-to-policy mappings
> > (i.e. non-group policies)?
> >
> > And so on....
>
> If all these questions do not have a well established clear answer,
> then I guess I misunderstood those who said that user->group mapping
> is something we have to do via AAA because it is widely used
> elsewhere.
>
> /js

I have said that the user-group mapping needs removing from the 'agent' as a
task the administrators have to perform in order to maintain security, else I
believe isms will not meet its objectives.

In one, rather large, marketplace, I see this model (framework? architecture?)
done in a proprietary manner, using Windows Active Directory (which uses
Kerberos, but I don't know in what way).

So an end user logs onto a server running an SNMP Command Generator, is
authenticated and as part of that, the security server specifies authorisations,
access permissions, rights etc which are mostly defined by being a member of a
group.  The Command Generator now has everything the Command Responder needs to
know and so passes it, end user identity plus group membership, to the Command
Responder in a secure manner (ssh transport, security parameters, authenticated,
with
integrity) which uses it to access the access control rules.

Obviously this does not yet exist for SNMPv3 but there are parallels for other
aspects of network management.  Again, I have no brief for those who would
implement such code but if we provide the protocol, I believe it is a simple
step forward.

Likewise, my knowledge of standards-based systems leads me to believe that this
could be done with them (although not necessarily with all of them).

I do believe that retrieving the group membership at the time the SNMPv3
principal is authenticated is the key function and that everything else needs to
stem from it.  As dbh's query elicited, these servers are stateless.  I also
believe that the Command Generator is the place to do it because of the (small)
numbers of them, the power of these platforms, the rich range of services that
already exist on them.  Doing it from an entry level router does not seem so
attractive.

Tom Petch



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