Subject: [Isms] FW: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS

From: "David B Harrington" <[email-masked]>
Date: Wed, 10 Jun 2009 05:53:59 -0400

Hi,

Randy Presuhn described it best. The simplest way to approach this
problem is to have the RADIUS authorization attributes simply there in
the background. Screw the ASIs; we want to finish this within five
years. A RADIUS-aware ACM can simply utilize the RADIUS attributes.

My concern is maintaining the modularity that was deliberately created
by the SNMPv3 WG to allow modular extensibility. This is all about
separating who knows what. RADIUS knows about authorization
attributes, not about VACM.

When the charter says that RADIUS provides VACM username-to-groupname
dynamic provisioning, that is wrong. RADIUS provides a policy name.
How that translates to VACM access control is dependent on the
(extended) VACM access control model. That permits additional access
control models to also utilize the RADIUS attributes.

dbh

> -----Original Message-----
> From: Dave Nelson [mailto:[email-masked]] 
> Sent: Tuesday, June 09, 2009 11:23 PM
> To: 'David B Harrington'; 'Romascanu, Dan (Dan)'; 
> [email-masked]; [email-masked]; [email-masked]
> Cc: 'Juergen Schoenwaelder'; 'Pasi Eronen'
> Subject: RE: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS
> 
> David B Harrington writes...
> 
> > "obtaining VACM authorization information via RADIUS" seems to 
> > violate the modularity of the RFC3411 architecture.
> 
> Well, perhaps it violates the *aspirations* for modularity.  
> It's clear to
> me that the access control decision is encapsulated entirely 
> in the Access
> Control Subsystem.  There is no ASI that allows for the ACS 
> to obtain access
> control guidance from any other subsystem.  We encountered 
> that problem in
> the work ISMS recently completed.  We created a new Transport 
> Subsystem, and
> a "cache" to allow the TS to communicate with the Security 
> Subsystem without
> modifying the existing ASIs.  It's pretty clear, in hind 
> sight, that the
> Security Subsystem design was never sufficiently modular to 
> foresee the
> possibility of the security mechanism being provided outside of that
> subsystem.  Are you suggesting we use the same tactic here?  
> That we create
> a new AAA Subsystem and a "cache" that allows it to 
> communicate with the
> ACS?
> 
> > There should be two steps.
> > 1) obtaining authorization information via RADIUS, using "Remote
> > Authentication Dial-In User Service (RADIUS) Authorization 
> for Network
> > Access Server (NAS) Management". The authorization 
> information should
> > be in an access model independent form, so it can be used with
> > different access control models.
> 
> In other words, we create an AAA Subsystem.
> 
> > If user/groupname bindings can be installed dynamically, even
though
> > the policy (group access) is not provisioned, a new access control
> > model or extension or an implementation might go get the values to
> > dynamically provision the policy details automatically, rather
than
> > requiring operators to preconfigure the access rights for groups
who
> > may never actually need to manage the device.
> 
> Well, such a thing is possible, of course, but in the absence 
> of a specific
> mechanism, simply providing access by default raises real 
> security concerns,
> whether or not it is a matter of local policy.
> 
> > I think it is important to recognize that the SNMPv3 WG
deliberately
> > made the binding mechanism between a principal and the AC policy
the
> > responsibility of the specific AC model. Another AC model 
> might use a
> > different binding mechanism to bind the principal and the
> > RADIUS-provisioned policy name.
> 
> By the same logic, as the binding mechanism *is* the 
> responsibility of a
> specific ACM, who's to say it cannot chose to use RADIUS?  
> What mandates
> that the source of access control information be "modular"?  
> Nothing that I
> see in the current definition of the ACS.
> 
> > RADIUS should supply a model-independent policy name, with no
RADIUS
> > knowledge of how the binding will occur within an AC model.
> 
> Having an AAA Subsystem might be a good thing.  My question 
> is whether it is
> a necessary thing, and whether it would be worth the extra 
> time and effort.
> 
> > The VACM extension should apply that RADIUS-provisioned 
> policy name to
> > the authenticated identity using the VACM-specific 
> username-to-groupname
> > mapping table.
> 
> I think that's exactly what's been proposed.
> 
> 
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 10 Jun 2009 09:41:19 -0700

Hi -

> From: "David B Harrington" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, June 10, 2009 2:53 AM
> Subject: [Isms] FW: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS
...
> years. A RADIUS-aware ACM can simply utilize the RADIUS attributes.
...

Lest I be credited with too much, let me re-cap the idea.  (I do not
claim to be the only person who's thought about it this way!)

(1) the RADIUS  authorization data includes the name of the
group of which this user is an authorized member.  (You can
call it a policy if you will, but to break out of chicken--egg
provisioning problems it must be possible to transform it into
a VACM group name without any prior configuration..)

(2) if one does not already exist, a corresponding entry is created
in the vacmSecurityToGroupTable.

(3) processing continues just like it would for any other transaction.

Details of step (2):
        vacmSecurityModel comes from the security model in use for this message
        vacmSecurityName obvious
        vacmGroupName comes from the RADIUS authorization data
        vacmSecurityToGroupStorageType volatile
        vacmSecurityToGroupStatus  active

If you really want to get fancy, you could AUGMENT  the vacmSecurityToGroupTable
with additional column(s) to make entries created in this manner behave like
elements in a age-out or LRU cache.

I *think* I went through this in more detail in the ancient "miasma" proposal
from the days when ISMS was just getting started.

The only "architectural" issue is that going through step (2) requires the
entity processing the request to be able to act like an SNMP CR application
operating on (rather than merely consulting) the VACM MIB (and possibly
an extension to that MIB).  This does *not* require defining any interfaces
that we don't already have.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jun 2009 19:45:48 +0200

On Wed, Jun 10, 2009 at 06:41:19PM +0200, Randy Presuhn wrote:
 
> If you really want to get fancy, you could AUGMENT the
> vacmSecurityToGroupTable with additional column(s) to make entries
> created in this manner behave like elements in a age-out or LRU
> cache.

I personally believe it should be defined what the lifetime of these
entries are and how they get eliminated.

> that we don't already have.

One way of looking at it. But in general, we do not spell out how our
MIB tables are populated; for me this is just more MIB instrumentation
and it does not matter how it is implemented. When a new OSPF peer
pops up, you also do not expect that an internal SNMP request is being
created to change the MIB tables.

That said, I believe we kind of all agree on the solution and I also
believe it is not really hard to write this up in an initial ID...

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

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 10 Jun 2009 14:15:26 -0400

Randy Presuhn writes...

> a VACM group name without any prior configuration.)

I don't think the "without any prior configuration" part works.  A group
name or policy name, whatever we call it, is just short-hand for a
potentially long list of policy rules or access control rules.  There's no
practical way that the RADIUS server can know what group names exist on the
NAS and what access rights they convey.  That has to be pre-arranged by the
system administrator.  Similarly, there's no way that the NAS can intuit the
correct set of policy rules from the name.  The name, IMHO, must simply be a
label and MUST NOT be encoded with actual access control semantics.
 
> in the vacmSecurityToGroupTable.

That, I think, is a potential security hole that you could drive a whole
fleet of trucks through.  Creating a table entry with some default, null or
wildcard set of access control rules seems like a very bad idea.  It's good
for ease-of-use, but bad for security.

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 10 Jun 2009 11:40:44 -0700

Hi -

> From: "Dave Nelson" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, June 10, 2009 11:15 AM
> Subject: [Isms] Moving into some design / architecture issues of ExtendedVACM
>
> Randy Presuhn writes...
> 

When I talked about "provisioning" I was referring to the SNMP-manageable
system.  The whole point of this exercise is to push as much as practical
(not as much as possible!) into the RADIUS world.  This means that the
group access rights *will* have to be pre-configured.  That's ok.

The point of the ISMS work is to cope with user churn, not policy churn.

> for ease-of-use, but bad for security.

