RE: [Isms] charter proposal

["David T. Perkins" <dperkins at dsperkins.com>]

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.
   

On Tue, 2 Aug 2005, David B Harrington wrote:
> 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
> dbharrington at comcast.net
> 
> 
> > -----Original Message-----
> > From: isms-bounces at lists.ietf.org 
> > [mailto:isms-bounces at lists.ietf.org] On Behalf Of Juergen 
> > Schoenwaelder
> > Sent: Tuesday, August 02, 2005 11:33 AM
> > To: isms at ietf.org
> > Subject: [Isms] charter proposal
> > 
> > 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
> > 

Regards,
/david t. perkins


_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms