Subject: [Isms] charter proposal

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Aug 2005 17:33:25 +0200

Hi.

Attached is a charter proposal for rechartering the ISMS WG based on
the discussions during today's WG meeting. Lets bash it here on the
list to converge it into a usable charter that helps us in getting the
work we agreed on today done.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany
_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 2 Aug 2005 12:10:21 -0400

Hi,

I think the ADs need to be updated. 

Suggested modifications:

"SSH is a widely deployed access protocol preferred by many operators
to manage network devices. In order to leverage the authentication
information already accessible on such devices, the ISMS working group
will define a new SNMP security model which utilizes the SSH protocol
to provide message security services for SNMP.

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. Devices utilizing SSH often support
the integration of user authentication with AAA systems via protocols
such as RADIUS, which provide authorization information in the same
message exchange session. The TMSM document will describe how
authorization information accessible through a TMSM authentication
mechanism might be cached or otherwise captured so that it can later
be made available to the AC subsystem, but it is out of scope to
define how the AC system gets such information. If the SSH security
model provides a tie-in to a AAA system, it will be acceptable to
identify how the information can be cached within the constraints of
the TMSM model.

The solution must not modify any other aspects of SNMPv3 protocol as
defined in STD 62 (e.g., it must not create new PDU types). It should
also be compliant with the security model architectural block of
SNMPv3, as outlined in RFC 3411. Any architectural extensions required
to achieve the goals stated above should be defined in the TMSM
document in such a way
that additional transport mapping security models may be defined in
the future."

[I am concerned about having the RADIUS tie-in in this charter, but
the TMSM is basically extending the architecture of SNMPv3, and if the
security model will "trigger the AAA infrastrcuture for authorization
information", it really needs to be discussed within the context of
the TMSM document.]

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder
> Sent: Tuesday, August 02, 2005 11:33 AM
> To: [email-masked]
> Subject: [Isms] charter proposal
> 
> Hi.
>

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 2 Aug 2005 09:32:55 -0700 (PDT)

HI,

I support the below, since it will allow for the following....

On the managed system, there can be created rules for where
to "resolve" authentication and authorization. For example,
a managed system may suport both local and "remote" (via
Radius) resolution. A simple rule may be based on ordering
of the authen/author resolvers, such as 
  "set authentication admin resolvers (local, r1)"
This rule would try to authenticate a user first locally,
and then "remotely" at Radius server r1. Other rules
could be supported based on, for example, a pattern
match of the the name, the source IP address, or
whether is was from a serial port.

Likewise, the managed system could support rules for
where to get authorization info, which could "override"
VACM info (such as group name), or extend it (such
as allowed hours of use).
 
PS Such rules already exist in commercial products for
   administrative access.

> > work we agreed on today done.

Regards,
/david t. perkins

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Aug 2005 18:35:51 +0200

> information", it really needs to be discussed within the context of

There is a reason why my text mentioned Radius as a source for user
authentication and not authorization...

/js

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 2 Aug 2005 12:54:06 -0400

Hi,

Hmmmm. I am of the impression that, as a source for authentication,
the use of AAA is an implementation-dependent detail of the SSH
authentication; whether SSH authentication relies on RADIUS or AAA or
local users to authenticate the transport connection and the user
should be transparent to the SNMP engine, shouldn't it? If so, then it
doesn't belong in the charter at all.

Where we run into the problem is if a TMSM also needs to somehow
capture the authorization information returned by AAA so the AC
subsystem can use it later. If we want that feature, and we seem to
have a lot of people suggesting it is an important feature to support,
then we need to address how to standardize that feature so future TMSM
security models handle it in a compatible way. 

Are my assumptions incorrect?

David Harrington
[email-masked]

> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Tuesday, August 02, 2005 12:36 PM
> To: David B Harrington
> Cc: [email-masked]
> Subject: Re: [Isms] charter proposal
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Aug 2005 19:06:25 +0200

> doesn't belong in the charter at all.

I agree that this is fully transparent to the SNMP engine. On the
motivational side of the charter, I thought it might be worth to
mention this since not everybody might be aware that SSH
authentication decisions can easily be outsourced to AAA servers,
something that was requested in the past by operators.