No, look at what the vacmSecurityToGroupTable *does*.
If there is no access control policy in place for a particular group,
then no rights are granted.  I think we very clearly do *NOT* want this
stuff to be messing with anything in VACM other than the
vacmSecurityToGroupTable.  Practically by definition, we trust
the RADIUS server to deliver the correct user->group mapping.
If we can't make that assumption, this whole exercise is pointless.
 
Randy

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 10 Jun 2009 15:09:25 -0400

Randy Preshun writes...

> This means that the group access rights *will* have to be
> pre-configured.

OK.  We're on the same page.

> The point of the ISMS work is to cope with user churn,

Exactly.

> No, look at what the vacmSecurityToGroupTable *does*.

Before dong any drafting of text I *will* need to review the VACM RFC
carefully, or rely on my co-editor for that expertise.

> If there is no access control policy in place for a 
> particular group, then no rights are granted.

OK.  I didn't realize that.

> Practically by definition, we trust the RADIUS server to
> deliver the correct user->group mapping.

Yes, but the NAS's VACM MIB tables and the RADIUS server's database are
configured by human system administrators who can make mistakes.  Sometimes
as simple as a typo error.  If RADIUS authorizes an unknown group name, that
has to be considered a configuration error and the NAS needs to handle it
predictably and securely.

> If we can't make that assumption, this whole exercise

We can assume that when the system is properly configured.  We also design
the system to detect and correctly handle mis-configurations.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 10 Jun 2009 15:16:48 -0400

Hi,

I agree with (what I believe to be) Randy's assessment.
VACM has two major parts:
	1) a binding of user to policy/group
	2) the detailed access controls for a group (views,
permissions, etc.)

I think it is fine for RADIUS to provide a user/policy, and for VACM
to translate that into user/groupname even if there are no entries
specifying the views and permissions for the groupname. The
isAccessAllowed() will simply say "no" for any  group for which no
views/permissions are defined.

Nobody is talking about providing agent-supplied defaults that grant
default permissions to an unrecognized groupname.

So installing the user/group binding alone should be fine. No security
hole that I see.

--

As Randy says, ISMS is trying to address user churn, not policy churn.
The configuration of the policy details within the VACM model can be
done using SNMP (or CLI or netconf or startup files or ...). Once
installed, the policy usually remains unchanged. 

The WG will need to deal with mid-session changes to user/policy
assignments and/or policy configuration changes. Maybe we assume
sessions will short-lived enough not to worry about it, but given the
sensitivity of management access, I think we will need to address
this. IIRC, RADIUS servers can specify "interrupts" - hey, client, I
need to revoke the current access-accept and force you to ask me
again, because some things have changed. 

Hopefully, we will not need to deal with a user changing their group's
permissions in a way that denies them access to the view and
permissions tables they are changing ;-)

dbh

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Randy Presuhn
> Sent: Wednesday, June 10, 2009 2:41 PM
> To: [email-masked]
> Subject: Re: [Isms] Moving into some design / architecture 
> issues ofExtendedVACM
> 
> Hi -
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 10 Jun 2009 15:31:19 -0400

Hi,

Installing a groupname when there are no corresponding views and
permissions entries is not a misconfiguration. From RFC3415:

vacmGroupName    OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The name of the group to which this entry (e.g., the
                 combination of securityModel and securityName)
                 belongs.

                 This groupName is used as index into the
                 vacmAccessTable to select an access control policy.
                 However, a value in this table does not imply that an
                 instance with the value exists in table
vacmAccesTable.
                "
    ::= { vacmSecurityToGroupEntry 3 }

(oh my! we have a misspelling in RFC3415!).

dbh

> Behalf Of Dave Nelson
> Sent: Wednesday, June 10, 2009 3:09 PM
> To: [email-masked]
> issuesofExtendedVACM

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 10 Jun 2009 15:38:17 -0400

David Harrington writes...

> I think it is fine for RADIUS to provide a user/policy,
> and for VACM to translate...

Are we contemplating something other than the "identity transform" here?  If
not, why use the word "translate"?  If so, how is domain-wide correctness
guaranteed?

> ... that into user/groupname even if there are no entries

Yes, I see that.  As the default for a new group entry is no access, there
is no security risk.  OTOH, what's the operational advantage of populating
the tables with useless / erroneous group names?  Conversely, what's the
disadvantage of simply ignoring any non-existing group names, and dismissing
them as a mis-configuration?  You many, of course, want a counter of these
someplace.

> assignments and/or policy configuration changes.

This can be tricky.  One possible solution is for a "significant' have of
policy definition in the NAS to trigger a RADIUS re-authentication request.

> IIRC, RADIUS servers can specify "interrupts" - hey, client, I

You're thinking of Dynamic RADIUS, which allows for changes of
authorization, initiated by the RADIUS server.  Of course, the RADIUS server
isn't likely to be aware of changes in MIB values on the NAS.

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 10 Jun 2009 15:45:19 -0400

> permissions entries is not a misconfiguration.

OK, so "null pointers" in VACM are *not* a mis-configuration.  I wouldn't
have guessed that.  :-)

I suppose it make sense in terms of populating a MIB Module.  Operationally
it seems kind of pointless, though.   Well, no matter.  It's not of
significance to the design, AFAICT.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 10 Jun 2009 17:03:04 -0400

Hi, 

> Sent: Wednesday, June 10, 2009 3:38 PM
> To: [email-masked]
> Subject: Re: [Isms] Moving into some design / 
> architectureissuesofExtendedVACM
> 

I just meant "translate" from attribute format to MIB format, using
the identity transform.

> them as a mis-configuration?  You many, of course, want a 

I think the reasoning was simply that some admins might prefer to
install user/group mappings before they actually do the accesstable.
Some might prefer to do the accessTable first and then the user/group
mapping.

Note that the accessTable also can be populated before the
user-to-groupname entry is defined, even though groupname is part of
the index.

vacmAccessEntry  OBJECT-TYPE
    SYNTAX       VacmAccessEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "An access right configured in the Local Configuration
                 Datastore (LCD) authorizing access to an SNMP
context.

                 Entries in this table can use an instance value for
                 object vacmGroupName even if no entry in table
                 vacmAccessSecurityToGroupTable has a corresponding
                 value for object vacmGroupName.
                "
    INDEX       { vacmGroupName,
                  vacmAccessContextPrefix,
                  vacmAccessSecurityModel,
                  vacmAccessSecurityLevel
                }
    ::= { vacmAccessTable 1 }
> re-authentication request.

Hopefully we won't need to deal with that too much. 

> isn't likely to be aware of changes in MIB values on the NAS.

True, but the server might be aware of admin changes for the
user/group assignments.

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 10 Jun 2009 18:59:00 -0700

Hi -

> Sent: Wednesday, June 10, 2009 12:38 PM
> Subject: Re: [Isms] Moving into some design / architectureissuesofExtendedVACM
...
> them as a mis-configuration?  You many, of course, want a counter of these

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?

Randy

---

From: "Dave Nelson" <[email-masked]>
Date: Thu, 11 Jun 2009 09:28:34 -0400

Randy Presuhn writes...

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

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?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Jun 2009 16:05:45 +0200

> All good questions.  We do need to define behavior for all the corner cases

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

> objects.  Is there an SNMP-level error message that will inform the user

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

---

From: "David Harrington" <[email-masked]>
Date: Thu, 11 Jun 2009 12:23:40 -0400

Hi, 

> it does and the lets move on. ;-)
[...]
> manually configured or installed by a RADIUS client.

agreed.

> (securityModel, securityName) tuple? 

If we tried to do this with a SET what would happen? If it would fail
as a SET, then it should fail as a dynamic creation. You might want to
use a different counter for the dynamic creation failure.

> Who wins in this situation - or
> fail? 

If the row contains a RowStatus, would that make a difference?

> What happens if no new entries can be created anymore due to
> resource limitations? 

If we tried to do this with a SET, what would happen? we should be
consistent, although we have no way of sending back an error RESPONSE
message.

These are examples of new error situations
> that we have to deal with.

agreed.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Jun 2009 19:14:11 +0200

> If the row contains a RowStatus, would that make a difference?

