Subject: [Isms] ISMS recharter, status update

From: <[email-masked]>
Date: Thu, 18 Jun 2009 20:23:17 +0200

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

----------

---

From: "David Harrington" <[email-masked]>
Date: Thu, 18 Jun 2009 14:51:17 -0400

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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Thursday, June 18, 2009 2:23 PM
> To: [email-masked]
> Subject: [Isms] ISMS recharter, status update
> 

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

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 18 Jun 2009 11:55:03 -0700

>>>>> On Thu, 18 Jun 2009 20:23:17 +0200, <[email-masked]> said:

PE> I made couple of minor edits to the text based on those emails
PE> (current version below), and today the IESG OK'd sending this for 
PE> IETF review (meaning ietf-announce etc.).

Pasi,

Thanks for the good news and for pushing forward on it.  I'm glad to see
progress so that we can try and make the charter deadlines ;-)
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "tom.petch" <[email-masked]>
Date: Wed, 24 Jun 2009 14:02:56 +0200

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