> security models handle it in a compatible way. 

I simply did not put this in the charter since I do not yet understand
the dimension of this problem. I need to learn more how AAA servers
provide this authorization information and how it looks like. Perhaps
someone here can educate me or point to the relevant specs to read.

/js

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 2 Aug 2005 13:21:02 -0400

Hi Juergen,

>From my limited experince looking at the problem,

If we start to discuss HOW the SSH will support AAA, then we will need
to discuss
1) which AAA protocol?
2) which AAA attributes contain the authorization information
2a) should we use filterID, which is supposed to be for packet
filtering, not policy management
2b) should we define a new standard attribute for this purpose, since
the only attributes available don't provide the granularity we need?
2c) should vendors develop their own VSAs to provide this granularity?
3) will we standardize the naming mechanisms for ACM policies?
4) will we support user-to-group mappings or user-to-policy mappings
(i.e. non-group policies)?

And so on....

I'd like to avoid the whole discussion of how to connect SNMP
authorization to AAA authorization for now, and simply focus on how to
connect SSH user-auth to SNMP user-auth.

However, if the WG REALLY wants to trigger/capture AAA-authorization
via the security model, we'll need to open that whole can of worms,
because it will require changes to the architecture or an agreement of
how to do it outside the architecture (wink, wink).

David Harrington
[email-masked]

> Sent: Tuesday, August 02, 2005 1:06 PM
> To: David B Harrington
> Cc: [email-masked]

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 02 Aug 2005 10:52:03 -0700

Hi David,

I am not sure we need elaborate AAA work in order to allow for
linkages between ISMS authentication and SNMPv3 VACM.
Ideally the RADIUS work for this should happen in RADEXT
and I believe Dave Nelson and Greg Weber already have an
ID that would be relevant.

http://www.ietf.org/internet-drafts/draft-nelson-radius-management-authorization-01.txt

regards,
   kaushik!

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Aug 2005 21:36:17 +0200

> (i.e. non-group policies)?

If all these questions do not have a well established clear answer,
then I guess I misunderstood those who said that user->group mapping
is something we have to do via AAA because it is widely used
elsewhere.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Aug 2005 22:00:42 +0200

> http://www.ietf.org/internet-drafts/draft-nelson-radius-management-authorization-01.txt

This is indeed interesting and highly relevant work. I do, however,
believe that (if we go down this road) we need to specify when exactly
such authorization information is retrieved, how long it is valid and
how such an external source of authorization information fits into the
RFC 3411 model.

I am also not sure the implementation specific textual formats
described in the ID cited above which convey authorization information
are particularily useful for interoperability, but that might be a
less important detail at this point in time.

/js

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 2 Aug 2005 17:21:52 -0400

> is something we have to do via AAA because it is widely used

Dave Nelson and I and the engineers at Enterasys started discussing
well over a year ago the need for vendor-specific management
attributes to provide granular user-to-policy mappings, and comparable
attributes are currently being discussed in RADEXT. We started our
discussions because there did not appear to be a set of RADIUS (or
other AAA protocol) attributes that could be used to provide such a
mapping for network management purposes at the desired level of
granularity for VACM groups or other network management access control
"named" policies. 

The only existing standard management attributes seem to be the remote
management Service-Types defined in RFC 2865 [RFC2865]. The available
services provide access to the interactive, ASCII-text, Command Line
Interface (CLI) of the managed entity, but do not do any user-to-group
mapping that I can see.

The only other option I've seen is the Congdon approach (RFC3580) for
having RADIUS identify user-to-VLAN mappings (the RADIUS server
typically indicates the desired VLAN by including tunnel attributes
within the Access-Accept), and then policy filters (i.e. the user is
allowed to use the SNMP protocol) can be applied to traffic on that
VLAN. I don't see how this could be effectively utilized for
user-to-VACM Group mappings.

I would be interested in hearing from vendors and operators and the
people arguing for this user-to-group-mapping feature just HOW they
currently use AAA to provide user-to-group mappings for network
management access control.

David Harrington
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 03 Aug 2005 08:27:45 +0200

Hi Juergen,

I have major problems with the way things went yesterday.

