Re: [Isms] ISMS recharter, status update

["David Harrington" <ietfdbh at comcast.net>]

Hi,

I am satisfied with this text, with the understanding that the WG
might choose to design this as two separate user-to-policy-name tables
and a selector table, rather than overloading the existing table.

dbh

> -----Original Message-----
> From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On 
> Behalf Of Pasi.Eronen at nokia.com
> Sent: Thursday, June 18, 2009 2:23 PM
> To: isms at ietf.org
> Subject: [Isms] ISMS recharter, status update
> 
> The ISMS charter has resulted in significant amount of discussion on
> multiple lists (isms, ops-dir, aaa-doctors, mib-doctors -- BTW,
> the archives of the latter two are public if you missed those).
> 
> As far as I can tell, most of the emails have been about details
that
> do not need to be in the charter, but rather need to be discussed
and
> decided in the WG during the work.
> 
> I made couple of minor edits to the text based on those emails
> (current version below), and today the IESG OK'd sending this for 
> IETF review (meaning ietf-announce etc.). If you think further edits

> need to be made (or the ones I made were wrong), please comment 
> on the ISMS WG list.
> 
> I will be mostly off-line starting today until July 20. If there are
> no significant comments, this could be approved by IESG on the July
2
> telechat (even though I won't be there). Anyway, this charter text
can
> be used as the current working assumption when preparing for IETF75.
> 
> In particular, it would be nice to have individual draft(s) for the
> RADIUS work submitted before the deadlines (July 6 for -00) so it
> might be possible to approve them as starting points for further WG
> work in Stockholm. So technical work should not wait for this
> recharter process to complete.
>  
> Best regards,
> Pasi
> 
> ----------
> 
> Integrated Security Model for SNMP (isms)
> 
> Description of Working Group:
> 
> The Simple Network Management Protocol version 3 (SNMPv3) provides
> message security services through the security subsystem.
Previously
> the ISMS Working Group defined a Transport Subsystem definition, a
new
> Transport Security Model, and a Secure Shell Transport Model and a
> method for authenticating SNMPv3 users via the Remote Authentication
> Dial-In User Service (RADIUS).  The initial body of work to be
tackled
> by the working group involved only these pieces.  Additional work on
> other transport models and other security extensions were to wait
> until the initial transport architecture and defining documents were
> completed.
> 
> It is now possible to authenticate SNMPv3 messages via a RADIUS when
> those messages are sent over the newly defined SSH transport.
> However, it still remains impossible to centrally authorize a given
> SNMP transaction as on-device pre-existing authorization
configuration
> is still required.  In order to leverage a centralized RADIUS
service
> to its full extent, the access control decision in the Access
Control
> Subsystem needs to be based on authorization information received
from
> RADIUS as well.  The result will be an extension to obtain
> authorization information for an authenticated principal from
RADIUS.
> The authorization information will be limited to mapping the
> authenticated principal to existing named access control policies,
> defining session timeouts, and similar session parameters.  This
> mechanism will not provision the detailed access control rules.
> 
> Additionally, new work will be undertaken to define TLS and
DTLS-based
> transports that can offer support for environments that prefer
> certificate authentication.  Certificate based authentication is
> desirable for many environments with a centralized authentication
> service.  DTLS also provides datagram-based transmissions which may
be
> desired for environments where TCP performance suffers because of
> network anomalies (e.g. high packet loss rates).  A combination of
TLS
> and DTLS-based transports offers solutions that addresses both the
> need for certificate-based authentication and for datagram-based
> delivery.  Operators will be able to chose the transport solution
that
> best meets their needs.
> 
> The current goal of the ISMS working group is two-fold: to develop a
> method for allowing for access control decisions to be based on
> information provide by an AAA provisioning service and to develop
> TLS-based and DTLS-based Transport Models.
> 
> The new work must not modify any other aspects of SNMPv3 protocol as
> defined in STD 62 (e.g., it must not create new PDU types).
> 
> The working group will cover the following work items:
> 
>   - Specify a mechanism to support centralization of SNMPv3 Access
>     Control decisions by means of a RADIUS-provisioned policy name
>     bound to a username, which the VACM extension will use to
>     dynamically populate the securityToGroupname table.
Additionally,
>     specify a time limit for access decisions, and such a time limit
>     should be used to garbage collect expired dynamic
securityToGroup
>     mappings.
> 
>   - Specify TLS and DTLS transport models for SNMP.
> 
> Goals and Milestones:
> 
> Jul 2009 Publish initial documentation on the (D)TLS 
> transports for SNMP
> Jul 2009 Publish initial documentation for the centralized 
> access control
> Jan 2010 Submit documentation on the (D)TLS transports for 
> SNMP to IESG
> Jan 2010 Submit documentation for the centralized access 
> control to IESG
> 
> ----------
> _______________________________________________
> Isms mailing list
> Isms at ietf.org
> https://www.ietf.org/mailman/listinfo/isms
>