The table has a RowStatus and a StorageType column and thus there are
quite a number of possible failure modes...
 
> consistent, although we have no way of sending back an error RESPONSE

My point is that have to define what the RADIUS client does in case
the attempt to push something into the vacmSecurityToGroupTable fails
- and depending on how long we want to work on this, we might go into
all the details of distinguishing different failure modes. It will
sure get complicated if we make it complicated.

But the minimum we have to do is to specify what the RADIUS client
does if the creation fails. And I think we should avoid making this
really more complicated.

/js

---

From: "David Harrington" <[email-masked]>
Date: Thu, 11 Jun 2009 13:26:01 -0400

+1 

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Thursday, June 11, 2009 1:14 PM
> To: David Harrington
> Cc: 'Dave Nelson'; [email-masked]
> Subject: Re: [Isms] Moving into some 
> design/architectureissuesofExtendedVACM
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 11 Jun 2009 12:37:19 -0700

Hi -

> Sent: Thursday, June 11, 2009 6:28 AM
> Subject: Re: [Isms] Moving into some design /architectureissuesofExtendedVACM
...
> objects.  Is there an SNMP-level error message that will inform the user

It depends.  Assuming the group is created automatically, in response
to an SNMP operation you might get "noSuchName", which would
be indistinguishable from "the data doesn't exist", or you might get
"authorizationError", which lets you know that the access-
control system kept you away from the information.

If the group were *not* created automatically (except when there is
something, such as corresponding entries in vacmAccessTable,  to
indicate that the group is "intended" to exist) then you're guaranteed
"authorizationError" in SNMPv3 by the procedures on page 12 of RFC
3413.

Even in this latter case, the operation *might* suceed if tried again later.
Consider this scenario:  while the security administrator is in the process
of pushing the updates to the vacmAccessTable in accordance with the
procedures spelled out in that table's DESCRIPTION, the rights granted
to members of that group will only stay the same or increase with each
update, so that members of that group can be assumed to have been
granted their full rights on that system only after *all* the relevant entries
to the vacmAccessTable have been successfully pushed.

I think the upshot of this is that carving out an exception doesn't actually
make anything easier here.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 11 Jun 2009 13:39:52 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Dave Nelson" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, June 11, 2009 7:05 AM
....
> manually configured or installed by a RADIUS client.

Adopting this philosophy helps answer the questions that follow...
 
> does this even cause the authentication of the incoming request to

If the row for  (securityModel, securityName) already exists,
then if the value of vacmSecurityToGroupStorageType is "readOnly",
then the "policy attribute" would have to be ignored.  For any other
value of vacmSecurityToGroupStorageType, the "policy attribute"
would result in an update of vacmGroupName, and (potentially)
vacmSecurityToGroupStatus set to "active".

> What happens if no new entries can be created anymore due to

Then no entry is created.  This is no different from the case where a
security administrator tries to create a new entry.

> that we have to deal with.

Yup.  Fortunately, none of them so far seems very complicated or scary,
as long as we don't try to change the fundamental design.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 11 Jun 2009 13:55:09 -0700

Hi -

> To: "David Harrington" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, June 11, 2009 10:14 AM
...
> sure get complicated if we make it complicated.

There are actually relatively few - I spelled them out in an earlier
message.

> does if the creation fails.

Yup, and I think the answer is "nothing."  There's no channel for
signalling back the failure.  From an implementation perspective,
if there aren't resources to create/update a vacmSecurityToGroupEntry,
then I'd be wary of trying to do things like queue up special-purpose
notifications for the security administrator, who'd be the one who'd have
to figure out a recovery strategy.

At an operational level, the user might notice that it was granted
different access rights than it expected.  The user might check its
vacmSecurityToGroupEntry (if it has permission to see it), or leave
that job to the security administrator.   (There would either be no entry,
or the group name specified in that entry would be the "old" one.)
In either case, figuring out a recovery strategy would still be up
to the security administrator, and would be no different from dealing
with a system that ran out of resources while a security policy update
was being pushed to it.

But I think we're off in the extreme corner cases here.  A system that
runs out of memory under these circumstances has a more serious
problem on its hands.  :-)

> And I think we should avoid making this
> really more complicated.

Agreed.

Randy

---

From: kaushik <[email-masked]>
Date: Thu, 11 Jun 2009 15:27:32 -0700

Hi Randy,

Please find my reply inline.

<snipped>

> for ease-of-use, but bad for security.

<Kaushik> 

The issue I have with this model is that we are using the RADIUS
user-to-group mapping which is a temporal association valid for the duration
of the session and provisioning a persistent piece of configuration on the
SNMP engine. I am not sure the semantics match and this could create
potential problems around whether the RADIUS server or SNMP engine is
authoritative source for user-to-group mapping since entries can be added to
the vacmSecurityToGroupTable without knowledge of the RADIUS server.

Regards,
 kaushik

</Kaushik>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Jun 2009 00:57:32 +0200

> to figure out a recovery strategy.

I am talking in general about a failure to install the requested
policy / name to group mapping - not just about the resource shortage
case.

Suppose the RADIUS server tells the RADIUS client that "joe" using
"TSM" is authorized for the management policy "restricted" but the
attempt of the RADIUS client to install this policy fails since for
some reason (e.g., there exists an entry for "joe" using "TSM" using
group "poweruser" that for whatever reason can't be modified). Is it
OK to ignore the failure and to let "joe" now use the "poweruser"
rights?  Or should the RADIUS client do something like deny
authentication of joe's session if it can't install the management
policy, or kill joe's session if it is already there (likely a
challenge to write down due to the architectural model we have, but
likely easy to implement ;-).

My understanding is that RADIUS decisions are of the kind "here is
exactly what you do or you deny service" (RADIUS folks, please correct
me if I am wrong). If this is the case, simply ignoring a failure to
install the requested policy sounds kind of wrong.

/js

PS: Does the RADIUS client have the "rights" to modify any existing
    writable matching table entries? Will it revert the changes when
    the session dies?

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 11 Jun 2009 17:14:00 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, June 11, 2009 3:57 PM
> Subject: Re: [Isms] Moving into some design/architectureissuesofExtendedVACM
>
> rights?

Yes, since that's exactly what would happen if another security
administrator tried to create/update the entry and failed.

>  Or should the RADIUS client do something like deny

I see no value whatsoever to doing so.  If the system is already configured
to treat that user as a member of a particular group, and (for whatever
reason) is unable to honor the group membership asserted by RADIUS,
then it makes perfect sense for it to use the policy it already has in
place.  After all, that's exactly what it would do today.

> install the requested policy sounds kind of wrong.

I think in our case it makes more sense to view this information as being
provided by a security administrator, since it is being used to update
the access control configuration of the system, and is *not* directly an
access-allowed/access-denied decision.
 
>     writable matching table entries?

If we take the stance that this should be treated like an update from a
security administrator, then yes, when vacmSecurityToGroupStorageType
is not 'readOnly', it would need to be able to update vacmGroupName and
vacmSecurityToGroupStatus (if not already 'active').

> Will it revert the changes when
>     the session dies?

Again, if we take as our model that the RADIUS information is configuration
data,  treated as if coming from an authorized security administrator, then
it does not make sense to revert the changes.

Randy

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 11 Jun 2009 13:39:23 -0400

I've sent other responses in this thread this morning, but the Elbrys
Networks DNS servers don't seem to like the ietf.org domain and my outgoing
mail often languishes.  Sigh.

---

From: "David Harrington" <[email-masked]>
Date: Thu, 11 Jun 2009 22:32:25 -0400

Hi,

I think the MIB should be augmented with a column to identify how it
was installed, and a time limit specified by RADIUS.

dbh 

> Behalf Of kaushik
> Sent: Thursday, June 11, 2009 6:28 PM
> To: Dave Nelson; [email-masked]
> issues of Extended VACM

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 11 Jun 2009 11:38:16 -0400

Juergen Schoenwaelder writes...

> Just be happy with what it does and the lets move on.

