Subject: RE: [Isms] RE: Follow up on Authorize Only issue

From: "Nelson, David" <[email-masked]>
Date: Tue, 25 Jul 2006 17:12:10 -0400

Dave Harrington writes...

> But "provisioning SNMP parameters" explicitly does not include mapping
> to the access control subsytem; ...

I don't read that in the charter.  You apparently read it between the
lines.  Defining a new Access Control Subsystem or making changes to
VACM is explicitly out of scope.

> ...that is a separate issue that is out of scope for the WG,
> and should be dealt with in a separate document when such a
> document is included in a subsequent ISMS charter.

We've had this discussion many months ago.  My opinion hasn't changed.
I think that providing a way for RADIUS to provision group membership
information that can be used to map into any Access Control Subsystem
ought to be part of the work.  Especially if it does not actually affect
the architectural model, and is accomplished in an implementation
dependent fashion.

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Tue, 25 Jul 2006 18:05:07 -0400

Hi,

I was asked by the chairs at IETF66 to help unravel the confusion that
surrounds the RADIUS work in ISMS. The charter is rather ambiguous
about what consistutes SNMP parameters, but the charter seems to be
crystal clear that mapping to the access control subsystem is out of
scope:
"Work on new access control models or centralized administration of
View-based Access Control Model (VACM) rules and mappings is outside
the scope of the working group."

I believe the confusion is being caused by your insistence that
mapping to the access control subsystem ought to be part of the
RADIUS/SSHSM work, AND you are fuzzy on the separation of
authentication and authorization in the SNMP architecture. 

I absolutely agree that RADIUS provisioning of access control should
be part of the ISMS work. But it is a distinct work that is
independent of the RADIUS/SSHSM integration work, which should be
about the authentication and authorization necessary to establish the
SSH snmp subsystem. Trying to define one monolithic solution, rather
than following the modular SNMP architecture approach, is causing lots
of unnecessary confusion.

The chairs came to the conclusion that the work of mapping to the
access control subsystem was out of scope, per the charter.  But the
scope decision is for them to make clear, not me.

That is the reason I included the following sentence in my email: 
"Please ask the chairs for their advice if this is fuzzy."

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

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Tuesday, July 25, 2006 5:12 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [Isms] RE: Follow up on Authorize Only issue
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Jul 2006 09:13:17 +0200

> the architectural model, and is accomplished in an implementation

My understanding is that the concept of a group name is specific to
VACM. The ASIs into the ACM subsystem do not carry such a thing as a
group name. As such, mappings of security names to group names is VACM
specific and clearly happens within VACM from an architectural point
of view.

While I do see interest in addressing this VACM security name to group
name mapping issue, I do indeed see this work item in conflict with
the current ISMS charter:

: Work on new access control models or centralized administration of
: View-based Access Control Model (VACM) rules and mappings is outside
: the scope of the working group.

Given our current charter, I like to see the RADIUS document we are
chartered to produce focus on the RADIUS SSH user authentication and
RADIUS authorization of the SSH SNMP subsystem.  Another document
detailing how RADIUS can be used by VACM to obtain security name to
group name mappings might be written and become a WG item in the
future once we have completed our current work items and we can
re-charter and take on new work.

Note that this does of course not impact the RADEXT document which may
define all attributes needed to address all the RADIUS related ISMS
requirements.

I actually like to encourage people to write a document which explains
how VACM can utilize RADIUS to provision the security name to group
name mapping and to post such a document as an individual draft. But
as explained above, this work can't become an official WG work item
under the current charter.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 26 Jul 2006 15:51:00 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Nelson, David" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Wednesday, July 26, 2006 12:13 AM
> Subject: Re: [Isms] RE: Follow up on Authorize Only issue
...
> under the current charter.
...

Bottom line: without this out-of-charter work, whatever isms produces
will have, from a provisioning perspective, the same characteristics
as existing USM.   Specifically, for each user, every box to which
that user is to have any access rights will need to be configured
before that user will be able to do anything with that box.  The only
change from what we have today is that the number of configuration
PDUs will be somewhat smaller.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 26 Jul 2006 16:25:11 -0700

>>>>> On Wed, 26 Jul 2006 15:51:00 -0700, "Randy Presuhn" <[email-masked]> said:

>> under the current charter.

Randy> Bottom line: without this out-of-charter work, whatever isms
Randy> produces will have, from a provisioning perspective, the same
Randy> characteristics as existing USM.  Specifically, for each user,
Randy> every box to which that user is to have any access rights will
Randy> need to be configured before that user will be able to do
Randy> anything with that box.  The only change from what we have
Randy> today is that the number of configuration PDUs will be somewhat
Randy> smaller.

That's close, but not correct.  Yes, there will have to be some level
of configuration to allow a given user to access the device over SNMP.
The big gain by ISMS without USM is the ability to use the existing
users and the user authentication management system they already have
in place.  That's a big win.

Would it be nice to have an automated ACM population mechanism in
place as well?

   certainly.

Do I even think the work should be added to the charter?

   sure.

But, the resulting work MUST NOT be married together.  I've stated
this before many times (including during both BOFs) but I'll restate
it because it's the one thing that I think would actually decrease the
usability of the results.  I'm all for developing a radius extension
to populate the VACM (or however you want to think about it) as long
as the SSH half of the ISMS mechanisms doesn't require it.  My largest
customers don't use RADIUS today but would like SNMP/SSH and don't
care too much about the configuration load since there is already a
zillion things that need to be bootstrapped in the device.  IMHO, the
biggest problem with USM is not the initialization it's the continued
maintenance.  (bootstrapping is a big issue to, mind you, but
secondary to the long term planning).

-- 
Wes Hardaker
Sparta, Inc.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Jul 2006 09:50:12 +0200

> PDUs will be somewhat smaller.

True. And this is why this out-of-charter work is important and should
be undertaken and kept in mind for a potential followup work item. But
even without this completed in the first step, SNMP over SSH allows
operators to use established key management procedures that are on
many boxes already used to secure the access to the CLI and this by
itself is a big plus we should not forget.

/js