Subject: [Isms] wg last call on the radius / vacm document

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Mar 2010 10:08:29 +0100

This message starts a 14-day working group last call on the
following document:

  Extensions to the View-based Access Control Model for use with RADIUS
  <draft-ietf-isms-radius-vacm-05.txt>

  http://tools.ietf.org/html/draft-ietf-isms-radius-vacm-05

This WGLC will end on March 22, 2010.  Please review the document
and post your comments on the mailing list.  If you have reviewed
the document but do not have comments, please let us know as well.

We will treat the questions Randy Presuhn asked on the WG mailing list
on March 6 as WG last call comments.

Please review this version of the document - it is reasonably short
and should not take too much time to review.

/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: "David B. Nelson" <[email-masked]>
Date: Mon, 8 Mar 2010 09:02:15 -0500

>  <draft-ietf-isms-radius-vacm-05.txt>

I will send my comments in separate email messages for each major issue.

Regards,

Dave

David B. Nelson

Elbrys Networks, Inc.
282 Corporate Drive, Unit 1
Portsmouth, NH 03801

+1.603.570.2636
www.elbrysnetworks.com
[email-masked]

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 8 Mar 2010 09:17:45 -0500

In Section 4.3:
  Likewise, although this memo specifically refers to RADIUS, it MAY be
  used with other AAA services satisfying these requirements:

    o  the service provides information semantically equivalent to the
       RADIUS Management-Policy-ID attribute [RFC5607], which has been
       mapped (perhaps trivially) into a GroupName;

    o  the service provides information semantically equivalent to the
       RADIUS User-Name Attribute, which has been mapped (perhaps
       trivially) into a SecurityName.

I'm moderately concerned about the language "which has been mapped  
(perhaps trivially)".
Admittedly, I look at this work more from an AAA / Security  
perspective, than from an SNMP / Network Management perspective.  My  
"principle of least surprise" is driven by the viewpoint of the RADIUS  
system administrator, rather than that of the SNMP system  
administrator.  When they are in fact the same individual, it doesn't  
matter, of course.  My concern is for the deployments where it's not  
the same individual.
I don't think that many NAS (RADIUS client) implementations perform  
"mapping" on RADIUS authorization attributes, except to the extent  
necessary to translate them into action, in an implementation  
dependent internal data structure.  For the Management-Policy-ID,  
there is always some sort for mapping going on, since this is simply a  
name for a locally-provisioned policy.  In the case of the User-Name,  
this is the user's identity, and the only common form of "mapping"  
would be the addition or stripping of a "domain-part", as in the case  
of a Network Access Identifier.  Perhaps this simply warrants some  
additional text in the Security Considerations section to describe  
what might happen if non-trivial mappings were to be applied to these  
values.  If the managed entity views user identity different from the  
RADIUS system administrator, there is certainly the opportunity, at  
least, for a "surprise" and in some cases it might result in a  
misidentification that would pose a security risk.
Regards,

Dave

David B. Nelson

Elbrys Networks, Inc.

+1.603.570.2636
www.elbrysnetworks.com

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 8 Mar 2010 09:47:17 -0500

Section 7.2.2:
    If a corresponding entry already exists in the
    vacmSecurityToGroupTable, and the row's StorageType is anything  
other
    than "volatile", or the RowStatus is anything other than "active",
    then a role (group) mapping for this user (principal) has already
    been put in place on this system, and will not be overridden.
I've said this before, but I'll say it again, hopefully in clearer  
terms.  I think that the notion of the *same* principal identity that  
comes from RADIUS (or other AAA) having already been "put in place on  
this system" is highly dubious.  At best, it relies on special  
circumstances.  Here's my reasoning on this:
(a) There is nothing in the documented protocol or elements of  
procedures that guarantees that the content of an SNMP securityName  
bears any relationship to the content of a RADIUS User-Name *unless*  
the former is dynamically obtained from the later, in the context of a  
single secure transport session.
(b)  In the absence of careful coordination on the part of the RADIUS  
system administrator and the SNMP system administrator, i.e. "special  
circumstances" there is no guarantee that independently, manually- 
configured but identical user names actually refer to the same user.   
For example, it is possible that the RADIUS system administrator is  
using the name "dave" for Dave Nelson and the SNMP system  
administrator is using the name "dave" for Dave Harrington.  I  
understand that the likelihood of such name collisions is reduced if  
fuller versions of the names are used, but 'll observe that at one  
point in time there were *five* Dave Nelson's working for Digital  
Equipment Corporation, of which I was just one.  So name collisions,  
and the resulting mis-identity, are not such a narrow corner case.
(c) The use case in which RADIUS is involved in SNMP access  
authorization is likely similar to the use case in which NIS us used  
for UNIX workstation login.   In other words, either you choose to  
centralize your authentication and authorization or you don't.  While  
there is alway the need for a [small] number of locally maintained  
access credentials for "emergency" login usages, it seems odd to me  
that a real-world deployment would be using RADIUS for "outsourced"  
identity management and at the same time there would be a manually  
configured set of user identities in the VACM MIB tables that requires  
constant synchronization with the user configured in RADIUS.
For these reasons, I think that the particular scenario in which an  
existing, manually-configured, non-volatile, vacmSecurityToGroup table  
row is expected to correctly match the securityName dynamically  
derived from RADIUS relies on "special circumstances", i.e. careful  
manual coordination of potentially disjoint name spaces.  I think this  
opens up the *potential* for a significant security risk.  In short, I  
would not automatically assume that the SNMP security manage knew what  
he/she was doing.  :-)
Regards,

Dave

David B. Nelson

Elbrys Networks, Inc.

+1.603.570.2636
www.elbrysnetworks.com

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 8 Mar 2010 10:03:38 -0500

I previously opined that removing the error counters from the MB  
module in this document was a mistake.

Randy observed that notifications would often be more helpful in  
resolving the errors than would simple counters.  I agree.

Randy also observed that implementors could use implementation  
dependent means, including appropriate syslog messages.  Yes, they  
could.

My concern is that if we don't include either counters or notification  
objects in the MIB module, that implementers will be tempted to skip  
over including any form of error indications.  We could beef up the  
security considerations text, to make that alternative less  
attractive.  Either way, I think *something* needs to be done about  
these potential error conditions.  While the counters are simplistic,  
much as that "check engine" idiot light on my dashboard, they at least  
indicate the need for investigation.  They also have the advantage of  
being simple to implement.  Not all of the originally proposed  
counters fall into this category, but some of them do.  I'm thinking  
of the ones that signal a
*possible* disconnect or lack of coordination between the RADIUS  
system administrator and SNMP security administrator.

Leaving it up the the initiative of conscientious implementers to  
handle these potential security mis-configurations in an ad-hoc  
fashion is not a good idea.  We should aim higher, I think.

Regards,

Dave

David B. Nelson

Elbrys Networks, Inc.

+1.603.570.2636
www.elbrysnetworks.com

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 8 Mar 2010 10:29:50 -0500

Editorial corrections:

Section 1:

s/from RADIUS or other AAA/from RADIUS or another AAA/

Old text:

  o    The Secure Shell Transport Model for SNMP [RFC5592] defines a
       Secure Shell Transport Model and Remote Authentication Dial-In
       User Service (RADIUS).

New text:

  o    The Secure Shell Transport Model for SNMP [RFC5592] defines a
       Secure Shell Transport Model.

Old text:

    This memo defines an extension to the View-based Access Control
    Model to obtain authorization information for an authenticated
    principal, from RADIUS or equivalent AAA service supporting a
    Transport Security Model.

New text:

    This memo defines an extension to the View-based Access Control
    Model to obtain authorization information for an authenticated
    principal, from RADIUS or an equivalent AAA service when used
    with a Transport Security Model.

Section 4.3:
Old text:
o     the model provides an indication of the establishment session for
       a particular user, identified using a SecurityName, and provides
       the corresponding value of vacmGroupName to be used, based on
       information provided by the AAA service in use;
New text:

o     the model provides an indication of the establishment of a  
session for
       a particular user, identified using a SecurityName, and provides
       the corresponding value of vacmGroupName to be used, based on
       information provided by the AAA service in use;

Section 9:

    This integration strongly assumes that RADIUS (or some other AAA
    service) is at least as trusted as the security administrator with
    access rights to the vacmSecurityToGroupTable.  It assumes that the
    transport security model can be trusted to pass through the users'
    security name and the group name provided by the AAA service.  It
    also trusts the transport security model to enforce any session
    timeouts imposed by the RADIUS server, and to provide an indicate
    whenever a session ends.
s/an indicate/an indication/
    The algorithms in this memo make heuristic use of the StorageType of
    entries in the vacmSecurityToGroupTable to distinguish those which
    have been provisioned by a security administrator (which would
    presumably not be configured as "volatile") and those dynamically
    generated.  In making this distinction, it assumes that those  
entries
    explicitly provisioned by a security administrator and given a
    non-"volatile" status are not to be dynamically over-ridden.
I don't think it's reasonable, or generally safe, to automatically   
assume that the SNMP security administrator is "clueful" and the  
RADIUS system administrator is "clueless".  That would seem to be the  
implication of always favoring the statically configured information  
over the dynamically derived information.  IMHO, the only thing that  
can be safely inferred from this type of conflict is that the two  
individuals are not coordinating with each other.  That raises a "red  
flag" and SHOULD result in an investigation of the root cause of the  
apparent conflict.
    Users
    of this memo need to be aware of this operational assumption, which,
    while reasonable, is not necessarily universal.
Um...  yeah.  I think this is insufficiently sternly worded advice.
    The design of VACM ensures that if an unknown policy (group name) is
    used in the VacmSecurityToGroupTable, no access is granted.  A
    consequence of this is that even in the presence of a malfunctioning
    or compromised AAA server, no user can gain access rights not  
already
    granted to some group.
It is reasonable to "fail safe" by not granting access in that case of  
an apparent misconfiguration or lack of policy coordination among  
system and security administrators.   On the other hand, why is it  
more likely that the AAA server is malfunctioning or compromised?   
This language seems to give greater weight (credence) to the actions  
and configurations of the SNMP security administrator in setting up  
the VACM MIB modules.  It seems to me that either source of  
information is equally subject to malfunction, misconfiguration or  
compromise.   Of course, if the security and access control mechanisms  
of the managed entity have indeed been compromised, all bets are off,  
no matter what RADIUS may have to say in the mater.