Perhaps.  My operating assumption is that VACM tables are not manually
updated frequently; in fact probably very infrequently.  Once the mistakes
in configuration ad detected, the Help Desk calls placed, and the error
rectified, things remain stable for a relatively long time.  All is
goodness.

Once the user to group mapping becomes dynamic, it seems to me that that
opportunity arises for much more frequent mismatches, with the resultant
user confusion and Help Desk calls.

Anyway, that's my current think on this issue.  I could be mistaken.

> (securityModel, securityName) tuple?

This is not unique to VACM.  There are other use cases where the NAS needs
to have a well defined precedence relationship for RADIUS-provisioned vs.
locally-stored session properties.  Sometimes this is a user configurable
parameter.

> What happens if no new entries can be created anymore due to

Good question.

---

From: "Dave Nelson" <[email-masked]>
Date: Thu, 11 Jun 2009 23:54:41 -0400

> OK to ignore the failure and to let "joe" now use the "poweruser"

I guess the question can be rephrased to ask whether you really want two
different repositories (the RADIUS server's database and the locally stored
VACM MIB entries) to be equally authoritative for authorization, especially
when they conflict.  I would think, in general, that's not a good idea.

In a carefully managed environment, many things are acceptable that would
not be acceptable in the more general case.  For example, if you assume that
the "joe" that RADIUS has authenticated is the same "joe" that is found
configured in the VACM MIB Module, it *might* in some circumstances be OK to
let the VACM data take precedence over the RADIUS data.  OTOH, if it's
possible that there are two *different* users with the username "joe" one in
RADIUS and another in VACM, then it may be a very bad idea.

Generally speaking when a feature is taken under RADIUS control, RADIUS is
considered to be the primary authority, and local data does not override the
access provisioned by RADIUS.  I feel quite uncomfortable with proposing
that behavior for use with the VACM extension.  Local data can use used with
RADIUS, but typically only in a fall-back use case, for example when RADIUS
is unavailable because of network problems or a server crash.

> likely easy to implement ;-).

With the caveat that this behavior could be overridden by local policy
configuration, this is exactly the behavior that I would recommend. 

Let me quote a portion of Section 6.3 of
draft-ietf-radext-management-authorization-07.txt, now in the RFC Editor
Queue:

   The management access policy named in this attribute, received in an
   Access-Accept packet, MUST be applied to the session authorized by
   the Access-Accept.  If the NAS supports this attribute, but the
   policy name is unknown, or if the RADIUS client is able to determine
   that the policy rules are incorrectly formatted, the NAS MUST treat
   the Access-Accept packet as if it had been an Access-Reject.

This indicates to me that when present in RADIUS authorization information
the policy (group name) specified in the Management-Policy-ID attribute MUST
be applied faithfully, or access MUST be rejected.

> me if I am wrong).

You are correct.

> If this is the case, simply ignoring a failure to install the 
> requested policy sounds kind of wrong.

Agreed.

>     writable matching table entries? Will it revert the changes when

I think it needs to revert, yes.

While we talk loosely of the RADIUS authorization information being used to
update the VACM MIB Module in the same sense that the SNMP engine would do
in response to an SNMP SET, we may be taking this too literally.  I think
that the RADIUS information kept by the VACM Extension should be transient,
with a lifetime limited to that of the secure transport session.

---

From: "Dave Nelson" <[email-masked]>
Date: Fri, 12 Jun 2009 00:23:08 -0400

Kaushik writes...
 
> user-to-group mapping which is a temporal association valid for
> the duration of the session and provisioning a persistent piece of
> configuration on the SNMP engine.

I have the same concern.  The simplicity of this concept -- populating the
vacmSecurityToGroupTable with data from RADIUS -- is alluring, to be sure.
It's useful for implementation, in that access control decision requests are
processed using existing code, and the table's contents can be used
externally for real time debugging of user access problems.

I think that one implementation "trick" that could be used to have the best
of both worlds would be to have a "shadow" copy of the
vacmSecurityToGroupTable that appears whenever RADIUS is "in play" and
disappears, revealing the statically and permanently stored version, when
RADIUS is "not in play".  The SNMP engine need not be concerned with which
copy of the table it was accessing at any given moment.  All the behaviors
would be the same either way.  The only difference is that we would not be
mixing statically configured user-to-group information with dynamically
configured user-to-group information.

This may sound like an odd idea at first blush, but I think it worthy of
serious consideration.

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 12 Jun 2009 00:04:28 -0700

Hi -

> From: "kaushik" <[email-masked]>
> To: "Dave Nelson" <[email-masked]>; <[email-masked]>
> Sent: Thursday, June 11, 2009 3:27 PM
> Subject: Re: [Isms] Moving into some design / architecture issues of Extended VACM
...
> the vacmSecurityToGroupTable without knowledge of the RADIUS server.

"Authoritative source"?  Whoever has the necessary access rights to update
the vacmSecurityToGroupTable is authoritative, as far as VACM is concerned,
and whatever the current configuration of VACM is will govern who can do what
to anything via SNMP.

The persistance of the information is governed by  vacmSecurityToGroupStorageType.
If the entry already exists, that's already been configured.  If a new entry needs to
be created, 'volatile' is the only type that makes sense.  Forcing persistence does
not make sense.

I think the crucial point is whether the information coming from the RADIUS server
is trusted as much as information coming from a security administrator.  If it is, then
updating vacmGroupName with the most recently received information makes sense.
If the RADIUS server is not trusted as much as a security administrator, then information
from it should not be used for making user/group mapping decisions.

It does *not* make sense for the value of vacmGroupName to "revert" upon termination
of the session or some other condition.  Consider the operational scenario where the
update of the RADIUS server is slightly out-of-phase with a VACM access control policy push.
Simple update of vacmGroupName will produce the correct answer.  Doing a "revert"
will result in vacmGroupName being *temporarily* updated via RADIUS to the correct value,
the SNMP push will walk on by, and then the "revert" will restore it to a now obsolete value.  Not good,
so to fix *that* you'd have to add additional state and require the push application to
write to objects that would appear to already have the correct value.  Yuck!

This isn't netconf.  This is SNMP.  Let's remember what the "S" is supposed to stand for.

Randy

---

From: "Dave Nelson" <[email-masked]>
Date: Fri, 12 Jun 2009 06:37:04 -0400

Randy Presuhn writes...

> "Authoritative source"?  Whoever has the necessary access rights
> to update the vacmSecurityToGroupTable is authoritative, as far
> as VACM is concerned...

That's today's model.  It's not at all clear to me it should be the model
going forward in a RADIUS-enabled extended VACM.

> ...and whatever the current configuration of VACM is will govern
> who can do what to anything via SNMP.

Correct.

> I think the crucial point is whether the information coming
> from the RADIUS server is trusted as much as information coming
> from a security administrator.

Right.  The use case we're talking about is one in which the "security
administrator" has been effectively replaced by the RADIUS server.  The
notion that RADIUS authorization information is considered advisory and
secondary to locally configured data is contrary to the way RADIUS is
intended to be used.  Local data can be used to place certain limitations on
the services provisioned by RADIUS, but that's almost always in the form of
limitations on the consumption of NAS resources.  RADIUS servers are,
generally speaking, unaware of such resource limitations in the NAS.

> If the RADIUS server is not trusted as much as a security 
> administrator, then information from it should not be used
> for making user/group mapping decisions.

I'd go further. If the RADIUS server is not trusted more than the security
administrator, then the I-D were talking about here is simply not applicable
to the use case.  Let's all go home.

> Consider the operational scenario where the update of the RADIUS
> server is slightly out-of-phase with a VACM access control policy
> push.

RADIUS needs to be in control of the user-to-group mapping.  SNMP is in
charge of the group-to-access-rights mapping.  Neither should attempt to
mind the other's business.  Yes, they do need to work in concert, such that
the set of group is commonly understood.  Having commonly understood group
names is REQUIRED to be able to use RADIUS in this fashion.

---

From: "David Harrington" <[email-masked]>
Date: Fri, 12 Jun 2009 11:38:21 -0400

