Subject: [MIB-DOCTORS] FW: Recharter: ISMS

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 9 Jun 2009 19:17:25 +0200

Please send me your comments and concerns before Wednesday 6/17. 

Thanks and Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, June 09, 2009 10:55 AM
To: [email-masked]
Subject: Recharter: ISMS

[Secretariat (Bcc'd), please place this on 2009-06-18 agenda for IETF
review, and send out an internal review announcement]

ISMS WG has completed its major deliverables for securing SNMP with SSH,
and is planning to take on new work: obtaining VACM authorization
information via RADIUS, and specifying TLS/DTLS based transport for
SNMP. The proposed charter text is included below.

Tim and I are still looking for a co-chair (Juergen Schoenwaelder has
indicated that he cannot continue as the only chair, and will not be
able to attend IETF76 and IETF77), but let's review the contents while
Tim and I look for someone...

Best regards,
Pasi

---------------------------------------------------------------------

Integrated Security Model for SNMP (isms)

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

Additionally, new work will be undertaken to define TLS and DTLS-based
transports that can offer support for environments that prefer
certificate authentication.  Certificate based authentication is
desirable for many environments with a centralized authentication
service.  DTLS also provides datagram-based transmissions which may be
desired for environments where TCP performance suffers because of
network anomalies (e.g. high packet loss rates).  A combination of TLS
and DTLS-based transports offers solutions that addresses both the need
for certificate-based authentication and for datagram-based delivery.
Operators will be able to chose the transport solution that best meets
their needs.

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
TLS-based and DTLS-based Transport Models.

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

  - Specify TLS and DTLS transport models for SNMP.

Goals and Milestones:

Jul 2009 Publish initial documentation on the (D)TLS transports for SNMP
Jul 2009 Publish initial documentation for the centralized access
control Jan 2010 Submit documentation on the (D)TLS transports for SNMP
to IESG Jan 2010 Submit documentation for the centralized access control
to IESG

---------------------------------------------------------------------

---

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

Hi,

1) 
I support this work.
I believe the RADIUS support for SNMPv3 authorization is important.
I will not be able to participate actively in this work,
unfortunately.

2) 
I think the charter is misworded. 
"obtaining VACM authorization information via RADIUS" seems to violate
the modularity of the RFC3411 architecture.
There should be two steps.
1) obtaining authorization information via RADIUS, using "Remote
Authentication Dial-In User Service (RADIUS) Authorization for Network
Access Server (NAS) Management". The authorization information should
be in an access model independent form, so it can be used with
different access control models.
2) applying the RADIUS authorization information to the view-based
access control model.

I suggest rewording this to read
"Applying RADIUS Management Authorization attributes to the view-based
access control model (VACM)." 

3)
I think this wording is slightly wrong:
"The authorization information will be limited to mapping the
authenticated principal to existing access control polices ..."
I think the RADIUS authorization could potentially reference policies
that do not exist on the managed device yet. I recommend:
"The authorization information will be limited to mapping the
authenticated principal to access control policies ..."
(I personally prefer "named access control policies" or "access
control policy names", but that's a nit.)

The WG will need to decide whether to install the unrecognized policy
as a new policy (groupname) even though it may not be supported by
preconfigured group access rights, or to discard the RADIUS
authorization attributes for a policy that is not supported locally.
RADIUS should NOT need to know whether the corresponding access rights
are provisioned on the managed entity.

If user/groupname bindings can be installed dynamically, even though
the policy (group access) is not provisioned, a new access control
model or extension or an implementation might go get the values to
dynamically provision the policy details automatically, rather than
requiring operators to preconfigure the access rights for groups who
may never actually need to manage the device. 

4)
a continuation of point 2)
>     garbage collect expired dynamic securityToGroup mappings.

I think it is important to recognize that the SNMPv3 WG deliberately
made the binding mechanism between a principal and the AC policy the
responsibility of the specific AC model. Another AC model might use a
different binding mechanism to bind the principal and the
RADIUS-provisioned policy name.

RADIUS should supply a model-independent policy name, with no RADIUS
knowledge of how the binding will occur within an AC model.
The VACM extension should apply that RADIUS-provisioned policy name to
the authenticated identity using the VACM-specific
username-to-groupname mapping table.

RADIUS should supply a time limit for the named policy; However, it is
the VACM extension that understands this will be enforced by
garbage-collecting expired entries in the username-to-groupname table.
A different access control model might enforce the time limit for the
named policy by using different AC mechanisms.

5) should we be saying AAA rather than RADIUS?

6) in the milestones, should "centralized access" be "VACM extension"?
The RADIUS management authorization document already defines the
"centralized access" mechanism. ISMS just needs to write the VACM
extension to utilize the RADIUS authorization attributes.

7) 
Should the charter include updating the SNMP-VIEW-BASED-ACM-MIB, if
needed?
A new MODULE-COMPLIANCE may need to be written.

David Harrington
[email-masked]
[email-masked]
[email-masked]

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Romascanu, 
> Dan (Dan)
> Sent: Tuesday, June 09, 2009 1:17 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [MIB-DOCTORS] FW: Recharter: ISMS
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 10 Jun 2009 01:11:09 -0400

Hi,

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

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

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

dbh

> From: Dave Nelson [mailto:[email-masked]] 
> Sent: Tuesday, June 09, 2009 11:23 PM
> To: 'David B Harrington'; 'Romascanu, Dan (Dan)'; 
> [email-masked]; [email-masked]; [email-masked]
> Cc: 'Juergen Schoenwaelder'; 'Pasi Eronen'
> Subject: RE: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS
> 
> David B Harrington writes...
> 
> > "obtaining VACM authorization information via RADIUS" seems to 
> > violate the modularity of the RFC3411 architecture.
> 
> Well, perhaps it violates the *aspirations* for modularity.  
> It's clear to
> me that the access control decision is encapsulated entirely 
> in the Access
> Control Subsystem.  There is no ASI that allows for the ACS 
> to obtain access
> control guidance from any other subsystem.  We encountered 
> that problem in
> the work ISMS recently completed.  We created a new Transport 
> Subsystem, and
> a "cache" to allow the TS to communicate with the Security 
> Subsystem without
> modifying the existing ASIs.  It's pretty clear, in hind 
> sight, that the
> Security Subsystem design was never sufficiently modular to 
> foresee the
> possibility of the security mechanism being provided outside of that
> subsystem.  Are you suggesting we use the same tactic here?  
> That we create
> a new AAA Subsystem and a "cache" that allows it to 
> communicate with the
> ACS?
> 
> In other words, we create an AAA Subsystem.
> 
> Well, such a thing is possible, of course, but in the absence 
> of a specific
> mechanism, simply providing access by default raises real 
> security concerns,
> whether or not it is a matter of local policy.
> 
> By the same logic, as the binding mechanism *is* the 
> responsibility of a
> specific ACM, who's to say it cannot chose to use RADIUS?  
> What mandates
> that the source of access control information be "modular"?  
> Nothing that I
> see in the current definition of the ACS.
> 
> Having an AAA Subsystem might be a good thing.  My question 
> is whether it is
> a necessary thing, and whether it would be worth the extra 
> time and effort.
> 
> I think that's exactly what's been proposed.
> 
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jun 2009 08:43:41 +0200

On Wed, Jun 10, 2009 at 05:23:18AM +0200, Dave Nelson wrote:
 
> Having an AAA Subsystem might be a good thing.  My question is whether it is
> a necessary thing, and whether it would be worth the extra time and effort.

RFC 3411 defines the Access Control Subsystem, see sections 3.1.2 and
4.3. David is perhaps right that the wording of the charter text is
not 100% RFC 3411 conform but since I believe it is good enough in
documenting what the WG wants to achieve.

I personally would have loved to have an initial ID for the RADIUS ACM
integration work available to support the recharerting discussion;
this is where the wording really matters. But it seems we won't get
such an initial document...

/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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 10 Jun 2009 10:24:10 +0200

Unless there are special reasons to keep some of the interactions
confidential I suggest to move the discussion to the isms mail list. 

Dan

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Wednesday, June 10, 2009 9:44 AM
> To: Dave Nelson
> Cc: 'David B Harrington'; Romascanu, Dan (Dan); 
> [email-masked]; [email-masked]; [email-masked]; 
> 'Pasi Eronen'
> Subject: Re: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS
> 
> is whether 
> > it is a necessary thing, and whether it would be worth the 
> extra time and effort.
> 
> RFC 3411 defines the Access Control Subsystem, see sections 
> 3.1.2 and 4.3. David is perhaps right that the wording of the 
> charter text is not 100% RFC 3411 conform but since I believe 
> it is good enough in documenting what the WG wants to achieve.
> 
> I personally would have loved to have an initial ID for the 
> RADIUS ACM integration work available to support the 
> recharerting discussion; this is where the wording really 
> matters. But it seems we won't get such an initial document...
> 
> /js
> 
> --

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 9 Jun 2009 23:23:18 -0400

> violate the modularity of the RFC3411 architecture.

Well, perhaps it violates the *aspirations* for modularity.  It's clear to
me that the access control decision is encapsulated entirely in the Access
Control Subsystem.  There is no ASI that allows for the ACS to obtain access
control guidance from any other subsystem.  We encountered that problem in
the work ISMS recently completed.  We created a new Transport Subsystem, and
a "cache" to allow the TS to communicate with the Security Subsystem without
modifying the existing ASIs.  It's pretty clear, in hind sight, that the
Security Subsystem design was never sufficiently modular to foresee the
possibility of the security mechanism being provided outside of that
subsystem.  Are you suggesting we use the same tactic here?  That we create
a new AAA Subsystem and a "cache" that allows it to communicate with the
ACS?