Regards,

Dave

David B. Nelson

Elbrys Networks, Inc.

+1.603.570.2636
www.elbrysnetworks.com

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 08 Mar 2010 13:41:23 -0500

--On Monday, March 08, 2010 09:47:17 AM -0500 "David B. Nelson" 
<[email-masked]> wrote:

> I've said this before, but I'll say it again, hopefully in clearer terms.
> I think that the notion of the *same* principal identity that comes from
> RADIUS (or other AAA) having already been "put in place on this system"
> is highly dubious.

I disagree.  You make the argument that if RADIUS and some SNMP device are 
not administered by the same person, they are completely coordinated and 
further the SNMP device administrator is a boob who has no clue what he is 
doing.  Certainly this is possible, and even somewhat common, but it is by 
no means the only case.

In a large enterprise (or a sub-unit of such an enterprise), it is usually 
the case that every person has a well-known username assigned by a central 
authority.  Unlike "Dave Nelson" at the time you worked for DEC, these 
usernames are unique, always refer to the same person, and can be looked up 
in a common directory.  They are generally mapped in a straightforward way 
to names used by various authentication services, including RADIUS.  At 
Carnegie Mellon, I have the same username in at least three different 
organizational units between which username assignment is pretty much the 
_only_ thing we coordinate.

It is thus not terribly unlikely that an administrator of a device might 
create locally-managed accounts for one or more users, using the same 
centrally-assigned username.  If an administrator does such a thing, 
chances are he intended for his entry to override whatever might come from 
RADIUS, and not the other way around.

> (a) There is nothing in the documented protocol or elements of procedures
> that guarantees that the content of an SNMP securityName bears any
> relationship to the content of a RADIUS User-Name *unless* the former is
> dynamically obtained from the later, in the context of a single secure
> transport session.

True, but in practice they will both be derived from the common username 
directory.

> circumstances" there is no guarantee that independently,
> manually-configured but identical user names actually refer to the same
> user.

True, but they often do; see above.

> (c) The use case in which RADIUS is involved in SNMP access authorization
> is likely similar to the use case in which NIS us used for UNIX
> workstation login.   In other words, either you choose to centralize your
> authentication and authorization or you don't.

False.  A far more common case is to choose to centralize _most_ 
authentication, but have a few locally-maintained accounts on each 
host/device/whatever.

> it seems odd to me that a real-world deployment
> would be using RADIUS for "outsourced" identity management and at the
> same time there would be a manually configured set of user identities in
> the VACM MIB tables that requires constant synchronization with the user
> configured in RADIUS.

Well, that's true.  The manually-configured thing is manually configured. 
Its data didn't come from RADIUS, and it doesn't require "synchronization" 
with RADIUS.  Your statement seems predicated on the idea that RADIUS is 
the authoritative source of all information, which I suspect is almost 
never the case.  It's far more common for the RADIUS server to get its data 
from some other source, which is also accessed in other ways.

> I think this opens up
> the *potential* for a significant security risk.  In short, I would not
> automatically assume that the SNMP security manage knew what he/she was
> doing.  :-)

No, you probably wouldn't, since you seem to apply the RADIUS worldview in 
which the RADIUS server is authoritative for what everyone else _MUST_ do, 
rather than the provider of information that it actually is.

An SNMP implementation must assume that the SNMP security manager knew what 
he was doing.  To do otherwise is to usurp that person's role as the 
definer of policy, and instead place the implementor in that role.

-- Jeff

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 8 Mar 2010 14:10:09 -0500

>  At Carnegie Mellon, I have the same username in at least three  
> different organizational units between which username assignment is  
> pretty much the _only_ thing we coordinate.

Is the authentication, i.e. the credentials you present, also  
coordinated, or only the name?

I fully agree that such a system *can* work, given that the requisite  
manually coordination occurs.  My complaint is that nowhere in this  
document does it make such manual coordination a prerequisite for  
secure operation.  You may claim that's simply common sense.  i'd like  
to see it written down if we are to rely upon it.

> It is thus not terribly unlikely that an administrator of a device  
> might create locally-managed accounts for one or more users, using  
> the same centrally-assigned username.  If an administrator does such  
> a thing, chances are he intended for his entry to override whatever  
> might come from RADIUS, and not the other way around.

OK, but such arrangement seem to me to be a mistake waiting to  
happen.  YMMV.

>> procedures
> True, but in practice they will both be derived from the common  
> username directory.

I'm always nervous when the identity is authenticated in one name  
space / administrative domain and then authorized (without further  
authentication) in *another* name space / administrative domain.  As  
you have suggested, thus can be safe if care is taken to keep the use  
of names synchronized across all these services.  I claim that  
requires "special considerations", and even if it's a fairly common  
use case, we ned to document the "special considerations"

>> authorization

But even in those cases, the locally maintained accounts are both  
authenticated and authorized using local data, right?

> Well, that's true.  The manually-configured thing is manually  
> configured. Its data didn't come from RADIUS, and it doesn't require  
> "synchronization" with RADIUS.

My concern is the separation of authentication and authorization.   
We've had this discussion before, BTW.  I haven't changed my opinion.

> It's far more common for the RADIUS server to get its data from some  
> other source, which is also accessed in other ways.

RADIUS may indeed consult other sources for both authentication and  
authorization, but once it binds those two items into an Access-Accept  
they need to remain bound.  The RADIUS server is free make such trust  
model choices, the RADIUS client typically is not.  (Well, of course,  
any implementation is possible.  I'm talking about what's common.)

> No, you probably wouldn't, since you seem to apply the RADIUS  
> worldview in which the RADIUS server is authoritative for what  
> everyone else _MUST_ do, rather than the provider of information  
> that it actually is.

Well, that is the standard RADIUS world-view.   I understand that this  
is a "collision" of different system-level assumptions and trust models.

> An SNMP implementation must assume that the SNMP security manager  
> knew what he was doing.  To do otherwise is to usurp that person's  
> role as the definer of policy, and instead place the implementor in  
> that role.

I disagree.  Once the authentication and authorization policy  
decisions are "outsourced" to RADIUS, then SNMP is no longer  
authoritative.  Right?  How can two separate entities both be  
[equally] authoritative?

Regards,

Dave

David B. Nelson

Elbrys Networks, Inc.

+1.603.570.2636
www.elbrysnetworks.com

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 08 Mar 2010 14:53:11 -0500

> coordinated, or only the name?

Those OU's operate separate Kerberos realms and other infrastructure.  They 
communicate, of course, such that credentials from one can be used to talk 
to another.  But separately, the username space is coordinated -- no new 
user can be created in any of them with a name that is already in use in 
another, unless the accounts belong to the same person (in which case we 
rather strongly encourage the names to be the same).

> document does it make such manual coordination a prerequisite for secure
> operation.  You may claim that's simply common sense.  i'd like to see it
> written down if we are to rely upon it.

I don't think we're relying on any such thing.  What we say is, if there is 
locally-configured authorization policy for a given username, that 
overrides authorization policy provided by RADIUS.  In other words, 
ultimate power rests with the local administrator, not with RADIUS.

> I'm always nervous when the identity is authenticated in one name space /
> administrative domain and then authorized (without further
> authentication) in *another* name space / administrative domain.  As you
> have suggested, thus can be safe if care is taken to keep the use of
> names synchronized across all these services.  I claim that requires
> "special considerations", and even if it's a fairly common use case, we
> ned to document the "special considerations"

See, you're assuming there are multiple administrative domains involved 
there.  My desire to use RADIUS for authentication but _not_ for 
authorization, or the other way around, or to not use RADIUS at all, does 
not mean that the names are unrelated.  For a moment, ignore my earlier 
example, which was intended only to make a specific point.  Within my 
infrastructure, there are multiple means of authentication and a wide 
variety of sources of authorization and policy.  The names, however, always 
mean the same thing.  If they didn't, then policy statements would be 
meaningless because there would be no way to tell if a given user was the 
one the policy talked about.

If you think the document needs to say something along the lines of VACM 
entries being meaningless if the security names listed don't match whatever 
authentication scheme you're using, go ahead.  But I think that's 
fundamental to VACM, and not something we're introducing here.  On the 
other hand, since we've already stated that the RADIUS User-Name gets 
mapped into the SNMP securityName space, I think that issue is covered.

Incidentally, I would point out that any concern you have about name 
mismatches when using RADIUS for authentication but applying local policy 
_also_ apply when obtaining policy from RADIUS but using, say, SSH public 
key authentication, or when using SSH public key authentication with local 
policy, or when RADIUS verifies users by getting Kerberos tickets but 
obtains authorization data via LDAP.  In every case, if the names don't 
mean the same thing, you lose.

> authenticated and authorized using local data, right?

Not necessarily.  For example, the normal model in our environment is for 
users to be authenticated via Kerberos, but for login access to a given 
host to be controlled by policy local to the host.  Kerberos certainly 
doesn't provide that policy; as an authentication service, authorization is 
(mostly) out of its scope.

At the same time, it is common for machines belonging primarily to one user 
to be set up so that that user can log in to the _same account_ using 
either his Kerberos password or one stored in the local password database. 
In the latter case, you don't get to use most network services until you 
get tickets, but you can log in when the network is broken or you're not 
connected to it.

> model choices, the RADIUS client typically is not.

Why?  Why in your model does the RADIUS server get to make all the policy 
decisions, rather than individual services making policy decisions?  I 
don't think I've seen this approach anywhere else.
> Well, that is the standard RADIUS world-view.   I understand that this is
> a "collision" of different system-level assumptions and trust models.
>
> I disagree.  Once the authentication and authorization policy decisions
> are "outsourced" to RADIUS, then SNMP is no longer authoritative.  Right?
> How can two separate entities both be [equally] authoritative?

Wrong.  Authority in this case isn't "outsourced"; it's _delegated_.  The 
SNMP administrator remains in ultimate control, but delegates _some_ 
authority for decision-making to RADIUS.  How much authority to delegate 
should and does lie with the administrator.  Our choice is to either make 
it easy for the administrator to delegate only some authority, or insist 
rather loudly that if he wants RADIUS's help at all he must put RADIUS in 
charge and abdicate all power.  I'm not interested in the latter, either as 
a protocol designer or as an operator.

