Subject: [Isms] potential charter text

From: Wes Hardaker <[email-masked]>
Date: Fri, 03 Apr 2009 13:26:18 -0700

I wanted to submit my suggested charter text immediately for potential
consideration.  I believe some of the author document authors, chairs,
etc will likely want to comment on the contents.  I'm going to be away
on vacation next week, so in the end I decided to submit it directly to
the list.  There is a number of things that are certainly not finalized
(like the two chairs, to say the least...  One roughly volunteered and
the other expressed a desire to step down at some point so I'll let them
answer if they want to continue together as co-chairs).  I'm also
personally less familiar with the new body of RADIUS authorization work,
so the text describing that work needs to be carefully reviewed as I may
not have summarized the problem and solution space perfectly.  The
previous charter was directly worded to discuss radius rather than
generic AAA terminology, so I stuck to using RADIUS directly as well.

The dates are also fairly randomly made up.  They're currently aligned
on a time-schedule wise, which I'm not sure is appropriate since I
suspect the solution spaces are at different current levels of completeness.

---- Begin proposed charter text ----

Integrated Security Model for SNMP (isms)

Last Modified: XXXX

Additional information is available at tools.ietf.org/wg/isms

Chair(s):
* Juergen Schoenwaelder <[email-masked]>
* David Harrington <[email-masked]>

Security Area Director(s):
* Tim Polk <[email-masked]>
* Pasi Eronen <[email-masked]>

Security Area Advisor:
* Pasi Eronen <[email-masked]>

Mailing Lists:

General Discussion: [email-masked]
To Subscribe: [email-masked]
In Body: in body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html

Description of Working Group:

The Simple Network Management Protocol version 3 (SNMPv3) provides
message security services through the security subsystem.  Previously
the ISMS Working Group defined a Transport Subsystem definition, a new
Transport Security Model, and a Secure Shell Transport Model and a
method for authenticating SNMPv3 users via the Remote Authentication
Dial-In User Service (RADIUS).  The initial body of work to be
tackled by the working group involved only these pieces.   Additional
work on other transport models and other security extensions were to
wait until the initial transport architecture and defining documents
were completed.

It is now possible to authenticate SNMPv3 messages via a RADIUS when
those messages are sent over the newly defined SSH transport.  However,
it still remains impossible to centrally authorize a given SNMP
transaction as on-device pre-existing authorization configuration is
still required.  In order to leverage a centralized RADIUS to its full
extent, the authorization configuration or decision making needs to be
outsourced to the RADIUS as well.  The result will be a new method of
outsourced authorization or centralized administration of View-based
Access Control Model (VACM) rules via a RADIUS.

Additionally, new work will be undertaken to define a DTLS-based
transport that can offer support for environments that prefer
certificate authentication and/or datagram-based transmissions.
Certificate based authentication is desirable for many environments with
a centralized authentication service.  Datagram based transports may be
desired for environments where TCP performance suffers because of
network anomalies (e.g. high packet loss rates).  A DTLS-based transport
would offer a solution that addresses both of these situations.

The current goal of the ISMS working group is two-fold: to develop a
method for allowing for access control decisions to be based on
information provide by an AAA provisioning service and to develop a
DTLS-based Transport Subsystem.

The new work must not modify any other aspects of SNMPv3 protocol as
defined in STD 62 (e.g., it must not create new PDU types).

The working group will cover the following work items:

- Specify a mechanism to support centralization of SNMPv3 Access Control
  rules via a RADIUS.
- Specify the DTLS transport for SNMP.

Goals and Milestones:
Jul 2009        Publish initial documentation on the DTLS transport for SNMP
Jul 2009        Publish initial documentation for the centralized access control
Jan 2009        Submit documentation on the DTLS transport for SNMP to IESG
Jan 2009        Submit documentation for the centralized access control to IESG

-- 
Wes Hardaker

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 3 Apr 2009 17:13:46 -0400

Wes Hardaker writes...

> I'm going to be away on vacation next week...

Enjoy!

> The result will be a new method of outsourced authorization
> or centralized administration of View-based Access Control
> Model (VACM) rules via a RADIUS.

Trying to pick my words carefully here...

Would we end up with a new Access Control Model?  Or would we attempt to
extend an existing one -- VACM?  We could define a new Access Control Model
-- call it VACM-R -- that is basically the same thing as existing VACM, but
it knows to outsource the identity lookup function to RADIUS, rather than
referencing a table in the local configuration data store.  The document
could liberally reference the VACM RFC.  I'm suggesting that it follows the
modular nature of the SNMP architecture better if we simply substitute
VACM-R for VACM as the ACM in a particular deployment, rather than
attempting to specify that an enhanced version of VACM is being used.  Do
models in the SNMP architecture even have version numbers?  :-)

