Subject: RE: RADIUS attribues for SNMPv3 (was RE: [Isms] draft of ISMS charter)

From: "Nelson, David" <[email-masked]>
Date: Mon, 22 Aug 2005 13:54:07 -0400

David Perkins writes...

> Every time I read the below I-D, the term "framed management" just
seems
> inappropriate. I'm sorry that I can't offer a better term, but that
> term makes it seem like an inappropriate mechanism is being used.

If the only issue is the name, that certainly can be changed.  This
document is written from a RADIUS perspective, based on the terminology,
context and history of RADIUS documentation.  In my previous discussions
on this topic, I have sometimes found that AAA experts phrase the issues
differently than SNMP experts.

What draft this is attempting to say is that there are two basic types
of management access to hosts (managed entities): (a) command line
interactive, via terminal emulation, and (b) "other".  Other involves
the use of an application layer protocol, such as SNMP or HTTP.  CLI
does not involve such a protocol.  Yes, remote CLI runs over application
protocols such as telnet and rlogin.  But the management objects
themselves are expressed in the non-protocol domain of ASCII command
strings.  Perhaps this is not a very useful distinction to make.

It would be possible to collapse the selection of SNMPv3 as a remote
management protocol from two RADIUS attributes down to one.  The current
version of the draft selects SNMPv3 by using a Service-Type of
Framed-Management together with a Framed-Management-Protocol of SNMPv3.
One could "flatten" this design by introducing a new Service-Type value
of SNMPv3.  We would have to flatten all the other remote management
protocol types as well.  Do you think this is a significant issue of
RADIUS protocol clarity?

> Also, when you work through the examples in section 9, I just don't
> believe that the model maps well to SNMPv3 VACM.

The authors have been waiting to see how this debate settles out in ISMS
before submitting the next revision.  I have seen discussion on this
list suggesting that *some* AAA-provisioned indication of the desired
SNMP access control policy is needed.  It has been suggested that the
RADIUS attribute could provide (a) the SNMP securityName, (b) the SNMP
groupName, or (c) some new object to used for this kind of mapping.
>From a RADIUS perspective, it really doesn't matter.

> Bottom line for me is that the I-D is a good start, it's not nearly
> well enough developed to go forward.

First, let me say that the draft intended to describe a new RADIUS
attribute that could be used for the purposes of ISMS.  It does not
contain any details as to *how" ISMS would use the attribute, beyond the
general notion that it provides a mapping into existing access control
mechanisms of SNMPv3.  Those details do need to be specified.  They can
be specified in a RADIUS document or an SNMP document.

As always, suggestions are welcome.

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 23 Aug 2005 14:12:06 -0400

>>>>> "Nelson," == Nelson, David <[email-masked]> writes:

    Nelson,> What draft this is attempting to say is that there are
    Nelson,> two basic types of management access to hosts (managed
    Nelson,> entities): (a) command line interactive, via terminal
    Nelson,> emulation, and (b) "other".  Other involves the use of an
    Nelson,> application layer protocol, such as SNMP or HTTP.  CLI
    Nelson,> does not involve such a protocol.  Yes, remote CLI runs
    Nelson,> over application protocols such as telnet and rlogin.
    Nelson,> But the management objects themselves are expressed in
    Nelson,> the non-protocol domain of ASCII command strings.
    Nelson,> Perhaps this is not a very useful distinction to make.

I really think HTTP (at least without SOAP) looks a lot more like CLI
than SNMP.