-- Jeff

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 8 Mar 2010 15:38:58 -0500

On Mar 8, 2010, at 2:53 PM, Jeffrey Hutzelman wrote:

>> space /
> See, you're assuming there are multiple administrative domains  
> involved there.

In the absence of any normative prohibition on *having* multiple  
administrative domains, I assume there can *be* multiple  
administrative domains.

>  My desire to use RADIUS for authentication but _not_ for  
> authorization, or the other way around, or to not use RADIUS at all,  
> does not mean that the names are unrelated.

The names from separate sources can be *know* to be related by one of  
two means: (a) the protocols involved bind them in some secure way, or  
(b) an administrative policy asserts that no apparently duplicate  
names will ever apply to distinct individuals.  The first method can  
be verified at run time by software, e.g. by security and/or  
cryptographic methods.  The second method is an "act of faith" and  
requires that humans don't (often) make mistakes.

> The names, however, always mean the same thing.  If they didn't,  
> then policy statements would be meaningless because there would be  
> no way to tell if a given user was the one the policy talked about.

Exactly my point!

> If you think the document needs to say something along the lines of  
> VACM entries being meaningless if the security names listed don't  
> match whatever authentication scheme you're using, go ahead.

I think perhaps is does, because in the only other Security Model we  
have available for use with VACM,  i.e. USM, the names are forced to  
be in synchronization because they exist in the locally configured USM  
MIB module's data store.  There's only one party involved, so there  
can be no lack of coordination.

> mismatches when using RADIUS for authentication but applying local  
> policy _also_ apply when obtaining policy from RADIUS but using,  
> say, SSH public key authentication, or when using SSH public key  
> authentication with local policy, or when RADIUS verifies users by  
> getting Kerberos tickets but obtains authorization data via LDAP.   
> In every case, if the names don't mean the same thing, you lose.

Indeed.  Which is why I think that the applicability statement for  
this document needs to be scoped down to deployments where the  
authentication and authorization information comes from the same  
entity, *or* an administrative policy ensures that all entities have a  
manually-enforced consistent view of user identity.

>> decisions
> Wrong.  Authority in this case isn't "outsourced"; it's _delegated_.

OK, that's another way of looking at it.

Regards,

Dave

David B. Nelson

Elbrys Networks, Inc.

+1.603.570.2636
www.elbrysnetworks.com

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 08 Mar 2010 16:03:45 -0500

--On Monday, March 08, 2010 03:38:58 PM -0500 "David B. Nelson" 
<[email-masked]> wrote:

> Indeed.  Which is why I think that the applicability statement for this
> document needs to be scoped down to deployments where the authentication
> and authorization information comes from the same entity, *or* an
> administrative policy ensures that all entities have a manually-enforced
> consistent view of user identity.

Having policy administratively originate from the same place is not the 
same thing as having an SNMP engine get authentication and authorization 
data exclusively via RADIUS.  The goal here is to allow people to make use 
of their existing infrastructure to get something useful done, and often 
that's going to mean getting some but not all of this data via RADIUS.  We 
can certainly say "make sure all your foo->securityName mappings are 
consistent, or you'll be sorry".  But I don't think that's grounds for 
removing a feature that allows device administrators to override 
authorization policy from RADIUS.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 8 Mar 2010 16:18:44 -0500

On Mar 8, 2010, at 4:03 PM, Jeffrey Hutzelman wrote:

> Having policy administratively originate from the same place is not  
> the same thing as having an SNMP engine get authentication and  
> authorization data exclusively via RADIUS.

Right.   As I said in my last reply, there are protocol-domain  
assurances and there are policy-domain assurances.  Both can be  
equally effective.  Only the former can be validated at run time.

> The goal here is to allow people to make use of their existing  
> infrastructure to get something useful done, and often that's going  
> to mean getting some but not all of this data via RADIUS.

Ummm...   Perhaps.

> We can certainly say "make sure all your foo->securityName mappings  
> are consistent, or you'll be sorry".

I would recommend doing so.  The Security Considerations section is a  
natural place for this.

> But I don't think that's grounds for removing a feature that allows  
> device administrators to override authorization policy from RADIUS.

OK.  As long as we clearly warn implementers and operators about the  
"you'll be sorry" risks of mis-identification mentioned just above, I  
agree we can leave that part in the document.  If I were implementing  
this, I think I'd make the override capability a locally configureable  
option, just to be on the safe side.  Of course, that just means you'd  
have to disengage the safety *and* pull the trigger in order to shoot  
yourself in the foot.  :-)

Regards,

Dave

David B. Nelson

Elbrys Networks, Inc.

+1.603.570.2636
www.elbrysnetworks.com

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 08 Mar 2010 16:29:30 -0500

> yourself in the foot.  :-)

OK then.  I think now all we need is some text.

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Mar 2010 13:51:17 -0800

Hi -

> From: "David B. Nelson" <[email-masked]>
> To: "Jeffrey Hutzelman" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, March 08, 2010 12:38 PM
> Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 2
...
> can be no lack of coordination.

There's a crucial difference between isms-style solutions and USM.  By
design, usmUserTable is indexed by usmUserName (what shows up in protocol),
but maps it to another object, usmUserSecurityName, which is what would be
passed on to VACM.  This is to allow for cases where "synchronization" departs
from the monotonous ideal across multiple systems, and may be practically unavoidable
in cases of federation.  But it also requires things to be set up in advance, which
would defeat the purpose of an isms-style solution.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Mar 2010 13:52:51 -0800

Hi -

> From: "Jeffrey Hutzelman" <[email-masked]>
> To: "David B. Nelson" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Monday, March 08, 2010 1:29 PM
...
> OK then.  I think now all we need is some text.

Will one of you be making a proposal, or should I make something up?

Randy

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 8 Mar 2010 16:53:21 -0500

> OK then.  I think now all we need is some text.

Here's some proposed text to add to the Security Considerations section:

In order to ensure that the access control policy that is ultimately  
applied by means of the mechanisms described in this document  
accurately represents the intended policy for any given principal,  
care needs to be applied in the mapping of the authenticated user  
(principal) identity to the securityName that is used to make the  
access control decision.  Generally speaking, there are two approaches  
to ensure the consistency of identity:

	 (a) that the RADIUS User-Name (or other AAA-authenticated identity)  
is dynamically propagated into the securityName object(s) of the  
vacmSecurityToGroup table, or

	 (b) in the case of a pre-configured entry in the vacmSecurityToGroup  
table, with a name that apparently matches the authenticated  
principal's User-Name, that administrative policy ensures a manually- 
enforced consistency of identity between the authenticated principal's  
User-Name and the securityName in the vacmSecurityToGroup table row  
entries.

In the later case, if care is not taken, it is possible that  
inconsistent re-use of the same name for different entities or  
individuals (principals) will cause the incorrect access control  
policy to be applied for the authenticated principal.  This may result  
in greater or lesser access rights than the administrative policy  
intended.  Inadvertent mis-identification in such cases may be  
undetectable by the SNMP engine or other software elements of the  
managed entity.

Regards,

Dave

David B. Nelson

Elbrys Networks, Inc.

+1.603.570.2636
www.elbrysnetworks.com

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 8 Mar 2010 16:55:06 -0500

> Will one of you be making a proposal, or should I make something up?

I have submitted some text for consideration.

Regards,

Dave

David B. Nelson

Elbrys Networks, Inc.

+1.603.570.2636
www.elbrysnetworks.com

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Mar 2010 14:53:30 -0800

Hi -

The editorial items in this list are fixed, but I'm not sure what to do with
the lengthy comments later on.

> To: <[email-masked]>
> Sent: Monday, March 08, 2010 7:29 AM
> Subject: Re: [Isms] wg last call on the radius / vacm document: ISSUE 4
>
> Editorial corrections:
> 
> Section 1:
> 

Fixed.
 
>     with a Transport Security Model.

Fixed.  (Also, changed "extension" to "supplement" for consistency with
earlier text.)
 
>        information provided by the AAA service in use;

Fixed.
 
> s/an indicate/an indication/

Fixed.

> RADIUS system administrator is "clueless".

I don't think we're making any such assumption.  It's a question of
how to handle information which has been explicitly provisioned to
be persistant, and how to heuristically identify stuff which may be
overwritten with little risk of trampling on an explicitly provisioned
configuration.

>  That would seem to be the  

As a practical matter, since these tables are indexed both by security
model and security name, I think the interesting cases will happen
when systems are upgraded to support this capability, and as the
RADIUS attribute for the group mapping is deployed.  These systems
will likely find themselves needing the administratively configured
mapping for some period of time, until the RADIUS support is
turned on.  At the point, we need to ask ourselves, is it better to
require the security administrator to clean up the vacmUserToGroupTables,
to rely on error notifications to prompt the administrator to clean up the tables,
or to (making a change to the proposed EOP) rely on dynamic
updates to override what had been provisioned as non-volatile
access control policy configuration data?  The current EOP assumes
the first of these three strategies.  I think there are pros and cons to
each of these from a software updgrade, deployment, and operational
perspective.  What I like best about the current EOP is that it is
very simple, offers no surprises, and would be very easy to implement
and test, at least in the code bases I'm familiar with.

> Um...  yeah.  I think this is insufficiently sternly worded advice.

I'm open to proposals for sterner advice.   But before we go too far, I'd
like to know whether anyone has ever seen an operational network where
vacmUserToGroupTable entries were set up as "volatile".  I haven't been
able to think of a realistic use case for such a thing, but that might just
be the fault of my own limited imagination.

> more likely that the AAA server is malfunctioning or compromised?

I don't think we made any such assumption.
   
> no matter what RADIUS may have to say in the mater.

The *intended* perspective is a bit different.  The boilerplate is intended
to address the stuff that is in common with other MIB documents.  VACM
is taken as a given, and the added material is intended to address the
ways in which this document differs from other MIB documents.  The
addition of RADIUS as an information source, and the modification
of VACM configuration data, are the key differences.  I'd like to avoid
repeating the security considerations section of the VACM document,
just as I'd like to avoid repeating the security considerations sections
of the RADIUS documents.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Mon, 8 Mar 2010 18:46:06 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of David B. Nelson

> We've had this discussion before, BTW.  I haven't changed my
opinion.

The SNMPv3 WG also discussed this at length and decided to
deliberately separate 
authentication and authorization, while RADIUS decided to bind them. 
Sure, an operator will need to be careful to coordinate the
securityName used for authentication and the securityname used when
configuring VACM authorization. 
Anytime a securityname must be manually configured in a MIB, such as
in the target-table, the administrator needs to be aware of what the
securityname means.
SNMP admins know this already.

> authoritative.  Right?  How can two separate entities both be  

An organization might delegate some authority to different persons or
mechanisms. 
As the COPS-PR policy-based management experience showed clearly,
network administrators do not completely outsource their authority to
automated protocols. Admins and RADIUS are not equally authoritative.
Admins are the definers of policy; RADIUS simply tells a NAS what the
policy is.
Admins assert the right to override policy-based protocols as needed.

dbh

---

From: "David Harrington" <[email-masked]>
Date: Mon, 8 Mar 2010 19:09:24 -0500

> can be no lack of coordination.

In SNMPv2 party, the authentication and authorization were bound
toghether in a common MIB module for authentication and authorization.
The SNMPv3 WG deliberately (i.e., we deliberated long and hard and
debated the ramifications of the decision) chose to separate
authentication from authorization to permit admins to choose how to
combine them. 

This decision was based on the belief that admins have more authority
than either the authentication mechanism or the authorization
mechanism in use. We decided that we should assume that the SNMP
admins **do** know what they are doing.

Your assumption that SNMP admins do not know what they are doing is
not consistent with SNMPv3 WG consensus. 

Somehow, you have concluded that the admin who configures a
centralized RADIUS server with a set of static rules at some point in
time must know more about the devices being managed than an admin who
has direct knowledge of the local device being managed or the current
local events impacting the local device. I think that's a mistake. 

dbh

---

From: "David Harrington" <[email-masked]>
Date: Mon, 8 Mar 2010 19:56:22 -0500

> >        information provided by the AAA service in use;

That should probably be authenticated principal rather than user.

I'm not comfortable talking about session here; SNMP has no sessions.
The model provides the establishment of a policy for a particular
principal.
The  lifetime of the policy might be tied to the lifetime of a session
of the AAA service in use.

> >     timeouts imposed by the RADIUS server, and to provide 

I don't agree with this text. I do not agree that RADIUS is "at least
as trusted as the security administrator". The security administrator
delegates authority to AAA to inform the SNMP entity about the
security policy. There is no assumption that the transport security
model "can be trusted".

I am not checking the TSM, but I'm pretty sure it never even sees the
group name provided by AAA. And IIRC, TSM knows nothing about
sessions; a session is something a transport model might know about
that is tied to the transport involved. 

> overwritten with little risk of trampling on an explicitly
provisioned

I don't think we're making any such assumption either. What we are
assuming is that an admin has a reason to locally and mnaually
configure an override. 
I don't think it's reasonable, or generally safe, to automatically
assume that the SNMP security administrator is "clueless" and the
RADIUS system administrator is "clueful", especially about current
local operating conditions.

> > flag" and SHOULD result in an investigation of the root 

And who should do that investigation? the RADIUS server or the
clueless security administrator? Remember, only somebody who has
permission to change the VACM tables can configure the override. I
would like to think that the security administrator is at least as
trusted as the RADIUS server.

> access control policy configuration data?  

I strongly recommend you acquaint yourself with the COPS-PR fiasco,
where
COPS-PR was allowed to override administrator changes. There is a
reason you
do not see COPS-PR mentioned positively in the O&M area - the
operators hated
the assumption that some server was trusted more than an administrator
who is aware of current operational conditions, which might be
different than when the policy server was configured. Operators need
to be able to override automated policy, and not have the policy
override their overrides. 

dbh

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Mar 2010 18:07:55 -0800

Hi -

> From: "David Harrington" <[email-masked]>
> To: "'Randy Presuhn'" <[email-masked]>; <[email-masked]>
> Sent: Monday, March 08, 2010 4:56 PM
> Subject: RE: [Isms] wg last call on the radius / vacm document: ISSUE 4
...

Fixed.
 
> I'm not comfortable talking about session here; SNMP has no sessions.

SNMP doesn't, but the secure transport models we're supporting here do.

> of the AAA service in use.

Indirectly, this gets back to the question of how general we want to make this.
For all the AAA examples discussed so far, unless I've overlooked something,
the dynamic authorization begins and ends with the session.

The dynamic VACM entries created here are *always* limited to the
specific security model associated with the authentication / authorization.
For a VACM entry to outlive the last remaining session would be pointless -
after the end of the last session, there can be no requests with that SecurityModel/
SecurityName pair to authorize.  Likewise, since the authorization to even
establish a session comes from the AAA, there is no value in having a
pre-existing entry for that particular SecurityModel/SecurityName pair.

So, I think no change is needed here, though I'm open to alternative
wordings for "session".

> security policy. There is no assumption that the transport security

Point taken.  However, I'm not sure what to do with the existing text.
Does someone have a concrete text proposal?

> that is tied to the transport involved. 

I'm not sure what to do here.  We're dealing with abstractions that may
or may not have any recognizable counterpart in an implementation.
Text would be welcomed.

....
> trusted as the RADIUS server.

I'm of two minds on this.  I can understand the reasoning that such a conflicts
should be rare. and might merit investigation. But I also can understand the
need to apply a more stringent or more liberal policy to a particular user on
a particular system than might be the case throughout the rest of the enterprise.
My personal preference would be to get some deployment experience
with the MIB as it is, and, if we find this is a real operational problem, to
address it in a revision to the MIB module.  I think that's preferable to
potentially over-engineering it from the outset.

> override their overrides. 

? That's one of the (unwritten) reasons why the current EOP favors
administratively configured policy over what is dynamically delivered.
I don't see a need to make any changes here.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Mar 2010 08:04:15 +0100

On Mon, Mar 08, 2010 at 03:47:17PM +0100, David B. Nelson wrote:
>    vacmSecurityToGroupTable, and the row's StorageType is anything other
> I've said this before, but I'll say it again, hopefully in clearer terms.  I think that the notion of the *same* principal identity that comes from RADIUS (or other AAA) having already been "put in place on this system" is highly dubious.  At best, it relies on special circumstances.  Here's my reasoning on this:
> 
> (a) There is nothing in the documented protocol or elements of procedures that guarantees that the content of an SNMP securityName bears any relationship to the content of a RADIUS User-Name *unless* the former is dynamically obtained from the later, in the context of a single secure transport session.
> 
> (b)  In the absence of careful coordination on the part of the RADIUS system administrator and the SNMP system administrator, i.e. "special circumstances" there is no guarantee that independently, manually-configured but identical user names actually refer to the same user.  For example, it is possible that the RADIUS system administrator is using the name "dave" for Dave Nelson and the SNMP system administrator is using the name "dave" for Dave Harrington.  I understand that the likelihood of such name collisions is reduced if fuller versions of the names are used, but 'll observe that at one point in time there were *five* Dave Nelson's working for Digital Equipment Corporation, of which I was just one.  So name collisions, and the resulting mis-identity, are not such a narrow corner case.
> 
> (c) The use case in which RADIUS is involved in SNMP access authorization is likely similar to the use case in which NIS us used for UNIX workstation login.   In other words, either you choose to centralize your authentication and authorization or you don't.  While there is alway the need for a [small] number of locally maintained access credentials for "emergency" login usages, it seems odd to me that a real-world deployment would be using RADIUS for "outsourced" identity management and at the same time there would be a manually configured set of user identities in the VACM MIB tables that requires constant synchronization with the user configured in RADIUS.
> 
> For these reasons, I think that the particular scenario in which an existing, manually-configured, non-volatile, vacmSecurityToGroup table row is expected to correctly match the securityName dynamically derived from RADIUS relies on "special circumstances", i.e. careful manual coordination of potentially disjoint name spaces.  I think this opens up the *potential* for a significant security risk.  In short, I would not automatically assume that the SNMP security manage knew what he/she was doing.  :-)

But the quoted text essentially says that local configuration takes
precedence over RADIUS. This is similar to what happens in NIS or
similar services. What do you propose how to handle this situation?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Mar 2010 08:06:20 +0100

> fashion is not a good idea.  We should aim higher, I think.

So is your proposal to reinstall the counters (exactly those we had in
the revision before they got removed)? Or is your proposal to add
suitable notifications?

/js

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 9 Mar 2010 06:19:46 -0500

Juergen Schoenwaelder writes...

> So is your proposal to reinstall the counters (exactly those we
> had in the revision before they got removed)? 

No.  Not exactly.  I agree, for example, that the counter of "out of memory"
occurrences is a bit silly.

> Or is your proposal to add suitable notifications?

I'd need assistance with crafting that proposal, as I'm a bit rusty at
notifications.

What I'd like to accomplish is some method of signaling when a potential
misconfiguration has occurred.  One event in question is when a RADIUS
User-Name collides with an existing securityName in the
vacmSecurityToGroupTable.  Another event is when the RADIUS
Management-Policy-Id doesn't match any pre-configured VACM groups.  As was
extensively debated under ISSUE 2 yesterday, it will not be possible to
axiomatically determine what is a misconfiguration and what is an
intentional override, when it comes to the User-Name.  Only the human in
charge of the device configuration will know.

Given the potential for a lot of false alarms, in the case of intentional
overrides, it seems that counters that can simply be ignored would be less
burdensome to manage, as well as to implement.  I'm open to suggestions as
to whether it should be counters or notifications.

One could also argue that the misconfiguration errors I'm concerned about
simply won't happen in "real life" and that we need do nothing.  I'm not
convinced that's the case.  In any event, I'd appreciate feedback from
others on the list as to whether this is an issue we need to address.

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 9 Mar 2010 06:21:59 -0500

> What do you propose how to handle this situation?

Text to be added to the Security Considerations Section was posted to the
list yesterday.

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 9 Mar 2010 06:34:51 -0500

Randy Presuhn writes (in response to Dave Harrington)...

> Does someone have a concrete text proposal?

If you don't trust RADIUS or the system administrator who configures its
polices, then don't use it.  I think I see organizational dynamics arguments
creeping into a protocol discussion.  That's always a bad sign, IMHO.  If
there's bad organizational karma between the SNMP security administrator and
the corporate RADIUS administrator, fight that out in the personnel domain,
not the protocol domain, please.