The group decided to reject out of hand SNMP/BEEP without any comparable
SSH draft.  I think this is both unreasonable and unwise, especially
given the time frame the ADs are pushing.

What I know:

 - There was general agreement in the room that "call home"
   functionality was a good thing to have.

 - There was general preference for a single mechanism between NETCONF
   and SSH.

 - Of the humm that occurred favoring SSH, the operators and at least
   those I know to be interested vendors indicated a preference for
   BEEP.

 - NETCONF/SSH specifically excluded "call home" functionality.

 - There is no specification for SNMP/SSH.

In our haste to create a solution that integrates with other security
solutions we are producing something that won't integrate with other
network management solutions.

Now you could say that perhaps the NETCONF/SSH specification should have
"call home" added to it.  The reason Margaret didn't include it was that
she felt if you wanted that sort of thing, use BEEP.  That was her
logic.  It's not unreasonable.

I have no problem working through the issues that separate BEEP and SSH.
 But to have prematurely made the decision is, I assert again, unwise.

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Aug 2005 09:07:59 +0200

> given the time frame the ADs are pushing.

The TMSM document was written with ssh in mind. This is mentioned in
the ID. I am happy to leave it to the chairs and the ADs to gauge the
level of discussion of SSH as a transport on the ISM WG mailing list
and to compare that to BEEP.

>    functionality was a good thing to have.

Can't remember whether this is accurate. I do remember jabber log
statements that call home might be doable with ssh as well - I can't
judge that at the moment. I do however realize that SNMP right now
does not have call home - so you are proposing to add a feature to
SNMP which does not yet exist in that form.

>  - There was general preference for a single mechanism between NETCONF

Not sure I understand the semantics of this sentence...

>    those I know to be interested vendors indicated a preference for

I heard Simon saying that he uses SSH for management, actually using
passwords authentication (even though he seemed to prefer in principle
to use public key SSH authentication). Simon, correct me if I am wrong.

I heard Ruediger saying that he doubts that someone types in SNMP
messages into SSH (which I can easily agree with) and that he does not
really care what the security protocol on the wire looks like as long
as it integrates. Ruediger, correct me if I am wrong.

>  - NETCONF/SSH specifically excluded "call home" functionality.

Not sure this is accurate. I think NETCONF decided to make a straight
forward ssh mapping mandatory. Other mappings can be used as well but
are not mandatory.

>  - There is no specification for SNMP/SSH.

See explanation above.

> network management solutions.

Which ones? I doubt that SNMP based solutions have a call home feature
right now.

> logic.  It's not unreasonable.

I prefer to let Margaret speak for herself since there are different
interpretations possible for a statement of the sort "if you wanted
that sort of thing, use BEEP".

> But to have prematurely made the decision is, I assert again, unwise.

Maybe it is, maybe not. With netconf, we took the approach that SSH is
mandatory and to let the market sort out the rest. In isms, it was
somehow determined yesterday that doing this same approach wastes
resources.

If you think this decision is wrong, you should I think primarily
contact the chairs and the ADs - I am clearly not the one to determine
concensus. (So I am kind of wondering why this message was directed to
me and not to the chairs - perhaps too many Juergens around here.)

/js

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 3 Aug 2005 09:41:48 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Eliot Lear" <[email-masked]>
Cc: "Margaret Wasserman" <[email-masked]>; "Andy Bierman"
<[email-masked]>; "Sam Hartman" <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 03, 2005 9:07 AM
Subject: Re: [Isms] charter proposal

Eliot

I did (and posted to the list) a section for the TMSM I-D which replaced TLS by
SSH.  There was very little change, mostly the choice to use subsystems and
connections. Sam commented I did not go far enough - true, but I went as far as
TMSM with TLS.

The unresolved issue for me was what to authenticate, whether we have one SSH
authenticated pipe between engines (ssh-userauth) with principal authentication
done separately or whether there was one SSH authenticated pipe per set of
security credentials, be that host, application or user (whatever level the
organisation authenticates at).

For me, most of the issues are transport level security ones, independent of
actual protocol.

Tom Petch
<snip>

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 3 Aug 2005 06:45:04 -0400

Hi Eliot,

I share your concern with the way things went, although not for quite
the same reasons. 