> may never actually need to manage the device.

Well, such a thing is possible, of course, but in the absence of a specific
mechanism, simply providing access by default raises real security concerns,
whether or not it is a matter of local policy.

> RADIUS-provisioned policy name.

By the same logic, as the binding mechanism *is* the responsibility of a
specific ACM, who's to say it cannot chose to use RADIUS?  What mandates
that the source of access control information be "modular"?  Nothing that I
see in the current definition of the ACS.

> the authenticated identity using the VACM-specific username-to-groupname
> mapping table.

---

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

Agreed. I realized after the fact that ISMS was not being CC'd.

dbh 

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Wednesday, June 10, 2009 4:24 AM
> To: Juergen Schoenwaelder; Dave Nelson
> Cc: David B Harrington; [email-masked]; 
> [email-masked]; [email-masked]; Pasi Eronen

---

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

Hi, 

> documenting what the WG wants to achieve.

The main reason I object to the wording is that Dave Nelson and
Kaushik, the planned editors for the draft, do not seem to understand
how to craft this solution without violating the modularity. I would
like the charter wording to give them some guidance on this issue.

> such an initial document...

agreed. A draft would have been helpful.

> OPS-DIR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-dir
>

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 10 Jun 2009 08:03:50 -0400

> The simplest way to approach this problem is to have the
> RADIUS authorization attributes simply there in the background.

OK.  This was supposed to be a chartering discussion, but it's turning into
an architecture and design discussion.  Maybe going down that path for a
moment will help resolve the charter text issue. I'm not sure.

So, how do systems typically use RADIUS?  Well, you have a device to which
network connections can be made, that is sessions established and service
provided.  There is some gatekeeper function that moderates access.  That
gatekeeper function can call the RADIUS client module and ask the "Mother,
may I?" question on behalf of the user identity associated with the
connection attempt.  RADIUS comes back with a "Yes" or a "No" and perhaps
some modifiers or limitations.  The result of that consultation with RADIUS
does indeed exist in the background.  The gatekeeper function typically
keeps it as part of some session state.  Or maybe not.  It depends on what's
needed.

The key point here is that the gatekeeper function calls the RADIUS client
function to ask an access control question.  The RADIUS client, after
talking to the RADIUS server, provided an answer.  Typically this happens
only once at the point of session establishment.  For scalability and
efficiency reasons, it can't happen for every discrete operation.

All of that comports with the notion that the RADIUS attributes exist in the
background.  What is not accounted for is that doesn't happen by magic.
Something has to call on RADIUS to request that information, and if that
something isn't the Access Control Model, what is it?

> attributes, not about VACM.

The RADIUS client does not know about VACM.  VACM is simply a module (yes I
mean that, a piece of code) that calls the RADIUS client's API.  The RADIUS
client (asynchronously) calls back with the results of the authentication /
authorization request.  The RADIUS client doesn't know what VACM (the VACM
extension) is going to do with this the information.  As a matter of
practicality, the VACM extension will probably dynamically update one of its
MIB modules with the information obtained from RADIUS.  That information
will exist for the duration of the "session".  Probably the hardest thing
about this work will be for the VACM extension to figure out when the
"session" is over and when to flush the temporary information from its MIB
module.  We've encountered this issue already.

> dynamic provisioning, that is wrong. RADIUS provides a policy name.

Pedantically, you're correct.  The RADIUS client provides the VACM extension
with a policy name that's bound to a username and the VACM extension uses
that information to populate the MIB table.

---

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

> agreed. A draft would have been helpful.

Yeah, well, it's always easier to write the requirements after you have the
solution in hand.  :-)

---

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

Hi,

I separated my responses, since one is about charter text and the rest
is an architecture and design discussion.

> that information to populate the MIB table.

Yes. My point is that the charter does not say this. The text is
wrong.
The charter says 
    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.
What it should say is what you said:
	a RADIUS-provisioned policy name bound to a username, which
the VACM 
	extension will use to dynamically populate the
securityToGroupname table.

This may seem pedantic to you, but it is more than that to me. It took
the SNMPv2/SNMPv3 community ten years, including some very acrimonious
times, to get an architecture we could agree to, that was flexible
enough to meet the demands of multiple segments of the community. If
we want to change the architecture, then we should do so deliberately,
not as a side-effect of sloppy design. 

I strongly object to a WG goal based on the current wording, because
it is counter to the intentions of the SNMPv3 WG, and is not
compatible with the RFC3411 architecture.

I strongly support a WG goal based on the corrected wording.

dbh

---

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

>     binding between a user and preconfigured VACM policies via
>     dynamic additions to the securityToGroupname table.
>     the VACM extension will use to dynamically populate the

Ah, those two sections of text read basically the same to me, not having the
context of the "SNMPv3 Wars".  :-)  I heartily endorse that change in
charter text.