Subject: [Isms] wg rechartering

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Mar 2009 11:31:20 +0100

Hi,

since no more technical issues were raised yesterday, I will now go
ahead and produce the document writeups and submit the chartered
documents to our AD. This means the WG has completed its charter.

During the meeting, people expressed interest to do followup work.
This requires the WG to recharter and we need to have committed
editors, document reviewers and (co-)chairs. To address the last point
first, I am not able to continue as the chair of this WG. I might
continue as co-chair but the decision will also depend on the outcome
of the rechartering discussion and the commitment people can make to
complete followup work in a reasonable time frame.

>From the motion in the meeting room yesterday, the following work
items are to be considered during the rechartering discussions:

* DTLS transport for SNMP. Wes Hardaker has an active ID and there
  seem to be implementations underway. There was quite some support in
  the meeting room yesterday.

* RADIUS support to control the View-based Access Control Model
  (VACM). There was a document some time ago that has expired. There
  was some support in the room to work on RADIUS support for VACM but
  it is unclear at the moment whether we have editors to work on such
  a document.

* Simplified View-based Access Control Model (SVACM). The document
  authors could not be present at the meeting yesterday. The interest
  to pursue this work in the ISMS WG at the meeting was very low.

Jeff Hutzelman, Wes Hardaker and David Harrington offered support to
work on a new charter proposal. Please help them by expressing your
support or concerns for the various suggested followup work items.

/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: Fri, 27 Mar 2009 14:33:30 -0400

Juergen Schoenwaelder writes...

>   it is unclear at the moment whether we have editors to work on such

I've always felt that this wok was an important companion to the work we
have already completed.  I tried to find some time to submit an initial
individual draft prior to IETF-74, but got side tracked by other
responsibilities.  My co-author on the RADIUS Usage draft had at one point
expressed an interest to me in working on such a draft.  I can't speak for
his current level of interest or commitment, of course.

If the WG wants to re-charter and include this work, I would be willing to
contribute as a co-author.  I would need substantial assistance with the
SNMP aspects of this work.  Additionally, since this work is no longer
related to my daily employment activities, it would need to be on
time-available basis.

One of the challenges with this work item will be reconciling the notion in
SNMP that authentication is a separate concern from authorization, and the
notion in RADIUS that authorization must be bound (in one way or another) to
an authentication.

---

From: kaushik <[email-masked]>
Date: Fri, 27 Mar 2009 20:01:18 -0700

I agree with David that the RADIUS work is not complete until we address
authorization. I would be willing to co-author a document that tries to
address this if the working group wants to include this work.

Regards,
  kaushik 

On 3/27/09 11:33 AM, "David B. Nelson" <[email-masked]> wrote:

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 28 Mar 2009 07:44:13 +0100

On Sat, Mar 28, 2009 at 04:01:18AM +0100, kaushik wrote:
 
> I agree with David that the RADIUS work is not complete until we
> address authorization. I would be willing to co-author a document
> that tries to address this if the working group wants to include
> this work.

Can you two produce an ID that describes the problem and potential
solutions so we have something concrete to look at?

/js

---

From: "Dave Nelson" <[email-masked]>
Date: Sat, 28 Mar 2009 09:37:36 -0400

> solutions so we have something concrete to look at?

I suppose.  I'm not sure that the problem statement text would be so lengthy
as to warrant an ID, though.

The end user product requirement is "make SNMP access control work with a
RADIUS AAA infrastructure".

The SNMP architectural product requirement is "make an Access Control Model
that gets at least some of its principal-specific access control information
from a RADIUS server".

When I say "some of", I'm thinking that the RADIUS server might perform the
mapping of authenticated user identity, e.g. securityName, to an access
control group.  I don't think it's necessary for all of the access control
information to be received dynamically from RADIUS. It seems reasonable to
me that a [small] number of organizational roles are defined, and for each
of these roles an access control policy is configured into something similar
to one or more of the existing MIB tables of the VACM.  That is to say, the
policy rules for each role may be configured into local configuration data
store, but that the mapping of identity to role occurs in a RADIUS Server.

An alternate solution might create an Access Control Model that's
effectively an "RPC wrapper" which sends all the incoming ASI parameters to
the RADIUS Server and receives all the ASI return values from the RADIUS
server.  I'm thinking that doesn't scale well.  I'm thinking that, as we did
with the SSHTM, we need to create local session context so that the Access
Control Model only needs to contact the RADIUS server upon the first request
within a given session.

I think there will be challenges, as there were with the secure transport
models, because the existing ACM, VACM, is stateless, much like USM, is
stateless.

The other day, I alluded to the second challenge, that of maintaining the
RADIUS architecture by tying the access control authorization request to a
[previous] authentication request for the principal.

How's that for a quick "problem statement"?

---

From: "David Harrington" <[email-masked]>
Date: Sat, 28 Mar 2009 09:30:28 -0700

Can you republish the expired draft as starting point?