[...]
> names is REQUIRED to be able to use RADIUS in this fashion.

I strongly object to a "VACM extension" that works this way.
That is a totally different access control model, with different
assumptions, and it shoulkd use its own MIB module.

That way VACM and RADIUS-ACM models can coexust.
And THAT is a key tenet of SNMPv3.

dbh

---

From: "Dave Nelson" <[email-masked]>
Date: Sat, 13 Jun 2009 09:40:32 -0400

(This me be a duplicate reply.)

> And THAT is a key tenet of SNMPv3.

Didn't we previously consider creating a completely new ACM for usage with
RADIUS and then dismiss that option, because of an "issue" with the
architecture that precludes a practical method of selecting an ACM at run
time?

I could probably find that thread if I searched through the archives.

As I recall, some asserted that adding another ACM would require us to
perform some "maintenance" on the SNMPv3 and/or ASIs such that the ACM could
be selected on a per packet basis.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 13 Jun 2009 16:24:05 +0200

> architecture that precludes a practical method of selecting an ACM at run

Indeed, the SNMPv3 specs do not define a way to select the ACM
responsible for a given message. Since so far has only been one ACM
(VACM), we all live happily with this. From this perspective, it is
attractive to use VACM unmodified.

/js

---

From: "Dave Nelson" <[email-masked]>
Date: Sat, 13 Jun 2009 12:31:03 -0400

> attractive to use VACM unmodified.

Well, yes, but adding new functionality and refraining from modification are
often incompatible goals.  :-)

I suppose, one could posit an architecture in which some glue code is added,
in the form of a local SNMP application that has an interface to RADIUS and
has write access to the VACM's MIB tables.  RADIUS then looks like an odd
form of system administrator, tinkering with the security objects.

The problem, as I see it, is that some of the rules for VACM MIB object
usage conflict with traditional RADIUS service provisioning practice.  I
don't want to offend any of the long time SNMP experts, but this seems to me
just one more case where the RFC 3114 SNMP architecture is modular as long
as you never consider options that weren't considered during its
formulation, such as providing SNMP packet security outside of the Security
Subsystem.  This may be another case where we need to be willing to think
"outside the box".

I agree that we seem to be limited to two options:

(a) Extend VACM so that it's RADIUS (or generically AAA) aware.

(b) Add a new SNMP application that takes counsel from RADIUS and modifies
the VACM's MIB objects, as if it were an external security administrator.

I'm concerned that if we take the (b) approach, we'll have an interesting
time addressing (or blithely ignoring) corner cases and security risks.
This approach is vastly simple on one level -- it does not touch existing
VACM code.  However it's highly complex on another level -- the RADIUS
provisioning model seems to have conflicts with the VACM provisioning model.

One issue that we need to resolve is "Who's in charge?".  It is reasonable
to use authorization information on a mix-and-match basis from two distinct,
and perhaps non-coordinated, entities?

I've previously posted my reasoning, based in the RADIUS NAS-Management I-D
text, why it's simply unacceptable for RADIUS-provisioned access control to
be ignored, e.g. because of a locally configured user-to-group that
conflicts.  I would characterize RADIUS as an "It's my way or the highway."
type of protocol.  If the NAS can't faithfully provision service as RADIUS
has specified it, the NAS must reject access altogether.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 13 Jun 2009 19:13:52 +0200

> the VACM's MIB objects, as if it were an external security administrator.

Well, (b) is not really an option - as long as you mean "application"
in the RFC3411 sense. What we have as an option is this:

(c) Fix the RFC3411 architecture so that is supports multiple access
    control models and then write a RADIUS access control model.

My concern is that we won't get this done easily and it will take one
year longer than we are planning this WG to continue.

/js

---

From: "Dave Nelson" <[email-masked]>
Date: Sat, 13 Jun 2009 13:20:12 -0400

Or course, there *are* some models of disparate authentication systems used
in a precedence relationship.  For example, consider NIS and /etc/passed as
used for UNIX login.  The key is that there *is* a precedence relation, and
you won't find NIS populating /etc/passwd with user entries.

---

From: "Dave Nelson" <[email-masked]>
Date: Sat, 13 Jun 2009 13:25:17 -0400

> in the RFC3411 sense.

You're probably right.  An SNMP application won't have the right hooks into
the "session creation" process.

> What we have as an option is this:
> 

Yeah.  That would be the "right thing" to do.  The question is whether there
is support in the Internet community to undertake that effort and whether
the result would be worth the effort.  I'm thinking that quick is good.

So, is option (a) still on the table?

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 12 Jun 2009 12:38:01 -0400

> assumptions, and it should use its own MIB module.
> 
> That way VACM and RADIUS-ACM models can coexist.

Didn't we already consider having a completely new ACM for RADIUS usage and
dismiss that option because of some "issue" with the architecture that
precludes a practical run-time selection mechanism for the ACM?