As to trusting the TSM (or TM), I think what's mean here is that one trust
the implementation to pass along the information, including User-Name and
Management-Policy-Id attributes and session start and end events, that the
documents says it has to pass along.

> or may not have any recognizable counterpart in an implementation.

This is another situation where the architectural model is simply getting in
the way.  I had originally suggested we use one of those "magic caches" as
we did for the TSM and TM work.  It was suggested by others on the list that
we leave the implementation detail more open ended for this document.  The
result is that it's not exactly clear how the information flows, just that
it MUST flow.

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 9 Mar 2010 06:41:19 -0500

Randy Presuhn writes...

> The editorial items in this list are fixed ...

Thanks.

> ... but I'm not sure what to do with the lengthy comments
> later on.

I suspect that the important points will be covered by the Security
Considerations section text that I posted to the list yesterday to resolve
ISSUE 2.

---

From: "David Harrington" <[email-masked]>
Date: Tue, 9 Mar 2010 08:55:01 -0500

Hi,

Sorry, I'm bringing multiple issues together because they interact
somewhat.

1) *** modularity police alert ***

I agree the architecture versus implementation details get in the way
in this instance. However, there are ways to work around those
constraints.

We are not allowed to ignore the architectural data flow constraints
described by the ASIs - we cannot, for example, say that "TSM passes
information" that architecturally it never gets from an ASI or from a
process clearly identified as implementation-dependent. So any place
the text says "the security model passes information" that it doesn't
get from the ASIs, or explicitly from implementation dependent means
should be eliminated. Assume the security model never sees or touches
such information.

Just say that the VACM extension gets the AAA attributes from a
transport model in an implementation-dependent manner. 

2) *** trusting modules ***

Part of my response was about anthropomorphising(?) the
subsystems/models in an SNMP engine. We don't "trust" one portion to
deliver something unchanged. 

We design the protocol to deliver it unchanged. And if we make it
implementation-dependent, then we should spell out the expectations
that the attributes will be delivered unchanged between portions of
the system.  

There is no question of "trust". There is a question of protocol
requirements.

3) *** trusting humans ***

There is a question of trust when it comes to human administrators.
But we are designing protocols, not organizations. 

trust but verify - we trust both admins because they should be
authenticated, and both the RADIUS server and the local operator are
allowed to modify VACM tables. If the organization doesn't trust the
local SNMP admin, then they should not be given permission to modify
VACM tables. Done.

We have to assume that all authenticated administrators who are given
permission to modify VACM tables are trusted, whether they are RADIUS
admins or SNMP admins. 

We don't allow one to override the other based on whether we trust
this one more than the other. A RADIUS admin is not trusted more than
an SNMP admin; an SNMP admin is not trusted more than a RADIUS admin. 

We need to assume both RADIUS and SNMP admins are trusted equally,
since both have permission to modify VACM (security) tables.

4) *** the need for overrides ***

We do need to make a decision about which should be allowed to
override the other's configuration. 

The IETF OPS community has dealt with this issue before. We went to
great lengths to discuss operator needs in the dilbert discussions,
the "SNMP World Tour" to operator fora, and the IAB NM workshop. A
great deal of that discussion was about policy-based configuration
(mainly promoted by COPS-PR and academic research) and operator-driven
configuration. 

The operators were quite clear - policy based configuration is a nice
way to automate processes, but a programmatic policy server does not
have the ability to recognize unusual circumstances and respond to
them; a human has better capability to recognize when a policy is
wrong for the current special circumstances, and a network management
protocol using a policy-based approach MUST be able to be overridden
by a human operator.

COPS-PR had this capability. There was an on-off swicth in COPS-PR
that allowed an operator to disable policy-based configuration. That
allowed an operator to go in and modify the configuration, in order to
troubleshoot a problem or stop an attack or whatever short-term
problem needed to be solved. When COPS-PR was re-enabled, it would
overwrite the changes made by the admin. This was found to be
unacceptable by operators.

5) *** override cleanup ***

Because an operator should be allowed to override policy-based config,
and not be subsequently overridden by the policy manager, it is
important that an operator clean up the static entries when he is
done. But an operator in the middle of troubleshooting problems might
easily forget to clean up a temporary override, and the device will
end up being "out of policy".

Therefore, I support Dave Nelson that we should have a
counter/notification to alert an operator that a policy is being
overridden by a static entry. But we need to make sure the
notification doesn't get in the way of an operator doing their job.

The organization may be able to eliminate the conflict between the
trusted RADIUS server and the trusted local operator by changing the
RADIUS policy to match the needed override settings. Maybe an
organization woudl prefer that the conflict remain - the override
might provide super-user privilieges, and the admins might prefer to
not always work in superuser mode, and to have a warning when they are
in super-user mode. Such a notification should probably be able to be
throttled somehow. Whether that notificastion goes to the RADIUS admin
or the SNNMP admin is a matter of RFC3413 configuration. They can
presumably eliminate the notification if they want to, using the
RFC3413 target and filter tables. I am not sure how to throttle the
notification.

dbh

> Behalf Of Dave Nelson
> Sent: Tuesday, March 09, 2010 6:35 AM
> To: [email-masked]
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Tue, 9 Mar 2010 10:06:00 -0500

Hi,

I believe that notification rate control should be discussed and
possibly addressed by
both the radius/vacm and the dtls-tm documents. 

Some network devices have the ability to configure throttle threshold
and throttle interval
values globally.  Typically, the default threshold is 100
(notifications) within an
interval of 5 seconds.

Below are a few suggested solutions we can consider.

A. Add text in both documents stating that it is strongly recommended
that the device
support global throttle threshold/interval scalar objects for
notifications to avoid the
possibility of network administrators being overcome with a potential
flood of messages. 

B.  Define throttle threshold/interval scalar mib objects for
notifications specifically
in the dtls and vacm/radius mibs to control the dtls and vacm/radius
rate of notifications 
respectively.

- Andy Donati  

DH> Therefore, I support Dave Nelson that we should have a
counter/notification to
DH> alert an operator that a policy is being overridden by a static
entry. But we
DH> need to make sure the notification doesn't get in the way of an
operator doing
DH> their job.

DH> The organization may be able to eliminate the conflict between the
trusted
DH> RADIUS server and the trusted local operator by changing the RADIUS
policy
DH> to match the needed override settings. Maybe an organization would
prefer
DH> that the conflict remain - the override might provide super-user
privileges,
DH> and the admins might prefer to not always work in superuser mode,
and to have
DH> a warning when they are in super-user mode. Such a notification
should probably
DH> be able to be throttled somehow. Whether that notificastion goes to
the RADIUS
DH> admin or the SNNMP admin is a matter of RFC3413 configuration. They
can presumably
DH> eliminate the notification if they want to, using the
DH> RFC3413 target and filter tables. I am not sure how to throttle the
notification.

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 9 Mar 2010 10:41:42 -0500

> transport model in an implementation-dependent manner.

Sounds good to me.

> There is no question of "trust". There is a question of protocol

Agreed.  Any "trust" of systems or software is implied by successful  
authentication of the principal.

> since both have permission to modify VACM (security) tables.

Agreed.  Equally trusted.  However, local information gets precedence  
over remote information.

> end up being "out of policy".

Correct.

> notification doesn't get in the way of an operator doing their job.

Do you have a preference for either counters or notifications?

Regards,

Dave

David B. Nelson

Elbrys Networks, Inc.

+1.603.570.2636
www.elbrysnetworks.com

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Mar 2010 17:05:52 +0100

On Tue, Mar 09, 2010 at 04:06:00PM +0100, Donati Andrew-MGIA0477 wrote:
 
> possibly addressed by both the radius/vacm and the dtls-tm
> documents.

So far, the only notifications we have are related to certificate
validation errors in the dtls document. The dtls document has passed
WG last calls.  If you think the throttling of these notifications is
necessary, you have to post an explicit IETF last call comment.

/js

---

From: "David Harrington" <[email-masked]>
Date: Tue, 9 Mar 2010 11:34:33 -0500

I prefer counters that are reported in notifications.
Then an operator can choose use event-based or polling-based
management.

dbh 

> Sent: Tuesday, March 09, 2010 10:42 AM
> To: [email-masked]
> Subject: Re: [Isms] wg last call on the radius / vacm 
> document: multipleissues
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 9 Mar 2010 10:48:50 -0800

Hi -

> To: "'David B. Nelson'" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, March 09, 2010 8:34 AM
> Subject: Re: [Isms] wg last call on the radius / vacm document:multipleissues
>

But to be of any use at all, such a notification would also need to carry at least
the SecurityModel and the SecurityName.  It would probably better if it also
carried both the old and the proposed values of vacmGroupName, in addition to
the value of the counter (which I assume would *not* be indexed, and would
thus increase according to the sum of all such events).

Now for details:

  - would we notify in the case where the newly proposed value for vacmGroupName
    happens to be equal to the value that is already there?

  - relying on the snmpNotificationMIB to decide whether something goes out (or not)
    is the right thing to do, IMO, but it comes at a signficiant run-time cost, in that in a
    typical implementation architecture it will require all the notification payload to have
    been marshalled, if not actually encoded (in both SMUX and AgentX environments
    there will be PDUs flying around) and that this information will then be evaluated
    against the snmpNotifyFilterTable, and, for the selected targets, evaluated again
    against VACM.  This can be a fair amount of work before the implementation
    reaches the decision that it "doesn't need to do anything."  The counter-argument
    is that this case shouldl be rare, except during initial deployment of this software.

  - I think the "throttling" question isn't terribly important here.  The maximum rate at which
    these could be generated is no greater than the maximum rate at which new sessions are
    accepted and authorized by RADIUS.  The real problem would be experienced at
    an enterprise-wide notification sink when this service is initially deployed, due to the
    fan-in from large numbers of managed devices being polled with short-lived sessions.
    Throttling would be of no help in this scenario.

Randy

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 9 Mar 2010 14:10:40 -0500

Resending from my enrolled email address (this is starting to get  
old...).