dbh 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dave Nelson
> Sent: Saturday, March 28, 2009 6:38 AM
> To: 'Juergen Schoenwaelder'; 'kaushik'
> Cc: [email-masked]
> Subject: Re: [Isms] wg rechartering
>

---

From: "Dave Nelson" <[email-masked]>
Date: Sat, 28 Mar 2009 13:07:04 -0400

David Harrington writes...

> Can you republish the expired draft as starting point?

Which expired draft is that?  draft-narayan-isms-sshsm-radius-02.txt?  I see
that draft name referenced in the ISMS minutes.

That's an earlier version of the RADIUS Usage draft that we've just
submitted to the IESG. In taking a quick look at that draft, I don't see any
*substantial* discussion of access control authorization.  The only
reference seems to be:

2.4.  SNMP Access Control Authorization

   [radman] describes a RADIUS attribute that can be used for SNMP
   access control authorization, however, the details of how an SNMP
   Access Control Model, such as the View-based Access Control Model
   (VACM), might utilize RADIUS authorization are the topic of current
   research, and beyond the scope of this document.

We may have had another early draft that delved deeper into access control
authorization, but it's not that one.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 30 Mar 2009 14:04:48 -0400

Is the following information (previously sent on March 28) sufficient for
the purposes of the re-chartering discussion?

> The end user product requirement is "make SNMP access control work
> with a RADIUS AAA infrastructure".
> 
> The SNMP architectural product requirement is "make an Access
> Control Model that gets at least some of its principal-specific
> access control information from a RADIUS server".
> 
> When I say "some of", I'm thinking that the RADIUS server might
> perform the mapping of authenticated user identity, e.g. securityName,
> to an access control group.  I don't think it's necessary for all
> of the access control information to be received dynamically from
> RADIUS. It seems reasonable to me that a [small] number of 
> organizational roles are defined, and for each of these roles 
> an access control policy is configured into something similar
> to one or more of the existing MIB tables of the VACM.  That 
> is to say, the policy rules for each role may be configured into
> local configuration data store, but that the mapping of identity
> to role occurs in a RADIUS Server.
> 
> effectively an "RPC wrapper" which sends all the incoming ASI 
> parameters to the RADIUS Server and receives all the ASI return
> values from the RADIUS server.  I'm thinking that doesn't scale
> well.  I'm thinking that, as we did with the SSHTM, we need to 
> create local session context so that the Access Control Model only
> needs to contact the RADIUS server upon the first request within a 
> given session.
> 
> I think there will be challenges, as there were with the secure
> transport models, because the existing ACM, VACM, is stateless, 
> much like USM, is stateless.
> 
> The other day, I alluded to the second challenge, that of maintaining
> the RADIUS architecture by tying the access control authorization 
> request to a [previous] authentication request for the principal.

If the WG chooses not to go dormant, and it's re-chartered to do more work,
we will obviously need authors, editors, and reviewers.  Kaushik and I have
indicated our willingness to co-author a draft if the WG re-charters to
include this work.

We would also need proposed charter text to succinctly describe the scope of
work, and that's what I think we need next.  A draft would follow the
re-chartering exercise.  Right?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 30 Mar 2009 22:40:37 +0200

On Mon, Mar 30, 2009 at 08:04:48PM +0200, David B. Nelson wrote:
 
> If the WG chooses not to go dormant, and it's re-chartered to do
> more work, we will obviously need authors, editors, and reviewers.
> Kaushik and I have indicated our willingness to co-author a draft if
> the WG re-charters to include this work.
> 
> We would also need proposed charter text to succinctly describe the
> scope of work, and that's what I think we need next.  A draft would
> follow the re-chartering exercise.  Right?

I like to understand what precisely the work is the WG wants to sign
up for. It is quite normal these days to charter work in the IETF for
which there is an initial ID that can be reviewed before a decision is
taken to take on the work item and which serves as a suitable starting
point. If there is nobody to produce such an initial ID, why should
the IETF charter this work?

It took us years to get SNMP over SSH worked out in a way that is
consistent with RFC3411 and so I do want to understand the relevant
architectural constraints for the proposed followup work so that it
becomes clear what it takes to work with them.

/js

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 30 Mar 2009 17:18:06 -0400

> If there is nobody to produce such an initial ID, why
> should the IETF charter this work?

Conversely, if there is no WG chartered to do the work, why should anyone
write an ID?  :-)  However, I do see your point.

> It took us years to get SNMP over SSH worked out in a way 
> that is consistent with RFC3411 and so I do want to understand
> the relevant architectural constraints for the proposed followup
> work so that it becomes clear what it takes to work with them.

Yes.  I think it would make sense to flesh out those details and constraints
prior to making a decision to take on the work -- or spending much time
writing formal IDs.  Of course, it may be that the incremental effort to
wrap such a write-up in ID format is small.  On the other hand, I'm not one
who believes that the only way to discuss such issues is to write an ID and
then solicit review.  There's a long-standing tradition in the IETF of
informally hashing out such issues on the appropriate mailing list.

If we can't get a discussion of the issues started here, then I'd suggest
that *both* the ID and the charter discussion are moot points.  :-)