(This message probably won't make it to the mailing list until late tonight
or early tomorrow.  We're still having mail server issues.)

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 13 Jun 2009 21:53:47 -0700

Hi -

> Sent: Saturday, June 13, 2009 9:31 AM
> Subject: Re: [Isms] Moving into some design / architecture issuesofExtendedVACM
...
> the VACM's MIB objects, as if it were an external security administrator.

In my opinion, (b) will bring completion with the least risk and the greatest
degree of operational interoperability with deployed management systems.

> time addressing (or blithely ignoring) corner cases and security risks.

So far, even the corner cases look incredibly straightforward.  It's only when
people try to get fancy (ignore the "S" in SNMP) that it looks like they'll
wrap themselves around the axle.  I'd argue that the "corner cases" in (b)
will be much easier to enumerate and analyze that if we create something
brand new that operates differently in any way from classic VACM.

> provisioning model seems to have conflicts with the VACM provisioning model.

Perhaps, but i think that if it look at it from one level above that, the
level of the enterprise-wide security administrator, those "conflicts"
are only transients that result when the push of a security policy update
gets slightly out-of-phase with RADIUS.  The good news is that the situation
is self-healing, *if* you take the simple approach and don't try to make
things fancy.

> and perhaps non-coordinated, entities?

It depends on how you read "non-coordinated."   If you mean "not necessarily
operating in lock step as policy updates are propagated", I think you have to
take it as a given, and it's not a problem if you handle the updates as I've
outlined earlier in this thread.  If you mean "not converging to the same security policy",
then you've got a much bigger problem, since you've granted both of them
access rights to change the security policy on the managed device.

> conflicts.

I don't think anyone is arguing for that.  The sole case I can see in which
the RADIUS-supplied user-to-group mapping should be ignored is
when the value of the corresponding vacmSecurityToGroupStorageType is
'readOnly', meaning it's in ROM and would not be changeable under
any circumstances by any security administrator.

>  I would characterize RADIUS as an "It's my way or the highway."

Perhaps, though handling this corner case in this way would mean that
if your network had a mix of systems with dynamic and "ROMmed" entries
for some user (e.g. "root"), and they did not all have the same ROM
group name for this user, then you would have to turn RADIUS off
in order to access the systems for which that user had a ROM entry.
To me, that cure sounds substantially worse than the disease.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 13 Jun 2009 21:58:15 -0700

Hi -

> Sent: Saturday, June 13, 2009 10:13 AM
> Subject: Re: [Isms] Moving into some design / architectureissues ofExtendedVACM
...
> Well, (b) is not really an option - as long as you mean "application"

Of course, I'm using it in a *much* looser sense.
One *could* think of it as using the ASIs to access the
corresponding instrumentation, or as reaching into the
vacmSecurityToGroupTable directly.  The important
part is the understanding that it's acting on behalf
of the security administrator.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 14 Jun 2009 15:12:31 +0200

> you won't find NIS populating /etc/passwd with user entries.

SNMPv3 currently does not have this for authentication and it does not
have this for authorization. To fix the multiple ACM issue, one would
have to extend the SNMPv3 infrastructure with a table that controls
how multiple ACMs each implementing the isAccessAllowed() ASI would
work together. One option is of course to have priorities. If we would
have something like this, we could have a RADIUS VACM MIB module which
provides a security name to group name mapping based on RADIUS policy
information and otherwise reuse VACM access rules. Then the new ACM
control table would allow me to specify whether RADIUS takes
precedence or not and I can have my fallback config in the VACM MIB
that is being used when RADIUS fails.

This might be the cleanest solution. But getting this right does
require some great deal of help of some SNMPv3 seniors...

/js

---

From: kaushik <[email-masked]>
Date: Mon, 15 Jun 2009 17:33:25 -0700

Hi Juergen,

I like the approach you have proposed to have the RADIUS user-to-group
mappings and VACM user-to-group mappings in separate tables and have a
control table to decide precedence.

Regards,
 kaushik

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 15 Jun 2009 17:43:14 -0700

Hi -

> Sent: Thursday, June 11, 2009 8:54 PM
> Subject: Re: [Isms] Moving into some design/architecture issues ofExtendedVACM
...
...

Repeating myself: this would interact badly with security policy updates.
It is much safer for changes to vacmGroupName in a vacmSecurityToGroupEntry
to behave just like they would if they had been set.  If they can "revert", then an entry
which appeared to be up-to-date when inspected by a security administrator could
silently become not-up-to-date because a secure transport session ended.
This would make a hash  of security policy configuration management.

Simple really is preferable here.  It's less work for the implementor,
both of management applications and in the guts of the SNMP implementation.
It's less work for the security administrator.  And it would be a lot simpler
for this WG.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 15 Jun 2009 17:53:57 -0700

Hi -

> Sent: Thursday, June 11, 2009 9:23 PM
> Subject: Re: [Isms] Moving into some design / architecture issues ofExtended VACM
>
> Kaushik writes...
>  

I think it has a real problem from the perspective of security configuration
management.  A security administrator should be able to find out how
a system's security policy is configured, regardless of whether RADIUS
is in use.  This means the "shadow" table would need to be visible to
management.  However, the security administrator should also be able
to configure and update the "real" VACM configuration whether RADIUS
is in use at the moment or not.  This means that "write" operations
would need to affect both the shadow and the "real" configuration.
However, to determine whether the "real" configuration is in need of
update, it must be possible for the administrator to retrieve it.  This
conflict is irreconcilable.

To kluge around it, I think you'd have to use a separate SNMP context for the
shadow.  This is just too ugly and convoluted a thing to do for no real
benefit, particularly since it would require standardizing a context name
for this kluge.

Randy

---

From: "Dave Nelson" <[email-masked]>
Date: Mon, 15 Jun 2009 23:26:53 -0400

Randy Presuhn writes...

> Repeating myself: this would interact badly with security policy
> updates. It is much safer for changes to vacmGroupName in a
> vacmSecurityToGroupEntry to behave just like they would if they
> had been set.

I think we're talking at cross purposes.

You seem to be talking about maintaining consistency between RADIUS usage
and manual security administration.  IIRC, the whole premise of the ISMS
work is that many operators feel that SNMPv3 security is simply too
complicated to deploy.  So they don't.  They want something ties into their
existing infrastructure.

We're talking about two different audiences, those who like SNMPv3 security
and use it as defined today and those who don't.  The ISMS work address the
"those who don't" audience.  I think, by definition, there aren't any
operational conflicts to be resolved.

Beyond that, I think you need to seriously consider other examples of how
local, static authentication and authorization is integrated with remote,
dynamic authentication and authorization.  There are precedents.  The UNIX
login usage (NIS vs. /etc/passed file) is just one.

I too am repeating myself, and it seems that we simply look at this problem
very differently.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Jun 2009 07:01:56 +0200

> It's less work for the security administrator.  And it would be a lot simpler

Randy,

you have the same probem if I as the security administrator change the
VACM table and then RADIUS comes in and simply changes what I have
carefully configured. I tend to agree with Dave Nelson that having a
single table modified by two different entities is likely asking for
trouble. You might argue that the problem is really the conflict
between RADIUS policy and the security administrator's policy. My
counter argument to that is that if both would be in fine synchrony,
we would not need the RADIUS interface in the first place.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Jun 2009 07:07:14 +0200

> benefit, particularly since it would require standardizing a context name

I do not think you need to mess around with contexts. If we can make
multiple ACMs to work, the problem has a solution.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 15 Jun 2009 22:34:27 -0700

Hi -

> Sent: Monday, June 15, 2009 10:01 PM
> Subject: Re: [Isms] Moving into some design/architecture issuesofExtendedVACM
...
> carefully configured.

I don't think this is operationally a problem.

As a matter of sanity, we have to assume that what the security administrator
tells RADIUS to do is the same as what he wants the SNMP-alone policy to be.
If they're at odds, he's got a bigger problem than we can solve here.

So the cases we need to worry about are those where SNMP and RADIUS
policy updates get out of phase.  The case you describe is the worst case
that can happen with a sane adminstrator, so it's worth exploring.

Consider what a security administrator needs to do to effect a policy change:
  (1) he needs to tell the RADIUS servers about the change
  (2) he needs to tell the SNMP management infrastructure about the change

(1) is going to generally propagate faster than (2), particularly since
(2) isn't complete until ever single managed device in the administrative
domain has been updated.

Even in the case that  (2) happens for some node before the
RADIUS servers are notified of the policy change,
it will "heal" when the RADIUS server is finally updated
and that user needs access again.  Furthermore, this behaviour is
in line with the "RADIUS is always definitive" philosophy folks
have been arguing for.

This worst-case scenario is still more desirable than the failure
mode I described with the proposed "revert" behaviour.

> I tend to agree with Dave Nelson that having a

No, demanding synchronization is unrealistic.  We need to assume
they'll be out of sync at least some of the time, but we also should
assume that it's operationally desirable for them to converge.
Consequently, the "dueling manager" scenarios fall under the
general rubric of "don't do that", and we only need to check through
the cases where things are temporarily out of sync to understand
the implications.  In those cases, as far as I can tell, nothing worse
happens than would occur if updates were slow to be propageted
to the RADIUS servers in the absence of SNMP-based policy
updates.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 15 Jun 2009 22:57:21 -0700

Hi -

> Sent: Monday, June 15, 2009 10:07 PM
> Subject: Re: [Isms] Moving into some design / architecture issuesofExtended VACM
...
...

Multiple ACMs would be a wonderful theoretical Pandora's box project to give
to some grad student to play with.  Be careful what you wish for, especially when
it comes time to send notifications.  For the implementations with which I am
familiar, having multiple ACMs would be *very* tricky.  Don't forget the
extent to which isAccessAllowed is involved in the conceptual processing
of GetNext, GetBulk, and notifications, and that a real implementation,
rather than relying on the ASI abstraction, may look directly into the
heart of VACM in order to optimize subagent subtree queries during GetNext
and GetBulk.  Having the possibility of a different access control model
could throw a monkey wrench into those algorithms.

Folks think having VACM to deal with is difficult.  Just wait until
folks start putting in ACMs of their own in order to "simplify" things.

But it will give the WG, implementors, and operators a lot more to do,
so I suppose some might consider that a win.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Jun 2009 09:29:02 +0200

On Tue, Jun 16, 2009 at 07:34:27AM +0200, Randy Presuhn wrote:
 
> As a matter of sanity, we have to assume that what the security
> administrator tells RADIUS to do is the same as what he wants the
> SNMP-alone policy to be.  If they're at odds, he's got a bigger
> problem than we can solve here.

If we make this assumption, why then have RADIUS at all?

I am familiar with envrionments where the SNMP configuration is rather
static and never changed unless really really really necessary. In
particular, nobody wants to configure a number of SNMP agents just
because a single user needs to be added/removed. But people are much
more happy to do this via a centralized (RADIUS) mechanism. In other
words, in such environemnts, the SNMP static access policy is by
definition different from the RADIUS access policy. For these
environments, making the assumption that the RADIUS and static SNMP
access policy are essentially the same except during transitional
update periods is a non starter since I still have to update a number
of SNMP agents - so there is really no win in having RADIUS involved.

/js

---

From: "David Harrington" <[email-masked]>
Date: Tue, 16 Jun 2009 08:29:30 -0400

Hi,

At the risk of repeating myself ;-) ...