> From: "David B. Nelson" <[email-masked]>
> Date: March 9, 2010 2:09:18 PM EST
> To: [email-masked]
> document:multipleissues
> On Mar 9, 2010, at 1:48 PM, Randy Presuhn wrote:
>
> I don't think the EOP anticipates any "newly proposed" values of  
> vacmGroupName.  The only error case, in terms of a newly started  
> RADIUS-authorized session, is if there is not match among the  
> existing vacmGroupName entries.
>
> Right.
> Yes.  I can see the advantage of sending a particular notification  
> only once, but I assume (a) there is no mechanism to support that  
> concept, an (b) if there were, it would still require significant  
> work (and state) internally to make that decision.
>
> Regards,
>
> Dave
>
> David B. Nelson
>
> Elbrys Networks, Inc.
> www.elbrys.com
> [email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 9 Mar 2010 12:00:49 -0800

Hi -

> Sent: Tuesday, March 09, 2010 11:10 AM
> Subject: [Isms] wg last call on the radius / vacm document:multipleissues
...
> existing vacmGroupName entries.

We're thinking about two very different cases.  I was considering the case
where the information from RADIUS corresponded to an existing entry
in the vacmSecurityToGroup table.  You're considering the case where
(regardless of whether there is an existing entry in the vacmSecurityToGroupTable
matching the SecurityModel and SecurityName pair) there is no entry
in the vacmAccessTable with a matching value for the vacmGroupName
index.  I still do not think this latter case is an error condition at all -
it certainly is not an error in a VACM configuration for this condition
to exist.

...
> work (and state) internally to make that decision.

It's worse than that.  The communication amongst the managed systems
necessary to prevent such an amplification attack would be as bad or worse
than the attack itself.  In an enterprise with a large number of identically-
configured devices, as each one is polled by a centralized NMS, the notification
would be generated.  Even if it happens only once, the security alarm sink
might be overwhelmed by the deluge resulting when every device in the enterprise
sends its one notification.  (Worse still if, due to pathological configuration / implementation,
RADIUS is consulted in setting up a transport for each of these notifications,
which, by the way, could potentially result in another notification.)

Randy

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 9 Mar 2010 15:28:45 -0500

On Mar 9, 2010, at 3:00 PM, Randy Presuhn wrote:

> in the vacmSecurityToGroup table.

You're gonna make me dig out the VACM RFC again, aren't you? ;-)

>>   happens to be equal to the value that is already there?

OK.  I'm confused.  If the row exists, why would there be a need to  
create a new value of vacmGroupName in the vacmSecurityToGroupTable?   
Are you asking about the case where the *dynamically* provisioned  
value of group name changes?  It certainly can, and that's not an  
error.  The RADIUS server is allowed to change it's mind, or more  
accurately an system administrator may reconfigure its policy database  
at any time.  On the other hand if there is a conflict with a  
*statically* configured group name, that comes down to the override  
case.

> You're considering the case where (regardless of whether there is an
> existing entry in the vacmSecurityToGroupTable matching the  
> SecurityModel
> and SecurityName pair) there is no entry in the vacmAccessTable with a
> matching value for the vacmGroupName index.

Umm...  yeah, that too.

> I still do not think this latter case is an error condition at all -

Well, it's *certainly* a RADIUS error for the RADIUS server to  
provision conditional / limited access using a non-existent, and  
therefore unenforceable, policy name.  Because of the behavior on the  
VACM end, it's not a security risk, but it's an error.  Let's not  
consider the issues only from an SNMP-centric or a RADIUS-centric  
viewpoint, but rather consider how it all works as a system.    
Admittedly, this isn't a VACM error, but it is a RADIUS/VACM error.

> than the attack itself.

I was only suggesting a behavior within the scope of a *single*  
notification originator.  Filter out duplicates for a given User- 
Name / Management-Policy-Id pair from a single SNMP engine.

> In an enterprise with a large number of identically-configured  
> devices, as
> each one is polled by a centralized NMS, the notification would be  
> generated.

Only if the "error" had occurred at each device, right?

Well, it wasn't a serious suggestion... more like wishful thinking.

Regards,

Dave

David B. Nelson

Elbrys Networks, Inc.

+1.603.570.2636
www.elbrys.com
[email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 9 Mar 2010 13:15:55 -0800

Hi -

> Sent: Tuesday, March 09, 2010 12:28 PM

> create a new value of vacmGroupName in the vacmSecurityToGroupTable?

When the  row (indexed by SecurityModel and SecurityName) in the
vacmSecurityToGroupTable already exists, there are several sub-cases.
   (1) the row that's already there has a "volatile" StorageType.  (Such a
        row was almost certainly created due to the RADIUS/VACM supplemental
        procedure, as when the user has more than one concurrent session open.)
        (1a) the new value of vacmGroupName is the same as what's already there
               - normal case, nothing needs to be done
        (1b) the new value of vacmGroupName is something different - this would
                happen if a user was assigned to a different group while a session
                was open, and the user opened yet another session.  In this case, we
                update the vacmGroupName to the new value, since that is the most
                up-to-date policy information we have available.
                (1b.1) this new proposed value already shows up in the vacmAccessTable
                           - normal case, no special handling required
                (1b.2) this new proposed value does not appear in the vacmAccessTable
                          - we have differing opinions on whether this is a special case and
                            whether any special handling would be required
  (2) the row that's already there does not have a "volatile" StorageType - 
        current EOP treats this as a "do not update" situation.  If we want to generate
        notifications, then we *might* want to distinguish
        (2a)  the proposed value of vacmGroupName is the same as what's already there
               - does it really make sense to generate a notification in this case?  There's
               an administratively configured policy that's the same as what RADIUS wants
               to impose.
        (2b) the proposed value of vacmGroupName is different from what's there
               (2b.1)  this new proposed value already shows up in the vacmAccessTable
               (2b.2)  this new proposed value does not appear in the vacmAccessTable

I hope this breakdown makes it clearer how the various situations differ, and the
granularity of notification that would be *possible*.  What we as a WG need to figure
out is what would actually be *useful*, and what would actually be *necessary*,
in order to decide whether support for those notifications should be mandatory or optional.

I'm not convinced that notifications for any of these cases are operationally necessary.
I can see that there might be some operational regimes in which some of them might potentially
be useful.  So, if folks really think they need the notifications (and they should say which ones!)
I could go along with adding them to the MIB module, but making support for them optional
in the conformance material.

> at any time.

Yes.  This corresponds to (1b) and (2b).

>  On the other hand if there is a conflict with a  

That's all of (2), potentially allowing a loophole (depending on your needs)
for (2a).  I can see arguments both for including and excluding the (2a) subcase.

...
> Admittedly, this isn't a VACM error, but it is a RADIUS/VACM error.

The problem is one of deployment / migration and existing practice.

We both agree that it's a perfectly reasonable VACM configuration
to assign a (SecurityModel,SecurityName) pair to a group (policy)
called "NoAccessAllowed". Currently there's no motivation for the security
administrator to take the extra step of creating a do-nothing entry
in the vacmAccessTable just to say that this group can't do anything.
Making this case into what you call a "RADIUS/VACM" error imposes
a new requirement - the security administrator would need to create
this extra do-nothing entry in the vacmAccessTable in order to keep
the RADIUS/VACM integration from complaining.  I'd rather avoid
imposing any requirements on administrators unless they are actually
*necessary* for good security or operational reasons.

Randy

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 9 Mar 2010 16:44:28 -0500

>                            whether any special handling would be  

See my comment below.  It depends on whether the RADIUS server (or its  
administrator) had a reasonable expectation of gaining meaningful  
access using that group name.

>               - does it really make sense to generate a notification  
> in this case?

No.  I think it does not make sense.  There is no "error" if there is  
no "conflict".

>               There's an administratively configured policy that's  
> the same as what
>               RADIUS wants to impose.

Sure.

>               (2b.2)  this new proposed value does not appear in the  

I don't think that 2b.1 and 2b.2 make a big difference, both are  
conflicts, but it *might* be interesting to report, because it could,  
for example, be an indication of a typo-error in manually configuring  
the vacmSecurityToGroupTable.  Or it might not.

Right.

> in the conformance material.

Well, if vendors choose to skip implementation and customers have a  
rough patch during migration because of that, it could certainly  
become a product differentiator.

> the RADIUS/VACM integration from complaining.

The RADIUS server will never, if configured correctly, grant SNMP  
service authorization, via the RFC 5608 mechanism, but deny MIB  
database access by provisioning a "dead-end" access control policy.   
The likelihood that a *valid* RADIUS policy id would be named  
"NoAccessAllowed" is very (very) slim.

>  I'd rather avoid imposing any requirements on administrators unless  
> they
>  are actually *necessary* for good security or operational reasons.

Sure, but a collision with the intentional "NoAccessAllowed" group  
name is not something that I think we practically need to worry about.

Regards,

Dave

David B. Nelson

Elbrys Networks, Inc.