I think it makes much more sense to encourage multiple proposals to be
submitted so we can do a real comparison; that was the approach used
in netconf and many other WGs, but apparently that's not an acceptable
approach for this WG. I think this would be a better approach than
eliminating all but one possible solution and choosing only one which
we don't even know is feasible, knowing that netconf found it hard to
support some expected requirements, and choosing that one without even
identifying the requirements that need to be met by proposed isms
solutions. An alternative approach is to identify the requirmeents and
then do a protocol analysis, but I've seen that in multiple WGs and
doing this seems to cause WGs to lose momentum badly, and to give
really skewed results.

We should be trying to accommodate operators' preferences for which
protocols to support. Wes's survey showed SSH as a popular choice with
(ISP) operators; I don't see BEEP in the list (maybe it wasn't a
choice in the survey). 

I think the group chose to reject BEEP, or at least sideline BEEP for
now, primarily because we are supposed to be leveraging
widely-deployed infrastructure, and BEEP to my knowledge is not widely
deployed; it is mentioned in a wide range of IETF WGs, which shows a
strong marketing push by the supporters of BEEP like yourself, but I
don't see a comparable deployment of BEEP in the real world. I think
this is very similar to the analysis done in the Netconf WG.

I think it would be foolish for the WG to choose BEEP because the ADs
are pushing a tight timeframe, just as I think it is foolish to choose
SSH because of a tight AD timeframe. But if that's what it takes to
stay in business, then I guess we must.

That said, I personally think that if you believe BEEP to be a better
solution than SSH, you should continue to develop the BEEP draft while
our team develops the SSH proposal, then we can do a real comparison.
I have serious concerns about the decisions made by Netconf to not
address notifications and other issues with their SSH solution, and it
may well be that SSH may not be a feasible approach to meet SNMP
needs, but until we have an SSH proposal it's hard to tell.

David Harrington
[email-masked]

> [mailto:[email-masked]] On Behalf Of Eliot Lear
> Sent: Wednesday, August 03, 2005 2:28 AM
> To: [email-masked]
> Cc: Margaret Wasserman; Andy Bierman; Sam Hartman; [email-masked]

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 3 Aug 2005 11:37:04 +0200

<below>
Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "David B Harrington" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 02, 2005 9:36 PM
Subject: Re: [Isms] charter proposal

> is something we have to do via AAA because it is widely used

I have said that the user-group mapping needs removing from the 'agent' as a
task the administrators have to perform in order to maintain security, else I
believe isms will not meet its objectives.

In one, rather large, marketplace, I see this model (framework? architecture?)
done in a proprietary manner, using Windows Active Directory (which uses
Kerberos, but I don't know in what way).

So an end user logs onto a server running an SNMP Command Generator, is
authenticated and as part of that, the security server specifies authorisations,
access permissions, rights etc which are mostly defined by being a member of a
group.  The Command Generator now has everything the Command Responder needs to
know and so passes it, end user identity plus group membership, to the Command
Responder in a secure manner (ssh transport, security parameters, authenticated,
with
integrity) which uses it to access the access control rules.

Obviously this does not yet exist for SNMPv3 but there are parallels for other
aspects of network management.  Again, I have no brief for those who would
implement such code but if we provide the protocol, I believe it is a simple
step forward.

Likewise, my knowledge of standards-based systems leads me to believe that this
could be done with them (although not necessarily with all of them).

I do believe that retrieving the group membership at the time the SNMPv3
principal is authenticated is the key function and that everything else needs to
stem from it.  As dbh's query elicited, these servers are stateless.  I also
believe that the Command Generator is the place to do it because of the (small)
numbers of them, the power of these platforms, the rich range of services that
already exist on them.  Doing it from an entry level router does not seem so
attractive.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Aug 2005 14:41:14 +0200

On Wed, Aug 03, 2005 at 11:37:04AM +0200, Tom Petch wrote:

> So an end user logs onto a server running an SNMP Command Generator,
> is authenticated and as part of that, the security server specifies
> authorisations, access permissions, rights etc which are mostly
> defined by being a member of a group.  The Command Generator now has
> everything the Command Responder needs to know and so passes it, end
> user identity plus group membership, to the Command Responder in a
> secure manner (ssh transport, security parameters, authenticated,
> with integrity) which uses it to access the access control rules.

Why should the device (command responder) trust the user that he does
not claim a false group membership?

I believe the user to group membership has to be provided by a trusted
third party or it would have to be at least signed by a trusted third
party and the device would have to be able to check the signature.

/js

---

From: Eliot Lear <[email-masked]>
Date: Wed, 03 Aug 2005 15:22:26 +0200

Hi Juergen,

First let me say that I did not mean to direct the message at you.   As
I recall you played very little part in discussions at the actual
meeting - not that there's anything wrong with that.  My concern is that
we have reached a perverse result without proper consideration of the
ramifications (not that you caused such a result).  Your message
containing the proposed updated charter required me to respond as I find
the charter wholly unacceptable (to the point that if it goes forward
under the current conditions I will appeal).  I recognize, however, that
you are accurately reflecting the sense of the room.

> and to compare that to BEEP.

Conveniently it works for both.  And I generally think that the TMSM is
good as far as it goes, and I agree with you that we should separate it
out from protocol, adopt it as a WG doc, and get it done.

> SNMP which does not yet exist in that form.

Yes, I am and it's important.  The world is very different from the way
it was when v3 was developed.  Unless people find it necessary to do so
I will not regurgitate the full logic behind this.

> Not sure I understand the semantics of this sentence...

In other words, better we end up with one protocol rather than two and
in principle I agree with that notion.

> to use public key SSH authentication). Simon, correct me if I am wrong.