If you design an ACM that operates with a totally different set of
assumptions, then you are designing a new ACM, not extending an
existing one. 

If you want an ACM that operates following RADIUS, rather than SNMPv3,
assumptions, then I think you need to design a new ACM and that means
you need to address the issue that the SNMPv3 WG did not provide an
ACM selector. 

That will take significantly more time to address than simnply adding
some RADIUS attributes to allow dynamically provisioning the existing
VACM models.

I expect there would be other significant problems to solve besides
the selector to get RADIUS-like assumptions built into SNMPv3; The
SNMPv3 WG **deliberately** split authorization from authentication,
using only the ASIs for bindings. I think you will effectively be
trying to design a new SNMP architecture based on AAA assumptions if
we follow your reasoning here. The RADIUS and SNMP architectures do
not match, and ISMS has not been authorized to totally redesign SNMP
and its assumptions.

dbh

> Sent: Monday, June 15, 2009 11:27 PM
> To: [email-masked]

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 16 Jun 2009 08:38:42 -0400

> I am familiar with envrionments where the SNMP configuration
> is rather static and never changed unless really really really
> necessary.

I suspect that this broadly applies to the access control rules and the
"roles" that are defined by the collections of rules, i.e. the "groups".  I
think that "roles" change very infrequently, once initially debugged and
tuned, unless something in the organization changes, such as a different
division of responsibilities or some new type of equipment with new
management challenges is introduced.

I think it's fair to say that the group definitions are semi-static, and
managed by traditional SNMP access.  These definitions are certainly *not*
managed by RADIUS.

I also think it's fair to say that most organizations have only a handful of
roles / groups.  What changes most frequently is the assignment of people to
roles.  From all the postings to date, I believe we have rough consensus on
that much.

What seems to be in contention is *how* the dynamic information from RADIUS
is applied.

The issue that seems to be most contentions is whether the securityName to
groupName binding provided by RADIUS is persistent in the NAS after the
session has ended.  While this is the way SNMP works it is not the way
RADIUS works.  This is the root of the disagreement -- very different
persistence models between RADIUS provisioning and SNMP provisioning.  Each
camp naturally views the issues from their own experience base and comfort
zone.

How do we resolve this?

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 16 Jun 2009 08:44:35 -0400

> The RADIUS and SNMP architectures do not match, and ISMS
> has not been authorized to totally redesign SNMP and its
> assumptions.

Nor has the WG been authorized to totally redesign RADIUS and its
assumptions.  :-)

Clearly there's an impedance mismatch between the operational models.  If
we're to proceed, we need to find a way to mitigate those issues.  I don't
think that misapplying RADIUS to the problem in an attempt preserve SNMP
architectural integrity is the answer.

---

From: "David Harrington" <[email-masked]>
Date: Tue, 16 Jun 2009 08:53:51 -0400

Hi,

SNMP is built with the assumption that one or more managers have
access to the MIB residing in an agent. That includes the VACM tables,
unless the access controls themselves prevent access. 

So it has long been a basic assumption in the SNMPv3 design that the
access control tables can be modified by more than one administrator
or management application. While the SNMPv3 WG punted on designing an
ACM selector field in the message, or some other mechanism, it was
always the consensus of the SNMPv3 WG that multiple ACMs could exist
and operate simultaneously. 

COPS-PR was a no-go in the IETF because it demanded that if COPS-PR
was enabled, then COPS-PR and only COPS-PR, controlled the policy
decisions for a managed device. For operators to use a different NM
interface, they needed to disable COPS-PR. Operators said "no way!" 

For me, this argument that when RADIUS is in use, it must be the only
access control in play follows a similar vein of thinking, and I think
this is a no-go.

dbh

> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, June 16, 2009 1:02 AM
> To: Randy Presuhn
> Cc: [email-masked]
> design/architectureissues ofExtendedVACM
>

---

From: "David Harrington" <[email-masked]>
Date: Tue, 16 Jun 2009 09:03:00 -0400

Hi,

I think Juergen's suggestion of a precedence table in a MIB might make
sense. That keeps the system SNMP-manageable, allows the administrator
the choice of precedence, and allows us to have a separate MIB module
and associated elements of procedure for RADIUS ACM support.
Effectively, we can design a new RADIUS ACM, and use the precedence
table as the selector mechanism. 

I assume the ACM precedence table must be preconfigured, just as the
policies are. I do think there will be plenty of problems forcing one
ACM to always have precedence, and I can envision admins wanting one
system to have precedence for some users (e.g., the IT staff, in case
of the need to override RADIUS), while other users should always be
controlled under the RADIUS approach. But setting precedence by user
would require preconfiguration of the users. ACM Precedence probably
needs to be by group. Setting precedence might be able to be added for
a user/group mapping by adding an ACM selector to the RADIUS
attributes. That might not work for the it-group, though. I think the
precedence table needs to be similar to a capabilities negotiation; an
admin can configure the table to say "RADIUS takes precedence for this
group if it is available; otherwise USM MAY be used by this group."
For non-emergency uses, RADIUS could specify the precedece order for a
group, but somehow, the security admin needs to be able to say that
"this group needs authorization to override a RADIUS rejection".

dbh

> Sent: Tuesday, June 16, 2009 1:07 AM
> To: Randy Presuhn
> Cc: [email-masked]

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 16 Jun 2009 09:20:34 -0400

> While the SNMPv3 WG punted on designing an ACM selector field
> in the message, or some other mechanism, it was always the consensus
> of the SNMPv3 WG that multiple ACMs could exist and operate 
> simultaneously.

In other words, you're all pretty much in a state of denial. :-)

> decisions for a managed device

An interesting sidelight on IETF network management protocol history, but
not directly relevant to the current debate, I think.

> For me, this argument that when RADIUS is in use, it must
> be the only access control in play follows a similar vein of
> thinking, and I think this is a no-go.

Except that no one has ever said that.  What I have said is that the
"multiple writers" problem for AAA should be solved in an organized way,
following accepted principles of precedence -- primary and fallback -- and
not in the simple "last change takes precedence" fashion traditional to
SNMP.  The use of RADIUS does not preclude the use of statically configured
user-to-group data in the NAS, any more than the use of NIS for UNIX login
precludes the use of the /etc/passwd file.

Sometimes in order to obtain new functionality, you need to be open to
change.

All I'm asking is that the RADIUS provisioning operation model not be
violated, and that RADIUS provisioned access control information has a
lifetime limited to that of the underlying session.

---

From: "David Harrington" <[email-masked]>
Date: Tue, 16 Jun 2009 09:24:39 -0400

Hi,

I think we actually have consensus about persistence. 

I think everybody expects that the user-to-group mapping should go
away when the radius-authorized session ends; we just need to figure
how to do that without redesigning snmpv3 and the rfc3411
architecture. 

I do not think we have consensus on reverting.

dbh

> Sent: Tuesday, June 16, 2009 8:39 AM
> To: [email-masked]

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 16 Jun 2009 09:29:54 -0400

> For non-emergency uses, RADIUS could specify the precedence
> order for a group, but somehow, the security admin needs to be
> able to say that "this group needs authorization to override 
> a RADIUS rejection".

I think you're making this *way* too complicated.

First, I don't believe there is a real market requirement for
fine-granularity precedence of AAA sources.  One can posit hypothetical
scenarios where it could be useful, but I think that's outside the
80-percent problem.

Second, no one should *ever* be able to override a RADIUS reject.  If there
is a problem with the RADIUS service, then a good design is to have one (or
a very small number) of locally configured user identities that bypass
RADIUS altogether -- the analog of the "root" account in the /etc/passwd
file.  Having a simple selection mechanism to choose between using RADIUS or
local data is sufficient, and that could be as simple as "root" is always a
local account.

Once you get into the business of second guessing the authoritative AAA
service, as to access control decisions, "Abandon Hope All Ye Who Enter
Here".

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 16 Jun 2009 09:46:18 -0400