+1.603.570.2636
www.elbrys.com
[email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Tue, 9 Mar 2010 17:10:40 -0500

my thinking was only to alert an operator that they had a statically
configured rule that conflicts with a RADIUS rule. But I am fine with
not using a notification to report that case, given the costs you
point out. 

Your email points out the various possible conflicts, and it is
unclear which would be useful. You have obviously spent much more time
than I thinking this through. Could we summarize all RADIUS-local
conflicts into one counter, and leave it to operators to figure out
the conflict? 

If that still doesn't work, then I recommend wording in the doc that
says implementers should consider using syslog to record the details
of any conflicts so security admins can track down the policy-vs-local
conflicts.

dbh

> Behalf Of Randy Presuhn
> Sent: Tuesday, March 09, 2010 4:16 PM
> To: [email-masked]
> > > We're thinking about two very different cases.  I was 
> considering  
> > > the case
> > >> - would we notify in the case where the newly proposed 
> value for  
> > >> vacmGroupName
> be useful.  So, if folks really think they need the 
> notifications (and they should say which ones!)

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 9 Mar 2010 14:39:13 -0800

Hi -

Trying to take into account both Davids' comments, I think it might
make sense to re-factor slightly.  But first I think we need to figure out
a few corner cases:

When the  row (indexed by SecurityModel and SecurityName) in the
vacmSecurityToGroupTable already exists, there are several sub-cases.
   (1) the row that's already there has a "volatile" StorageType.  (Such a
        row was almost certainly created due to the RADIUS/VACM supplemental
        procedure, as when the user has more than one concurrent session open.)
        (1a) the new value of vacmGroupName is the same as what's already there
               - normal case, nothing needs to be done
               *** DO WE CHECK WHETHER THE EXISTING vacmGroupName
               corresponds to an entry in the vacmAccessTable, and notify if
                it does not, just as in (1b.2)?  (The security administrator could have deleted an
                entry in the vacmAccessTable since the last time we checked.) ***
        (1b) the new value of vacmGroupName is something different - this would
                happen if a user was assigned to a different group while a session
                was open, and the user opened yet another session.  In this case, we
                update the vacmGroupName to the new value, since that is the most
                up-to-date policy information we have available.
                (1b.1) this new proposed value already shows up in the vacmAccessTable
                           - normal case, no special handling required
                (1b.2) this new proposed value does not appear in the vacmAccessTable
                          *** this is one of the cases for which a notification is needed, right? ***
   (2) the row that's already there does not have a "volatile" StorageType - 
        current EOP treats this as a "do not update" situation.
        *** My understanding is that there is NOT a perceived need to categorically
        count / notify condition (2)
        If we want to generate         notifications, then we *might* want to distinguish
        (2a)  the proposed value of vacmGroupName is the same as what's already there
               - does it really make sense to generate a notification in this case?  There's
               an administratively configured policy that's the same as what RADIUS wants
               to impose.
         *** do we want to nonetheless check whether there's a matching vacmAcessEntry,
               as in (2b.1 / 2b.2), and notify if there is not? ***
        (2b) the proposed value of vacmGroupName is different from what's there
                *** my understanding is that there is a perceived need to notify on (2b) ***
               (2b.1)  this new proposed value already shows up in the vacmAccessTable
               (2b.2)  this new proposed value does not appear in the vacmAccessTable
                      *** do we also want to notify on this condition? ***

I could see describing it in terms of two notifications:

 - extVacmQuestionableGroupReference - whenever extVacmGroupName is
   assigned a value which doesn't reference something in the vacmAccessTable
 - extVacmAttemptedUpdateConflict - whenever we *don't* update
   the vacmSecurityToGroupTable because the entry in question isn't "volatile" and
   "active".

I'm not so sure as David about the extVacmAttemptedUpdateConflict in the
sub-case where the vacmGroupName would be unchanged.  While it's true
that this would be a policy no-op, on the other hand I think it *does* indicate
that something is messed up, because if that user is later assigned to
a different group in RADIUS, it will *become* an error.

Randy

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 9 Mar 2010 22:49:43 -0500

Randy Presuhn writes...

