Subject: RE: [Isms] Re: securityName/groupName

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 23 Aug 2005 10:00:11 -0700

David,

My probably controversial viewpoint is that if RADIUS is being used for
SNMP authentication and authorization by ISMS, then that means that
RADIUS *replaces* SNMP authentication/authorization across the board.
Specifically, SNMP shall not be able to use SET or any other provision
to modify RADIUS authentication/authorization or to "tune" it for SNMP
usage. Rather, any tuning must be done at RADIUS itself, otherwise it
would be possible for SNMP authentication/authorization to get out of
synch with RADIUS authentication/authorization, which gives "the bad
guys" lots of opportunity to do damage. (Note: bad guys needn't be
crackers, it could also be careless local managers.)

--Eric

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Tuesday, August 23, 2005 9:22 AM
To: [email-masked]
Subject: RE: [Isms] Re: securityName/groupName

Hi,

I agree that the SNMP architectural changes required to accomodate
transport mapping security models (for message authentication and
encryption, and presumably user authentication) are separate from the
SNMP architectural changes or features to support new securityName to
groupName mappings (for authorization).

Recognize that with a AAA architecture like that used for RADIUS, that
the authentication and authorization features are bound together,
deliberately for security-binding reasons. Therefore it may be difficult
for SNMP to separate the authentication and authorization specifications
when using RADIUS or other protocols that require such bindings.

I have a question. The vacmSecurityToGroupTable can be populated by
multiple means - SNMP, RADIUS, CLI, etc. Should the Table have a column
that identifies how each row was configured? Should the Table have a
column that identifies for which session the binding is applicable?

Here's why I ask. Assume I could SET a user-to-group mapping "dbh:root"
in the vacmSecurityToGroupTable, possibly using the netconf interface,
which doesn't yet support access control. Then I send SNMP messages
using the SSH/RADIUS security model, and it populates the table from
RADIUS with user-to-group mappings of "dbh:operator" and "dbh:helpdesk".
When RADIUS authenticated dbh, it explicitly did NOT send attributes
mapping "dbh:root" because dbh should not have root privileges. Will dbh
be allowed to perform SNMP operations as a member of the "root" group?

The Access-Accept message has bindings between the authenticated entity
and the (proposed) attributes it sends for mapping to groups for that
authenticated session. How do we maintain the RADIUS bindings without
causing bindings between the SNMP authentication and access control
models?

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder
> Sent: Tuesday, August 23, 2005 3:55 AM
> To: Blumenthal, Uri
> Cc: [email-masked]
> Subject: Re: [Isms] Re: securityName/groupName
> 
> On Tue, Aug 23, 2005 at 03:26:14AM -0400, Blumenthal, Uri wrote:
> 
> > 2. Mapping of securityName to groupName is required as VACM is 
> > group-based. Thus *some* piece of the new architecture must
> provide that
> > mapping.
> 
> Just to be clear about this: The securityName to groupName mapping 
> does exist as part of VACM today and a new security model would work 
> just fine with it. Since people find this mapping difficult to 
> maintain, there is obviously interest to relevant VACM mapping table 
> entries on the fly as part of the authentication exchange with an
AAA
> server.
> 
> In fact, I believe that an SSH security model can work with local 
> accounts and the existing local securityName to groupName mapping
and
> should allow this option. In addition, there should be a RADIUS 
> interface which allows to replace local account authentication with 
> RADIUS authentication and this might provide in addition VACM
mapping
> table entries.
> 
> I do not think that the architectural changes required to accomodate 
> transport mapping security models automatically call for
architectural
> changes or features to support new securityName to groupName
mappings.
> (In fact, I believe that a group is a VACM only concept that does
not
> really exist in the SNMPv3 architecture per se.)
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> 
> _______________________________________________
> Isms mailing list
> [email-masked] https://www1.ietf.org/mailman/listinfo/isms
> 

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 23 Aug 2005 13:56:29 -0400

Hi Eric,

I don't think that's controversial at all. I think if we're going to
provide a user-to-group mapping based on RADIUS attributes, we need to
provide a binding between the authentication session and the
authorization.

dbh

> From: Fleischman, Eric [mailto:[email-masked]] 
> Sent: Tuesday, August 23, 2005 1:00 PM
> To: [email-masked]; [email-masked]