> away when the radius-authorized session ends; ...

Excellent!

> ... we just need to figure how to do that without redesigning
> snmpv3 and the rfc3411 architecture.

I eagerly await suggestions, as I have (temporarily) run out of ideas.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Jun 2009 17:05:42 +0200

> "this group needs authorization to override a RADIUS rejection".

Way too complex if you ask me. Such an ACM precedence table should be
as minimal as we can make it - and Randy believes even that is way too
complicated because of ACM optimizations some SNMP toolkits do for
performance reasons. For me, the minimal solution is a table
consisting of a priority column and an ACM identification column.

If I would have a configured precedence like try first RVACM (Radius
VACM) and then VACM, then RVACM might return a statusInformation of
the isAccessAllowed() allowed that tells my code to 'continue' with
the next ACM. However, VACM does not have such a continue return code
defined (RFC 3415 page 7) so I would assume that a VACM decision is
always final (access/failure). In other words, the precedence VACM and
then RVACM would never reach RVACM.

Here is what this exercise boils down to:

a) A control table needs to be defined that specifies the precedence
   order in which ACMs are consulted.

b) A very slight change to the isAccessAllowed() ASI since the
   statusInformation would be "success or errorIndication or continue"
   for new ACMs.

c) Updates would be needed to section 3.2 of RFC 3413 step (5) where
   isAccessAllowed() is called from Command Responder applications

d) Updates would be needed to section 3.3 of RFC 3413 step (2) and (3)
   where isAccessAllowed() is called from Notification Originator
   applications

Putting my chair hat on, the question is whether ISMS is chartered to
do such a piece of work that affects several core SNMPv3 documents.
So far, work on new access control models was clearly out of scope for
this WG. The proposed new charter text also talks pretty clearly about
"a binding between a user and preconfigured VACM policies via dynamic
additions to the securityToGroupname table." So if this charter gets
approved, I believe the work outlined above falls out of the charter
and we have to come up with some other sensible ways to deal with
conflicts that can happen if RADIUS is asked to overwrite existing
table entries.

/js

---

From: "David Harrington" <[email-masked]>
Date: Tue, 16 Jun 2009 12:56:18 -0400

I prefer to avoid using contexts to solve this issue.

dbh

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 16 Jun 2009 10:38:42 -0700

Hi -

> Sent: Tuesday, June 16, 2009 5:38 AM
...
> camp naturally views the issues from their own experience base and comfort

I think it's helpful to break it down into the specific cases:

(1) a matching entry (identified by user name and security model) already 
      exists when the data from RADIUS arrives.

      This is the case that's been getting most of the attention in this discussion.
      It occurs when something gets provisioned both through SNMP and through
      radius.  I believe that in this case, the persistence should be in accordance
      with the row's StorageType, and that the most recently supplied group
      mapping should "win", with no mystical "reverting" of values.

(2) No matching entry exists when the data from RADIUS arrives.

      I think it is quite reasonable for such entries to have a very limited lifetime,
      and that upon expiration of that lifetime, they should evaporate, unless
      in the meantime a manager has stepped in and changed the StorageType
      from 'volatile' to something more permanent.

Now, I *think* a reasonable compromise is possible.  Under normal operational
conditions, it doesn't make much sense to provision vacmSecurityToGroupStorageType
to be volatile.  After all, the security administrator creating the entry would almost
certainly like it to survive the next reboot!  So, consider the following:

When the data arrives from RADIUS, check for a matching  vacmSecurityToGroupEntry.
If it exists and vacmSecurityToGroupStorageType is not readOnly:
Then
   update vacmGroupName with the data received from RADIUS
Else
   create an appropriate entry:
       using the supplied data for  vacmSecurityName, vacmSecurityModel,
       and vacmGroupName; 'volatile' for vacmSecurityToGroupStorageType,
       and 'active' for 'vacmSecurityToGroupStatus'

When the user's last session goes away (there may be multiple, overlapping
sessions, right?):
If there is a matching  vacmSecurityToGroupEntry (it's possible that creation
failed due to system resource exhaustion, but that is a pathological corner case)
Then
   if the entry's vacmSecurityToGroupStorageType is 'volatile'
   Then set vacmSecurityToGroupStatus to 'destroy'

I think this satisfies fairly well everyone's requirements, doesn't change VACM
one bit, produces no "surprising" results and is really really simple.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Tue, 16 Jun 2009 17:30:34 -0400

Hi,

OK. We can simplify this if we do not change the assumptions in the
basic VACM model.

We need to allow RADIUS to provision the VACM user-to-group table, or
to provision a second table for user-to-group mapping, with an
admin-configured precedance table. I think the simplest approach is to
treat thia as a VACM extension, and that means it happens between the
isAccessAllowed() interface and the VACM elements of procedure. 

We add a second mapping table, and a precedence table, and some EOP
that immediately check the precedence table to determine which mapping
table to use. The only thing the precedence table decides is which
user-to-group mapping table to use. Once we have the correct table,
then VACM elements of procedure work as designed.

We can choose to not support a fallback approach; if RADIUS-authz
fails, well, it fails. An operator can try a different username, such
as root, to connect if RADIUS is not available. 

In this way, we do not need to add a "continue" option to
isAccessAllowed, and we are not changing any of the existing RFCs, or
any ASIs. We are merely developing an optional augmenting MIB module
for VACM with associated elements of procedure.

How an access control model decides to map users to policies has
always been considered the purview of the specific access control
model. All we are doing is adding some flexibility to VACM's decision
mechanism.

If we want to ensure there are no competing admins, but help admins
understand what is happening regarding authorization, we can make the
RADIUS mapping table into a read-only MIB module; only RADIUS can
alter it. 

I think the ACM precedence should be assigned per group. So you might
have most operators assigned groups in the RADIUS table, while a
select few operators (superusers) are configured to use statically
configured VACM. So it is a manual fallback design.

dbh

> Sent: Tuesday, June 16, 2009 11:06 AM
> To: David Harrington
> Cc: 'Randy Presuhn'; [email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Tue, 16 Jun 2009 18:20:00 -0400

Hi,

I suggest the RADIUS attributes be stored and associated with a
RADIUS-authorized session. When the session goes down, the attributes
and the session authorization are deleted. The VACM-RADIUS extension
should check whether RADIUS authorization attributes are present and
valid or not, much as SSHTM checks whether we have a present-and-valid
tmStateRefreence. If the session is closed there will be no
authorization attributes available. 

Representing this in a MIB or an ASI construct helps to standardize
this, including the terminology, so we can better check whether
independent implementations will have interoperable assumptions. This
also makes the job for the WG harder. But this may also make the IESG
more comfortable that we have an interoperable solution. An operators
might want to be able to see what is happening regarding RADIUS
authorizations.

I think limiting the MIB-ified part to the VACM user-to-group table,
and augmenting the table using standard MIB things, like lifetime
objects and RowStatus to indicate/manipulate the entries, as Juergen
suggested, could be fairly simple. We might want some type of "void
pointer" in the table to the implementation-dependent
session-associated authorization information. 

We already have a "void pointer" tmSessionID in the tmStateReference
with which the attributes could be associated in an
implementation-dependent manner. 

dbh

> Sent: Tuesday, June 16, 2009 9:46 AM
> To: [email-masked]

---

From: kaushik <[email-masked]>
Date: Wed, 17 Jun 2009 15:21:57 -0700

Hi Randy,

Sorry for the delayed response.

I was referring to notion of "authoritative source" really at a system
level. A typical environment will have some form of Identity management
system, for e.g. An LDAP server, as an authoritative source of user
identities and group mappings. RADIUS servers will typically acquire
attributes on a per session basis to evaluate network access policies and I
was hoping that a similar model could flow down to VACM wherein the group
mapping provided by the RADIUS server had the semantics of a temporal
read-only attribute. This is probably in line with the model Juergen
suggested where we have a separate RADIUS VACM table that store
user-to-group mappings received from RADIUS.

Regards,
 kaushik