Yes, he is sitting next to me (not on the list).  This is what he said.
 However, he went on to vote for BEEP.

> forward ssh mapping mandatory. Other mappings can be used as well but

Well, the "straight ssh forward mapping" does not support call home.  To
quote draft-ietf-netconf-ssh-04.txt:

>   When NETCONF is run over SSH using the mapping defined in
>   this document, the client is always the manager, and the server is
>   always the agent.

> Which ones? I doubt that SNMP based solutions have a call home feature

No, I'm referring to {SNMP/NETCONF}/{SSH/BEEP}.  Let's be clear: there
is no call home function in the NETCONF/SSH mapping.  Even if you do
such a thing for SNMP/SSH, one must use two different call home
mechanisms.  This is how things are lining up and it's the wrong way to go.

> that sort of thing, use BEEP".

While I agree it's always best if she speaks for herself, I don't
believe I am misrepresenting her opinion.  As you can see she followed
through with it in the draft.

> somehow determined yesterday that doing this same approach wastes

Yes, it's the "somehow" that eludes me.  The decision as I repeatedly
said yesterday is premature.

> me and not to the chairs - perhaps too many Juergens around here.)

Again, I apologize if this sounded like a complaint against you.  It was
not meant as such (far from it).  I'm saying that the working group is
going down a perilous path for many many reasons.  It is not just the
chairs and the ADs that need to hear this.  It is the working group as
it is the working group that needs to change course.

Also, all decisions at IETF are confirmed by the mailing list.  I am
saying that this is one we ought not confirm.  Instead, we should
continue with draft development and compare approaches, particularly in
light of the broader context, and then make a decision.

The ADs have made it clear that they want us to finish, and have
suggested that perhaps an interim meeting might help.  I repeat my offer
to the group:  if the group would like to hold an interim meeting, I
would be happy to host it at the end of September in Switzerland.

Eliot

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 3 Aug 2005 10:22:33 -0400

Hi Tom,

> implement such code but if we provide the protocol, I believe 

We have provided the protocol - it is called SNMPv3, and we provided a
standards-based set of MIBs to hold such configuration information.
Making the security remotely configurable was a definite design
decision of the SNMPv3 WG.

It certainly would be possible for a network management application (a
Command Generator) to authenticate itself to the managed entity using
USM (user=HPOV) and then, assuming it had appropriate rights via VACM,
populate the USM tables and the VACM user-to-group mappings for the
person who has authenticated themselve to the application (using OS
security mechanisms). Then the application can perform all SNMP
operations as the individual requesting the operation. 

All of this is imminently doable already, using industry standard
mechanisms (SNMPv3/MIBs) already resident on the networking devices of
most major equipment vendors, and readily available in many toolkits
with host management capabilities.