> The current goal of the ISMS working group is two-fold: to
> develop a method for allowing for access control decisions to
> be based on information provide by an AAA provisioning service
> and to develop a DTLS-based Transport Subsystem.

Looks good.  s/provide/provided/

> - Specify a mechanism to support centralization of SNMPv3 Access
>   Control rules via a RADIUS.

We may want to wordsmith this a little bit.  My vision of the solution is
that the rules themselves, the OID-by-OID access rights, are still stored in
local configuration data store and provisioned as they are today.  What I
think we want to outsource to RADIUS in the mapping of securityName to
access control group name.  That is to say, the mapping of an authenticated
principal name to a pre-defined role.

If we want to [optionally] provision the detailed rules via RADIUS, we can
perhaps do that, but I think the charter wording should not mandate that
particular solution choice.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 4 Apr 2009 00:29:10 +0200

On Fri, Apr 03, 2009 at 11:13:46PM +0200, David B. Nelson wrote:

> attempting to specify that an enhanced version of VACM is being used.

I believe to recall from previous discussions (probably around the
ISMS interim in Boston some years ago) that the current EoPs in the
SNMP RFCs do not really allow to have multiple access control models
in place since there is no defined way to select which access control
model is in charge for a given access control decision. If my
recollection is correct, taking this path might involve much more
work than one might expect...

/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: Wes Hardaker <[email-masked]>
Date: Fri, 03 Apr 2009 15:39:53 -0700

>>>>> On Fri, 3 Apr 2009 17:13:46 -0400, "David B. Nelson" <[email-masked]> said:

DBN> Would we end up with a new Access Control Model? 

I'd assume not, but I tried to the leave the wording not pointing to a
specific solution.

I personally believe, as Juergen has already stated, that opening the
"what if we define something totally new" bag of worms will explode
because of the lack of standardization for how a management station
selects which ACM a given agent should be using (and what happens when
you have two).

I personally didn't have a huge amount of knowledge about what the
solution-space definers wish so I left it a bit generic.  I'd *much*
prefer that someone else more knowledgeable about the draft write
replacement text for my proposal.
-- 
Wes Hardaker
SPARTA National Security Sector
Cobham Analytic Solutions

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 3 Apr 2009 18:41:12 -0400

Juergen Schoenwaelder writes...

> I believe to recall from previous discussions (probably around
> the ISMS interim in Boston some years ago) that the current
> EoPs in the SNMP RFCs do not really allow to have multiple 
> access control models in place...

Multiple ACMs in place / use at one time?  In a single implementation?
Ever?

I have to assume that the notion of an Access Control Subsystem abstraction
implies that there can be multiple Access Control Models, each of which
could serve the as the "implementation"" of the ACS.  Are you saying that is
*not* the case?

> ... since there is no defined way to select which access 
> control model is in charge for a given access control decision.

OK, so this could be a matter of local configuration, right?  One could
[statically] "config out" VACM and "config in" VACM-R? 

> If my recollection is correct, taking this path might involve
> much more work than one might expect...

In which case we could attach an "extension" onto VACM?  I suppose that's no
different from the "config out" / "config in" scenario, just a little less
modular and elegant.

Does anyone else have insight into the modularity constraints on ACMs?

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 03 Apr 2009 16:00:36 -0700

>>>>> On Fri, 3 Apr 2009 18:41:12 -0400, "David B. Nelson" <[email-masked]> said:

DBN> I have to assume that the notion of an Access Control Subsystem
DBN> abstraction implies that there can be multiple Access Control
DBN> Models, each of which could serve the as the "implementation"" of
DBN> the ACS.  Are you saying that is *not* the case?

