Re: [Isms] ISMS recharter, status update

["tom.petch" <cfinss at dial.pipex.com>]

For those who don't track the ssh list, it looks like there is about to be a
draft for certificates with ssh, which would give another option for certificate
users besides (D)TLS.

Tom Petch


----- Original Message -----
From: <Pasi.Eronen at nokia.com>
To: <isms at ietf.org>
Sent: Thursday, June 18, 2009 8:23 PM
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