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

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 23 Aug 2005 03:26:14 -0400

1. SecurityName is required to identify the principal in a security
model-independent way. Thus mapping from model-specific to
model-independent name is needed.

2. Mapping of securityName to groupName is required as VACM is
group-based. Thus *some* piece of the new architecture must provide that
mapping.

3. Roles are similar enough to groups, that groups should be usable for
role-based management.

So I prefer that both securityName and groupName became "mapped" after
NewSM is done processing the request.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David B Harrington
Sent: Monday, August 22, 2005 12:42 PM
To: 'Sam Hartman'; 'Juergen Quittek'
Cc: [email-masked]
Subject: RE: [Isms] Re: securityName/groupName

Hi Sam,

The mapping from a model-specific identity to a securityName is
model-specific by definition. There are issues associated with using
securityName in a manner that loses granularity. If the remapping is
done within the security model and the security model addresses those
issues adequately, I see no problem. If the remapping is done inside
the ACM model and the ACM addresses these issues adeqautely, I see no
problem. 

I think remapping securityName instead of groupName is fine to keep as
an option, but I definitely prefer a groupName mapping to overloading
securityName.

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sam Hartman
> Sent: Sunday, August 21, 2005 10:32 PM
> To: Juergen Quittek
> Cc: [email-masked]
> Subject: [Isms] Re: securityName/groupName
> 
> >>>>> "Juergen" == Juergen Quittek <[email-masked]> writes:
> 
>     Juergen> Woul it be acceptable for everybody if we replaced
>     Juergen> "securityName and groupName" with "securityName and
other
>     Juergen> SNMP parameters"?
> 
> 
> I'm a bit concerned about over-broad wording.  Wording so broad that
> redefining VACM was inc scope is clearly too broad.  Also, is there
> anyone who supports remapping securityname instead of the group
name?
> I am concerned that I may have accidentally given support to a
> specific proposal when what I cared about was giving support to
> solving a generic problem without supporting a specific solution.
> 
> 
> 
> _______________________________________________
> 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: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Aug 2005 09:54:58 +0200

> group-based. Thus *some* piece of the new architecture must provide that

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

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 23 Aug 2005 12:21:43 -0400

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]

> [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
>

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 23 Aug 2005 10:29:41 -0700

Hi David,

First of all we are talking about two different security models
and hence the user "dbh" within the USM is different from
the user "dbh" on the RADIUS server. They are different
name spaces.

Now coming to authorization, I still believe that the cleanest
model is to use the RADIUS attribute to refer to a VACM
group. This way the RADIUS server is never assigning
permissions for SNMP but primarily describing membership.
The permission assignment happens via the mapping of the
group to the view on the SNMP engine, this way the VACM
permission model stays the same irrespective of whether you
use USM or ISMS.

regards,
   kaushik!

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 23 Aug 2005 14:57:49 -0400

Hi Kaushik,

1) I'm sorry my shorthand distracted you.

I understand USM and RADIUS are different namespaces. But the WG is
talking about populatng the vacmSecurityToGroupTable, so the USM and
RADIUS elements get translated into one namespace - the vacm namespace
of vacmSecurityModel/vacmSecurityname and vacmGroupName.

2) The VACM Elements of Procedure (RFC 3415 section 3) utilize the
vacmSecurityToGroupTable. So unless we choose to modify VACM, it
appears that populating the vacmSecurityToGroupTable behind the scenes
is the simplest approach from a documentation perspective (but I
personally dislike it because I think it muddies the architectural
separation of the subsystems and the models, and ties the solution to
the VACM-specific access control model).

So the question remains, if the vacmSecurityToGroupTable can be
populated by multiple means, do we need to modify the table to
recognize how each row was populated? By which session? AAA-server?
Server-type? Etc.

When do the rows get deleted from the table? Which subsystem has that
responsibility? Should each row have an "expiration" parameter?

Should the document that describes how to do this
RADIUS-to-VacmSecurityToGroupTable mapping define a MIB module that
extends the snmpVacmMIB to contain these extra columns?

3) We can use RADIUS attributes to refer to a vacm group, but if the
security subsystem gets the info, then it needs to pass it to the ACM
subsystem. Populating the vacmSecurityToGroupTable behind the scenes
is one approach (the "magic happens" approach). 

I have suggested an alternate approach that passes a list of
"groupnames" in an additional parameter of the ASI. Then VACM *or any
other ACM model* can use the info, if desired. Passing it as a
parameter ensures that the groups are specific to the session, and
maintains the binding between the authentication/authorization for the
session.

4) If we move the user-to-**group** mapping outside of the ACM
subsystem, then we'll force all future models to use a group
membership concept for ACM. I personally don't think we should force
all future models of ACM to be based on a group-membership approach to
access; there were segments of the SNMPv3 WG that did not want groups,
but had other approaches they wanted to be able to use. VACM happened
to use groups, and the user-to-group mapping is within the snmpVacmMIB
because the decision to use groups is meant to be VACM-specific. I
prefer to not use "group" in our choice of words.