Lets back up and forget that train.  Because it is that complex (not
because it's not interesting or possible).

The real perceived goal, as you stated earlier, is to have RADIUS
bootstrap VACM with data, right?  That's what the current draft does (I
haven't read it)?  And that's what the solution space will be?  If so,
that's what we should write into the charter. 

DBN> Does anyone else have insight into the modularity constraints on ACMs?

(The quickest summary is that the M in ACM does mean "module".  Which
means it was, in theory, designed to be able to be swapped out and
replaced with something else.  But the operational aspects of actually
doing that aren't easy, to say the least.)
-- 
Wes Hardaker
SPARTA National Security Sector
Cobham Analytic Solutions

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 3 Apr 2009 19:18:53 -0400

> The real perceived goal, as you stated earlier, is to have 
> RADIUS bootstrap VACM with data, right? 

Yes.  As a security / AAA guy, I'm cool with that.  I guess I was
anticipating a polite "dope-slap" from the SNMP guys around my lack of
sensitivity to maintaining the modularity of the SNMP architecture.  :-)
What I'm hearing is that there really isn't so much modularity in the Access
Control Subsystem, when you get down to implementation details, so we don't
need to sweat too much about that.  Sweet! 

> If so, that's what we should write into the charter.

Right.  How about this?

OLD:

     In order to leverage a centralized RADIUS to its full
     extent, the authorization configuration or decision making
     needs to be outsourced to the RADIUS as well.  The result will
     be a new method of outsourced authorization or centralized 
     administration of View-based Access Control Model (VACM) 
     rules via a RADIUS.

NEW:

    In order to leverage a centralized RADIUS service to its 
    full extent, the access control decision in the Access Control
    Subsystem needs to be based on authorization information
    received from RADIUS as well.  The result will be a new
    method of outsourced authorization of an authenticated
    principal, for use within the View-based Access Control 
    Model (VACM).

And this?

OLD:

       - Specify a mechanism to support centralization of 
         SNMPv3 Access Control rules via a RADIUS.
       - Specify the DTLS transport for SNMP.

NEW:

       - Specify a mechanism to support centralization of 
         SNMPv3 Access Control decisions based on authorization
         information for an authenticated principal obtained
         via RADIUS.
       - Specify the DTLS transport for SNMP.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 03 Apr 2009 17:45:26 -0700

>>>>> On Fri, 3 Apr 2009 19:18:53 -0400, "David B. Nelson" <[email-masked]> said:

DBN> In order to leverage a centralized RADIUS service to its 
DBN> full extent, the access control decision in the Access Control
DBN> Subsystem needs to be based on authorization information
DBN> received from RADIUS as well.  The result will be a new
DBN> method of outsourced authorization of an authenticated
DBN> principal, for use within the View-based Access Control 
DBN> Model (VACM).

Sounds good, at least from the high level :-)

DBN> - Specify a mechanism to support centralization of 
DBN> SNMPv3 Access Control decisions based on authorization
DBN> information for an authenticated principal obtained
DBN> via RADIUS.

Yep.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 4 Apr 2009 07:53:10 +0200

> that's what we should write into the charter. 

Which current draft? 

I think it is crucial to decide what the WG wants to do so that it is
possible to get a feeling of the obstacles on the path and how long it
will take to move the obstacles away. There are likely significant
difference between

(1) populating a complete VACM configuration via RADIUS,
(2) creating a new ACM (and fixing any existing SNMP shortcomings to make
    that work), or 
(3) patching data into the VACM security name to group name mapping
    (this is what I think the EUSM proposal written by Kaushik several
    years ago suggested).

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 4 Apr 2009 08:28:40 +0200

On Sat, Apr 04, 2009 at 12:41:12AM +0200, David B. Nelson wrote:
 
> I have to assume that the notion of an Access Control Subsystem
> abstraction implies that there can be multiple Access Control
> Models, each of which could serve the as the "implementation"" of
> the ACS.  Are you saying that is *not* the case?

Being able to support multiple ACMs was clearly the intention but I
believe that this currently does not really work and if I am right,
then we would have to fix this part of the SNMP specs (like we had to
introduce a transport subsytem since the SNMP architecture did not
really provide one).

I believe the problem are the EoPs in RFC 3413, they simply state that
the isAccessAllowed ASI is called and there is nothing spelling out
how an ACM is selected (that is which isAccessAllowed ASI is actually
called if there are multiple ACMs). Consequently, there are also no
configuration datastore objects to control the ACM selection process.

I personally believe this is a bug in the SNMP specifications. Whether
it is worth fixing and who should be in charge of fixing it, I can't
tell right now.

Note that this "shortcoming" of the SNMP specifications also affects
the SVACM proposal (which BTW includes some text on interaction with
RADIUS in section 3 people might want to look at).

/js

---

From: "Dave Nelson" <[email-masked]>
Date: Sat, 4 Apr 2009 05:59:52 -0400