The application models exist in an application subsystem and new
applications can be developed. Do you want to develop a security model
or new command generator application that performs this type of
forwarded security configuration?

Do you think the application should pass the OS-authentication
username/credentials to the managed entity? I think this would be a
bad practice security-wise. 

Passing OS credentials to a managed device could be a mess
configuration-wise because host-side authentication is typically not
vendor-neutral, and would be difficult to support for all variations
of LDAP server, ActiveDirectory, etc. 

Do you think the application should pass some type of vendor-neutral
authentication credentials into the managed system? Do you think the
protocol to pass on the information should be secure? If so, why not
use SNMPv3 to do so? That's why we provided a standards-based protocol
and data schema for this purpose.

> could be done with them (although not necessarily with all of them).

standards are great, everybody should own one?
Why not use a vendor-neutral standard, such as SNMPv3?

> stem from it. 

I question the need to do this. If HPOV is an authenticated entity
with manageent rights on a remote device, and a user authenticates to
HPOV, why not simply let HPOV request the SNMP operations for the
user? That would minimize the amount of remote configuration needed.
Why go through the whole process of configuring the user credentials
into the managed device and then sending messages using the
authentication information of that principal? Why not just act as a
trusted proxy for that principal (which you would be doing in either
case)?

Oh, because we want to track who made what changes to which managed
objects? I've heard this for years and have never seen it actually
done. How does one do this? I am aware of no standard mechanism that
provides the promised logging or auditing of SNMP operations.
Certainly HPOV could track which requests it performed for which
authenticated users, and that would make it a non-requirement for the
managed station to maintain such auditing info. 

So do we really gain anything by having a Command Generator populate
user info or user-to-group mappings at the time of authentication?

David Harrington
[email-masked]

---

From: Kaushik Narayan <[email-masked]>
Date: Wed, 03 Aug 2005 12:30:41 -0700

Hi David,

>management access control.

Cisco IOS currently has the following mechanisms for access control for
the CLI commands.

Cisco IOS supports 16 privilege levels (0-15) that can be setup
on a RADIUS (TACACS+) server and will be sent to the device using a
Cisco RADIUS VSA (shell:priv-lvl)

http://www.cisco.com/warp/public/480/PRIV.html

More recently we have augmented the privilege level model to support
more flexible RBAC like support with CLI views (a.k.a roles) and we have a 
Cisco
RADIUS VSA (shell:cli-view-name) used to communicate the view name of the 
user to the
device. CLI views (similar to SNMPv3 VACM views) must be defined locally
on the device.

http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a0080455b96.html#wp1073986

In addition to this, TACACS+  also supports per command
authorization, i.e. a TACACS+ authorization  request/response will be used to
authorize each command being received by the device.

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_c/fsecsp/scftplus.htm#1001102

Hope this helps,

kaushik!

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 8 Aug 2005 12:58:42 +0200

<inline>
Tom Petch
----- Original Message -----
From: "David B Harrington" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 02, 2005 6:54 PM
Subject: RE: [Isms] charter proposal

> doesn't belong in the charter at all.
I agree; we should specify the SSH options that are appropriate but no more than
that.  Thus the authentication of the Command Generator will (most likely) be
done by ssh-userauth, which REQUIREs  user (identified by UTF8 string) public
key, and allows user password (with transport level encryption) and host (dns
name, IPaddress) public key.  No mention of any AAA infrastrucutre there nor
should there be.  We might want to comment on the use of host authentication
versus user authentication and its interaction with the concept of SNMP
principal but I would not want to see any more than that.

> security models handle it in a compatible way.
We could require any transport security model to pass than information securely
in the initial exchange, which I believe ssh can do.

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 8 Aug 2005 09:14:15 -0400

Hi Tom,

> that.  Thus the authentication of the Command Generator will 

In writing an SSH proposal, it is my intention to authenticate the
user, not the Command Generator. Authenticating only the command
generator entails a tremendous loss of granularity in identifying the
princiapl, and I do not consider that change of granularity to be in
high demand by the SNMP community, nor do I think there is consensus
of this WG that such a change should be made.  

David Harrington
[email-masked]