>         row was almost certainly created due to the RADIUS/VACM
>         supplemental procedure, as when the user has more than one 
>         concurrent session open.)
>                corresponds to an entry in the vacmAccessTable, and notify
>                if it does not, just as in (1b.2)?  (The security
>                administrator could have deleted an

I suppose due diligence would suggest that we do check.

>         (1b) the new value of vacmGroupName is something different
>             - this would happen if a user was assigned to a different
>               group while a session was open, and the user opened yet
>               another session.  In this case, we update the vacmGroupName
>               to the new value, since that is the most

Yes.

>    (2) the row that's already there does not have a "volatile" StorageType
>         - current EOP treats this as a "do not update" situation.
>         *** My understanding is that there is NOT a perceived need to
>         categorically count / notify condition (2)

Only in the case of conflicts.

>                - does it really make sense to generate a notification in
>                  this case?  There's an administratively configured policy
>                  that's the same as what RADIUS wants to impose.
>          *** do we want to nonetheless check whether there's a matching
>          vacmAcessEntry, as in (2b.1 / 2b.2), and notify if there is 
>          not?***

Again, due diligence suggests that we might want to do so.

>                 *** my understanding is that there is a perceived need to

Yes.

>                       *** do we also want to notify on this condition? ***

I think so.

>    the vacmSecurityToGroupTable because the entry in question isn't
>     "volatile" and "active".

I think that basically covers it.

> that this would be a policy no-op, on the other hand I think it *does*
> indicate that something is messed up, because if that user is later
> assigned to a different group in RADIUS, it will *become* an error.

Well, let's report it when it actually becomes an error.

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 9 Mar 2010 21:08:13 -0800

Hi -

> From: "Dave Nelson" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, March 09, 2010 7:49 PM
...
> Well, let's report it when it actually becomes an error.

While I can appreciate the reasoning, doing it this way (special-casing
the case where the "new" policy is the same as the existing one),
it will make both the specification and the implementation *slightly*
more complex.  (It changes a "whenever" to a "whenever... unless".)

I think I understand what the Davids want well enough to craft some specific
text.  I'll try to get that done Wednesday morning.

Randy

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 9 Mar 2010 14:09:18 -0500

I don't think the EOP anticipates any "newly proposed" values of  
vacmGroupName.  The only error case, in terms of a newly started  
RADIUS-authorized session, is if there is not match among the existing  
vacmGroupName entries.

Right.

Yes.  I can see the advantage of sending a particular notification  
only once, but I assume (a) there is no mechanism to support that  
concept, an (b) if there were, it would still require significant work  
(and state) internally to make that decision.

Regards,

Dave

David B. Nelson

Elbrys Networks, Inc.

+1.603.570.2636
www.elbrys.com
[email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 10 Mar 2010 11:53:39 -0800

Hi -

Here's a summary of the edits I think would be needed to satisfy the
comments on error counting and notifications.  As a technical contributor,
I'm still sceptical of the need for these, and think they increase the size
and complexity of the document and of implementations far out of proportion
to their value.  However, as editor, it seems that the weight of the working group
is in favor of doing something along these lines.  So - please let me
know whether these proposed changes accurately reflect your desires.

(1) Changes to section 5 (Structure of the MIB module)

      - add a subtree for the counters
      - add a subtree for the notifications

(2) Changes to section 6 (Relationship to Other MIB modules)

     - add a sub-section noting that notifications are turned off/on
        and destinations selected via RFC 3413

(3) Changes to section 7 (elements of procedure:)

       - modify 7.2.2 (Creation of Entries in vacmSecurityToGroupTable)
         to describe circumstances for extVacmAttemptedUpdateConflict
         notification (with exceptions in case where policy proposed by RADIUS
         is same as policy already in effect)

      - modify 7.2.3 (Update of vacmGroupName)
        to describe circumstances for  extVacmQuestionableGroupReference

(4) changes to section 8 (MIB modules)

       - add subtrees for counters and notifications
       - add counters (read-only) for each of the two notifiable conditions
       - add notification-type extVacmQuestionableGroupReference
         with a payload consisting of its counter and extVacmGroupName
       - add notification-type extVacmAttemptedUpdateConflict with a payload
         consisting of its counter and extVacmGroupName
         (minor issue - do we also want to convey the coresponding stuff from
          the vacmSecurityToGroupEntry, or should we rely on the application
          processing the notification to dig into it?)
.      - add a new MODULE-COMPLIANCE
         (or two ... issue: do we want to have a counters-only (no notifications) option?)
       - add a new OBJECT-GROUP for the counters
       - add a new OBJECT-GROUP for the notifications

(5) changes to section 9 (security considerations)
       - add text on sensitivity of the added read-only counters
       - add text on notification sensitivity
       - add text on *possible* significance of notifications
       - add text on potential notification DDoS

Let me know whether I've missed anything important in this summary,
and confirm whether this is what we want to do.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Wed, 10 Mar 2010 15:03:50 -0500

if the consensus is that these are not worth the effort/cost, I can
live without.

dbh 

> Sent: Wednesday, March 10, 2010 2:54 PM
> To: [email-masked]
>          (or two ... issue: do we want to have a 
> counters-only (no notifications) option?)

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 10 Mar 2010 15:11:09 -0500

On Mar 10, 2010, at 2:53 PM, Randy Presuhn wrote:

> As a technical contributor,I'm still sceptical of the need for  
> these, and think
> they increase the size and complexity of the document and of  
> implementations
> far out of proportion to their value.

I respect your position.  OTOH, it's often added facilities to aid in  
figuring out what has gone wrong that separates a mundane  
implementation from a robust one.

>  However, as editor, it seems that the weight of the working group

I have no informed opinion on this issue.   My guess would be that we  
let applications dig for added information, as long as we've provided  
all the necessary "search keys" in the body of the notification.

>         (or two ... issue: do we want to have a counters-only (no  

Again, no strong opinion.  I have no objection to making the counter  
group and notification group (separate or single) optional.  The value  
of these diagnostics aids will either be evident, or not, to the  
implementer.  I think it's important that we provide a standardized  
framework for implementing them, when they are seen as needed in a  
particular product or deployment.

> and confirm whether this is what we want to do.

I think you've got this "nailed".  I don't see anything that you've  
missed.  Thanks!

Regards,

Dave

David B. Nelson

Elbrys Networks, Inc.

+1.603.570.2636
www.elbrys.com
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Mar 2010 09:26:43 +0100

>          (or two ... issue: do we want to have a counters-only (no notifications) option?)

Counters are cheap to implement. If we agree to introduce counters, I
think they should be mandatory. Notifications should IMHO be optional
since they are more expensive to implement.

> and confirm whether this is what we want to do.

I think this is a fairly complete summary.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 11 Mar 2010 12:23:23 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, March 11, 2010 12:26 AM
...
> since they are more expensive to implement.

The counter itself is cheap, but in the case of extVacmQuestionableGroupReference,
implementing the counter requires scanning a VACM table (vacmAccessTable)
that we would otherwise not even need to mention, since we don't need to know
anything about it for this MIB module to do its real job.

I think a counter without the corresponding notification is relatively useless.  Reacting to
a change in the counters would require a scanning the vacmSecurityToGroupTable and
vacmAccessTable, and reconciling what is there with the complete RADIUS user/policy
configuration for *all* users, since there's no guarantee that the "offending" entry will
still be present in the extVacmSecurityToGroupTable when the counter change is
noticed.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Mar 2010 23:18:06 +0100

> The counter itself is cheap, but in the case of
> extVacmQuestionableGroupReference, implementing the counter requires
> scanning a VACM table (vacmAccessTable) that we would otherwise not
> even need to mention, since we don't need to know anything about it
> for this MIB module to do its real job.

This MIB modules is a close extension of VACM so I do not see the
"different MIB module" argument.

> I think a counter without the corresponding notification is
> relatively useless.  Reacting to a change in the counters would
> require a scanning the vacmSecurityToGroupTable and vacmAccessTable,
> and reconciling what is there with the complete RADIUS user/policy
> configuration for *all* users, since there's no guarantee that the
> "offending" entry will still be present in the
> extVacmSecurityToGroupTable when the counter change is noticed.

Yes, for debugging, you like to have a notification or a syslog
message. For detecting the situation, a counter is sufficient.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 11 Mar 2010 18:29:53 -0800

Hi -

> Sent: Thursday, March 11, 2010 2:18 PM

The point is that *every* time a group name arrives from RADIUS,
to support this counter implementations need to scan the vacmAccessTable.
This is necessary because the vacmAccessTable could have changed
since the last arrival from RADIUS, so even if a group name is not being
changed (e.g. a user is just opening another session) the "refresh" requires
us to check the vacmAccessTable to see whether the group now refers to
a "missing" policy.

Without the counter, there's no reason to do so.  It's processing
overhead that goes beyond "counters are cheap to implement."
Is it a huge cost?  Probably not, because the same lookup will
also happen inside the isAccessAllowed() ASI.  Is it free?
Certainly not.

[Aside - I suppose that if we really wanted to verify that the policy
reference was truly valid, we shouldn't just check to see that the
row exists, but should also require a check of the RowStatus for
the vacmAccessEntry to verify that it is "active".]

I just find it more than a little ironic that after all the complaints on another
list about VACM being over-engineered, we're doing the same thing here.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Mar 2010 08:13:04 +0100

On Fri, Mar 12, 2010 at 03:29:53AM +0100, Randy Presuhn wrote:
 
> I just find it more than a little ironic that after all the
> complaints on another list about VACM being over-engineered, we're
> doing the same thing here.

I can do well without the counter. Making the counter an optional
feature is what I would like to avoid. Either the counter is useful
and reasonable to implement or it isn't.

Since a RADIUS decision usually comes at the beginning of a secure
session, I doubt that the vacm access check will be noticable
overhead, given all the other stuff happening at the secure transport
layer. So I am not convinced by the complexity argument.

That said, I can live very well without the counter. There are other
configuration errors an administrator can make (e.g. a VACM access
entry pointing to non-existing view names) where the answer is simply
"you get what you asked for" and so from an SNMP perspective, a
reference to a non existing access rule is just it.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 12 Mar 2010 11:13:21 -0800

Hi -

Are there any other comments on how / whether to procede with
adding counters and notifications?  I think I have a good idea
what the edits would be, but would like instruction from the chairs
whether to apply these edits to the draft.

Randy

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 12 Mar 2010 15:23:25 -0500

--On Tuesday, March 09, 2010 06:34:51 AM -0500 Dave Nelson 
<[email-masked]> wrote:

> polices, then don't use it.  I think I see organizational dynamics
> arguments creeping into a protocol discussion.  That's always a bad sign,
> IMHO.  If there's bad organizational karma between the SNMP security
> administrator and the corporate RADIUS administrator, fight that out in
> the personnel domain, not the protocol domain, please.

Good advice.  Our goal here is to provide administrators, collectively, 
with the tools they need to apply their chosen policy.  Our goal is not to 
declare that one subsystem or its administators are more "trusted" than 
another, more likely to know what is going on, or less likely to do 
something stupid.

With that in mind, I generally like to apply the architectural principal 
that when configuration and policy come from multiple sources, information 
coming from a source "closer" to where it is applied should take precedence 
over information coming from further away.  This again has nothing to do 
with assuming that the closer source is more "trusted", and everythign to 
do with the fact that it makes sense to have an enterprise-wide policy and 
make exceptions for specific devices, but not to have a policy for a 
specific device and make an exception that applies to the entire 
enterprise.  The latter is nonsensical!

-- Jeff

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 12 Mar 2010 12:33:23 -0800

Hi -

> To: "Dave Nelson" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, March 12, 2010 12:23 PM
...
> enterprise.  The latter is nonsensical!

Text, please?

Randy

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 12 Mar 2010 16:11:14 -0500

--On Friday, March 12, 2010 12:33:23 PM -0800 Randy Presuhn 
<[email-masked]> wrote:

>> with the tools they need to apply their chosen policy.  Our goal is not
>> to  declare that one subsystem or its administators are more "trusted"
>> than  another, more likely to know what is going on, or less likely to
>> do  something stupid.
>>
>>
>> that when configuration and policy come from multiple sources,
>> information  coming from a source "closer" to where it is applied should
>> take precedence  over information coming from further away.  This again
>> has nothing to do  with assuming that the closer source is more
>> "trusted", and everythign to  do with the fact that it makes sense to
>> have an enterprise-wide policy and  make exceptions for specific
>> devices, but not to have a policy for a  specific device and make an
>> exception that applies to the entire  enterprise.  The latter is
>> nonsensical!
>
> Text, please?

What text?

I believe we were discussing the question of whether local configuration 
should override that provided by RADIUS or the other way around.

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 12 Mar 2010 13:53:50 -0800

Hi -

> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, March 12, 2010 1:11 PM
...
> should override that provided by RADIUS or the other way around.

Which text would you like to add to or remove from the I-D currently in WG
last call?

If the discussion entails no changes to the I-D, it would be nice
to know that, too. :-)

As far as I can tell, the draft's operational characteristics with respect to
the primacy of administratively provisioned policy vis-a-vis dynamically
delivered policy align with my understanding of the consensus view on
this list, though of course declaration of consensus is the chairs' perogative.

If there is specific text that is incorrect or misleading, please identify it
and suggest a replacement.

Randy

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 12 Mar 2010 18:02:09 -0500

> Which text would you like to add to or remove from the I-D currently in WG

I'm not sure why you're picking on me.  I responded to a comment David 
Nelson made, which in turn was in response to a comment David Harrington 
made about a specific piece of text to which he objected.  So, it should be 
pretty clear here that we're talking about that text, and particularly the 
notion that "RADIUS ... is at least as trusted as the security 
administrator".

In addition, part of my comment was intended to be taken in the context of 
the discussion that's been going on all week about the question of RADIUS 
overriding local configuration or vice versa.  Since that discussion has 
not yet quite died down, I think it's a bit premature to be complaining 
that no one has provided text regarding its outcome.

-- Jeff

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 12 Mar 2010 15:37:35 -0800

Hi -

> Sent: Friday, March 12, 2010 3:02 PM

What do you want to replace that text with?  I'm not arguing that what's there
is wonderful.  It's simply the text I made up in order to address the request
that the security considerations section should talk about the trust
relationships between the various entities.  I'd be happy to replace it with
anything meeting that requirement.

> that no one has provided text regarding its outcome.

I've re-read the thread.  All specific suggestions for text in this thread have been
resolved one way or another.  I think the discussion on the primacy of explicitly-
provisioned configuration over dynamically delivered stuff was clearly in favor of
handling things in the way the draft currently does.  (Though this is probably more
obvious to those scarred by the COPS experience.) The chairs can over-rule,
of course.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Mar 2010 10:18:18 +0100

> whether to apply these edits to the draft.

Speaking as co-chair, it seems there is no concensus yet what to do
about counters / notifications. We need more input on this. Here is an
attempt to sum up the positions of those who participated in the
discussion so far (let me know if I am wrong or missing something):

DN: error reporting to spot likely configuration inconsistencies is needed
DH: prefers supporting both counters and notifications for error reporting,
    but can live without if these are not worth the effort/cost
RP: counters are not terribly useful, do not over-engineer this
ED: proposed adding two counters and notifications, making counters
    and notifications each optional
JS: prefers moving ahead without counters/notifications, dislikes 
    having optional counters as an easy way out, can live with optional
    notifications but considers this in general an update to VACM
AD: concerns about throttling notifications

AD = Andy Donati
DH = David Harrington
RP = Randy Presuhn
ED = editor (Randy Presuhn)
JS = Juergen Schoenwaelder

<comment hat="contributor">
  VACM always allowed security names that map to group names for which
  there is no access rule. This does not seem to have been a
  operational problem for the last ten years and it is unclear why
  RADIUS makes this such a special case. Note that a "questionable
  group reference" may not just appear when security name to group
  name entries are added, but also when the security administrator
  removes entries from the access table. So if we choose to report
  "questionable group reference", it should in my opinion be reported
  in all cases, which means we would have to add to the EoP of the
  vacmAccessTable, something we are likely not charted to do. If we do
  not check "questionable group reference" when the vacmAccessTable is
  changed, then the fact that "questionable group reference" was not
  reported or counted does not mean there is no "questionable group
  reference", making the error indication relatively useless.

  I guess I am making up another argument in favor of doing nothing
  since reporting "questionable group reference" really would require
  an update of VACM to be generally useful.
</comment>

/js

---

From: "Dave Nelson" <[email-masked]>
Date: Mon, 15 Mar 2010 07:09:36 -0400

>   VACM always allowed security names that map to group names for
>   which there is no access rule. This does not seem to have been a
>   RADIUS makes this such a special case.

I understand that VACM has always had the opportunity for internal
inconsistency of MIB objects in its tables.  What makes this slightly
different with the introduction of RADIUS is:

(a) With VACM, the potential for inconsistency is easily discovered from
inspection of the static data in the MIB objects.  With RADIUS, a key
element of the potential inconsistency will be transient, and not easily
visible without externally accessible instrumentation.

(b) RADIUS is centralized and VACM is distributed.  There are two separate
"places" that have to be consistent.  Of course, this is no different from
other kinds of NAS-resident policy, such as that invoked by the RADIUS
Filter-Id attribute, after which the Management-Policy-Id attribute is
modeled.

I don't feel strongly that we should add instrumentation, if the consensus
is that operators will not find it helpful.  I can envision it being
helpful, but maybe that's just me.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Mar 2010 16:56:16 +0200

> visible without externally accessible instrumentation.

OK, I think you have a valid argument here. 

> Filter-Id attribute, after which the Management-Policy-Id attribute is

I do not what (b) has to do with the question whether we should have
counters and/or notifications.

> helpful, but maybe that's just me.

We need to find a way to move forward since we are obviously getting
stuck on this issue. I will consult with Russ to see what his reading
is since he is less involved in the technical debate.

/js