>     (this is what I think the EUSM proposal written by Kaushik several

I prefer this approach.

---

From: "Dave Nelson" <[email-masked]>
Date: Sat, 4 Apr 2009 06:02:53 -0400

> introduce a transport subsytem since the SNMP architecture did not

Perhaps in some *other* SNMP maintenance WG someday?  I agreed that we
should skirt around this issue, if possible.

---

From: "David Harrington" <[email-masked]>
Date: Sun, 5 Apr 2009 20:39:41 -0700

Hi,

Just returning from a vacation.

SNMPv3 was designed architecturally to support multiple coexistent
ACMs, but we screwed up the EOPs and presumably the message format,
and failed to define a selector mechanism. I believe this would be
significant work to correct, as was the lack of a transport subsystem,
and we should NOT take on this work at this time.

I think SVACM might work as a simplified approach to VACM, rather than
a new ACM, although I have not studied interoperability issues. The
NMS:agent relations (1:M, M:1, M:M) need to be considered.

I recommend that the RADIUS support be treated as a VACM extension,
rather than a separate AC model. This will allow us to avoid the
selector problem.

Like DaveN, I believe we should focus on an extension that provides
only a username-groupname dynamic mapping, that would provide a
binding between a user and preconfigured VACM policies via dynamic
additions to the securityToGroupname table. I think the main goal is
to simplify the configuration requirements for SNMP authroization for
employee adds/drops/changes and equipment adds/drops/changes.

I think AAA has the ability to specify a time limit for access
decisions, and such a timelimit should be used to garbage collect
expired dynamic securityToGroup mappings.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Friday, April 03, 2009 11:29 PM
> To: David B. Nelson
> Cc: [email-masked]
> Subject: Re: [Isms] potential charter text
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: "Dave Nelson" <[email-masked]>
Date: Mon, 6 Apr 2009 07:54:24 -0400

David Harrington writes...

> rather than a separate AC model. This will allow us to avoid the

We seem to be developing some consensus on that.  What do you think of the
proposed charter text I had sent out last week (reproduced below)?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Apr 2009 14:04:53 +0200

>     principal, for use within the View-based Access Control 

I find the usage of "outsourcing" confusing, at least for people
having knowledge how this term has been used in the COPS context. It
seems people really want to provision authorization policies. And in
general, I love charter text that spell out what a WG is not going to
do. If there is agreement that we the goal is not to provision access
policies (view tree families etc.), then this should be spelled out.
The tighter the charter text, the more useful it is going to be
(especially in the absence of an ID to start from - hint hint).
 
>          information for an authenticated principal obtained

This can be read to fully populate ACM information (which not VACM?)
and I believe this is not what this WG wants to do. If the goal is to
get the mapping to VACM group names (policies) from RADIUS, then we
should say so. It would also be good to know if any additional RADIUS
attributes will be needed and if so, who is going to standardize them,
that is what the interplay of ISMS and RADEXT would be in this case.

/js

---

From: "Dave Nelson" <[email-masked]>
Date: Mon, 6 Apr 2009 08:23:24 -0400

> having knowledge how this term has been used in the COPS context.

OK.  I tend to agree.  That was wording that Wes introduced.  I think we can
be more specific.

> If there is agreement that we the goal is not to provision access

OK.

> (especially in the absence of an ID to start from - hint hint).

We could turn the charter text into the outline of ID.  Just kidding. :-)
 
> This can be read to fully populate ACM information (which not 
> VACM?) and I believe this is not what this WG wants to do.

Right.

> If the goal is to get the mapping to VACM group names (policies)
> from RADIUS, then we should say so.

Perhaps I can purloin some text from Dave H's last message.

> It would also be good to know if any additional RADIUS
> attributes will be needed ...

Hmmm.  I think that goes a bit beyond what one would normally find in a
charter, into the realm of solution details.

> ... and if so, who is going to standardize them, that is what
> the interplay of ISMS and RADEXT would be in this case.

However, I believe that all the RADIUS attributes that we will need are
already defined in the "radman" draft, or defined in an existing RFC and
discussed in the "radman" draft.  I think we're all set in that regard.

I send some further modified proposed charter text in a separate message.

---

From: "Dave Nelson" <[email-masked]>
Date: Mon, 6 Apr 2009 08:37:38 -0400

Further refined proposed charter text (addresses comments from Dave
Harrington and Juergen Schoenwaelder):

.....

     In order to leverage a centralized RADIUS service to its
     full extent, the access control decision in the Access Control
     Subsystem needs to be based on authorization information
     received from RADIUS as well.  The result will be an
     extension to the View-based Access Control Model (VACM),
     to obtain authorization information for an authenticated
     principal from RADIUS.  The authorization information will
     be limited to mapping the authenticated principal to existing
     access control polices, defining session timeouts, and
     similar session parameters.  This mechanism will not provision
     the detailed access control rules.

.....

        - Specify a mechanism to support centralization of
          SNMPv3 Access Control decisions by means of a
          RADIUS-provisioned username-to-groupname dynamic
          mapping, that would provide a binding between a 
          user and preconfigured VACM policies via dynamic 
          additions to the securityToGroupname table.  
          Additionally, specify a time limit for access 
          decisions, and such a time limit should be used to
          garbage collect expired dynamic securityToGroup 
          mappings.

Note, this is a modification of the text sent out by Wes hardaker last week.

---

From: "Dave Nelson" <[email-masked]>
Date: Mon, 6 Apr 2009 08:47:59 -0400

> discussed in the "radman" draft.  I think we're all set in that regard.

We could turn this into additional proposed charter text, to formally
address any RADIUS dependencies.  For example:

      It is expected that all the RADIUS Attributes needed for
      this work have already been defined in existing RFCs or in 
      draft-ietf-radext-management-authorization-06.txt.

---

From: kaushik <[email-masked]>
Date: Mon, 06 Apr 2009 07:28:29 -0700

I prefer this approach as well.