Subject: [Isms] draft of ISMS charter

From: Juergen Quittek <[email-masked]>
Date: Mon, 22 Aug 2005 18:15:04 +0200

Dear all,

Here is a full text version of the charter items we discussed.
Several phrases are taken from Juergen Schoenwaelder's charter
proposal.

Still open is the issue that Tom raised today:
Shall we have two documents, a general one on TMSMs and a
specific one on SSH security model, or shall we have just
a single document defining architectural considerations and
the SSH security model?

Further open is whether or not we should also work on a
revision of RFC 3430.  Any opinion on that?

Thanks,

    Juergen

=========================================
Integrated Security Model for SNMP (isms)
=========================================

Chair(s):
N.N.
N.N.

Security Area Director(s)
Sam Hartman <[email-masked]>
Russell Housley <[email-masked]>

Security Area Advisor:
Sam Hartman <[email-masked]>

Mailing Lists:
General discussion: [email-masked]
To (un)subscribe: [email-masked]
in body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html

Description of Working Group

The Simple Network Management Protocol version 3 (SNMPv3) provides
message security services through the User-based security model
(USM). However, the USM approach has seen limited deployment so far.
One frequently reported reasons is the lack of integration of USM
key and user management into deployed authentication infrastructures.

SSH is a widely deployed access protocol for remote devices configuration.
Many devices support the integration of SSH user authentication with
AAA systems via protocols such as RADIUS.

The goal of the ISMS working group is developing a new session-based
security model for SNMP that integrates with widely deployed user and
key management systems.

For this integration the working group will define a standard method
for mapping from AAA-provisioned authorization parameter(s) to
corresponding SNMP parameters.

In order to leverage the authentication information already accessible
at managed devices, the new security model will use the SSH protocol.
However, the integration of an SSH transport mapping security model into
the SNMPv3 architecture should be defined such that it is open to support
potential alternative transport mappings to protocols such as BEEP and TLS.

The new security model 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.

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.

The working group will cover the following work items:

  - Specify how transport mapping security models (TMSMs) fit into
    the SNMPv3 architecture.
  - Specify a mapping from AAA-provisioned authorization parameter(s)
    to securityName and other corresponding SNMP parameters.  This
    item might be shared with the RADEXT WG.
  - Define how to use SSH between the two SNMP engines
  - Specify the SSH security model for SNMP.

Goals an Milestones:

Oct 2005  Initial version of a general transport mapping security models
          (TMSMs) document that specifies how TMSMs fit into the SNMPv3
          architecture and that defines the requirements for transport
          mapping security models.
Oct 2005  Initial version of a document specifying RADIUS attributes for
          TMSMs (in RADEXT WG?)
Oct 2005  Initial version of a document specifying the SSH security
          model for SNMP.
Feb 2006  Initial version of an applicability statement that sets up
          reasonable mandatory to implement methods.
Apr 2006  revision RFC 3430 (SNMP over TCP) to ensure it is aligned it
          with the SSH transport model (or move RFC 3430 to historic)
Feb 2005  Submit TMSM document to IESG
Feb 2005  Submit RADIUS attributes for TMSMs to IESG
Jun 2005  Submit SSH TMSM to IESG
Aug 2005  Submit applicability statement to IESG
Aug 2005  Submit revision of RFC 3430 to IESG

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Aug 2005 17:32:54 +0200

> revision of RFC 3430.  Any opinion on that?

I am fine with keeping this out of the ISMS charter - lets see where
ISMS goes and then we can take a decision whether RFC 3430 is worth to
be updated or better should go to historic or just stay around as it
is when we are done.

The other thing to look at is the question where we do the RADIUS
specific work - whether that actually falls within ISMS (which would
be logical since ISMS and the RADIUS stuff must work together) or
whether this actually falls within RADEXT where the RADIUS experts are
hanging around which we need to review the document. I do not have a
strong opinion here - perhaps something the IESG should give advise.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 22 Aug 2005 20:51:17 +0200

Dear all,

I used the wrong year for the last 5 milestones.

In

> Aug 2005  Submit revision of RFC 3430 to IESG

all occurrences of "2005" need to be replaced by "2006".

Thanks to Simon for pointing this out.

    Juergen

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 22 Aug 2005 16:45:51 -0400

Hi,
Comments inline 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen Quittek
> Sent: Monday, August 22, 2005 12:15 PM
> To: [email-masked]
> Subject: [Isms] draft of ISMS charter
> 
> Dear all,
> 

RFC3412 combined both the message processing architecture, in sections
1-5, and the SNMPv3-specific message processing, in Sections 6-7. Very
few people recognize the distinction, and often mistake the way things
are done for SNMPv3 messages as being an architectural requirement. 

I believe it makes more sense to have two documents, one for the
architectural aspects, and a second with the specifics of the SSH
security model.

> revision of RFC 3430.  Any opinion on that?

Some of the issues discussed in RFC3430 will probably need to be
discussed in the TMSM document. I think the WG does not need to take
responsibility for updating RFC 3430.

David Harrington
[email-masked]

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 22 Aug 2005 18:39:43 -0400

Hi,

Some wordsmithing comments inline.

dbh

> Archive: 
> http://www.ietf.org/mail-archive/working-groups/isms/current/m
> aillist.html
> 

Message security services through the security subsystem, for which 
there is one currently defined model - the User-based security model

> The goal of the ISMS working group is developing a new session-based

The goal of the ISMS working group is developing a new

> security model for SNMP that integrates with widely deployed user
and

key management systems, as a supplement to the USM security model. 
> at managed devices, the new security model will use the SSH
protocol.

at managed devices, the new security model will use the SSH protocol
for
message protection, and RADIUS for AAA-provisioned user authentication
and  authorization.

> However, the integration of an SSH transport mapping security 

> However, the integration of a transport mapping security 

> model into

[ The TMSM approach is not complaint with the security model
architectural 
block of SNMPv3, as outlined in RFC 3411. The RFC 3411 architecture
does not permit using a lower-layer protocol to provide
authentication, encryption, and intergity checking. 

Using sessions modifies aspects of the SNMPv3 architecure; The closest
we'll get is to develop architectural extensions compatible with the
philosophy expoused in RFC3411 et al.]
>   - Specify how transport mapping security models (TMSMs) fit into

- Specify an architectural extension that describes how transport
mapping security models (TMSMs) fit into

>   - Specify a mapping from AAA-provisioned authorization
parameter(s)

- Specify an architectural extension that describes how to perform a
mapping from AAA-provisioned user-authentication and authorization
parameter(s)to securityName and other corresponding SNMP parameters.
- Specify a mapping from RADIUS-provisioned authentication and
authorization parameter(s) to securityName and other corresponding
SNMP parameters.
- Specify a mapping from locally-provisioned authentication and
authorization parameter(s) to securityName and other corresponding
SNMP parameters.

>     This

> Oct 2005  Initial version of a document specifying the SSH security

Dec 2006  Initial version of a document specifying the RADIUS
authentication and 			authorization mapping model
for SNMP.