David Harrington
[email-masked]

> From: Kaushik Narayan [mailto:[email-masked]] 
> Sent: Tuesday, August 23, 2005 1:30 PM
> To: [email-masked]
> Cc: [email-masked]
> > > entries on the fly as part of the authentication exchange with
an
> >AAA
> > > accounts and the existing local securityName to groupName
mapping
> >and
> > > (In fact, I believe that a group is a VACM only concept that
does
> >not

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Aug 2005 21:50:25 +0200

> have a column that identifies for which session the binding is

Yes, I think such an augmentation would be useful/needed if we go down
this path.

/js

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 23 Aug 2005 13:29:53 -0700

Hi David,

I think updating the vacmSecurityToGroupTable behind the scenes
would not be a good idea since this would actually become part of the
configuration of the SNMP engine. The groupName would be passed
down from the RADIUS server for every session so I would consider
part of the session state and not really long term configuration.

I think it would be preferable that would an additional parameter to
the ASI.

regards,
   kaushik!

---

From: Sam Hartman <[email-masked]>
Date: Wed, 24 Aug 2005 13:45:28 -0400

>>>>> "David" == David B Harrington <[email-masked]> writes:

    David> So the question remains, if the vacmSecurityToGroupTable
    David> can be populated by multiple means, do we need to modify
    David> the table to recognize how each row was populated? By which
    David> session? AAA-server?  Server-type? Etc.

If you are going to modify VACM at all then please do something that
you believe is an architecturally consistent and reasonable solution.
I will point out that there are scope issues as to whether it is
appropriate for us to modify VACM.  However there is a compelling
argument that if we don't fix the group mapping problem, ISMS is not
all that useful.

In decreasing order of preference from my standpoint:

1) Find some clean way of not modifying VACM

2) Modify VACM to allow alternate soruces of group mapping in an architecturally reasonable manner.

3) Modify the VACM table behind the scenes possibly adding book
   keeping.  I dislike this approach because it sounds like specifying
   things that should be implementation matters.  This is particularly
   bad because it will force implementation decisions that complicate
   the implementation and lead to non-ideal behavior.

--Sam

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 24 Aug 2005 17:14:53 -0400

Hi,

I think #1 can be achieved by describing in an ISMS security model how
the vacmSecurityToGroupTable gets populated by additional sources, and
augmenting the VACM MIB module with source information; this info can
also provide the information necessary to delete session-specific rows
when the session closes. 

There are two major architectural problems with this approach - it is
totally dependent on VACM being the only ACM model the solution will
work with, and any security model that utilizes AAA to populate the
table creates dependencies between specific models in the security
subsystem and specific models in the AC subsystem. That is contrary to
the RFC3411 architectural philosophy.

I think #2 can be achieved by using an architectural extension. This
"authorization" extension to the security subsystem would describe
gathering a grouplist/filterlist from a (generic) authorization
server, and then passing the grouplist/filterlist through the
intermediate ASIs to the access control subsystem (to any/all access
control models). 

If the grouplist is message-based, an ACM model can work directly from
the grouplist.
If the grouplist is session-based, then we need to identify whether
the security subsystem caches the authorization info and passes it
with each message, or a lookup token, and whether ACM models should
use the grouplist directly or copy the grouplist into local tables,
and how ACM models that copy the info into their own local tables
avoid populating duplicate information for the same session, and how
access control models know of the end of the life of the session, so
any created entries in local tables can be deleted. I believe the best
approach is to have ACM models not copy the grouplist into local
tables.

An example appendix could show how this architectural extension can be
implemented with RADIUS as the authorization server protocol. We will
need to nail down which attributes are to be used. Realize that if we
develop this based on the management attributes in RADEXT, that no
current RADIUS server supports them (to my knowledge). If this
appendix would be large, it would probably be better as a separate
document, but I think most of the issues will actually be covered by
the architectural extension.

A Co-existence appendix could describe how to apply this in a
backwards-compatible way to VACM, as defined in RFC 3415, possibly by
having the vacmSecurityToGroupTable populated from the grouplist, but
then we need to address how to handle sessions and data lifetime. It
would probably be better to specify that VACM should use the passed
grouplist directly rather than the vacmSecurityToGroupTable. Using a
co-existence document would be consistent with the SNMPv1/v2/v3
Coexistence document, where we avoided redefining SNMPv1 and SNMPv2
documents by providing a coexistence document (RFC 3584).

I have concerns with #3 because either we specify how this is done,
which might violate the standard vs. implementation threshold, or we
don't specify it, which could lead to ambiguity and interoperability
issues. 

If others believe #3 is a viable approach, I'd like to see a concrete
(or at least partially-hardened) proposal so we can determine whether
this can be implementation-independent and unambiguous.

David Harrington
[email-masked]

> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Wednesday, August 24, 2005 1:45 PM
> To: [email-masked]
> Cc: 'Kaushik Narayan'; [email-masked]