Subject: RE: [Isms] draft of ISMS charter

From: Juergen Quittek <[email-masked]>
Date: Wed, 24 Aug 2005 19:17:03 +0200

David,

Thanks for the improvements.  Please find replies inline.

--On 8/23/2005 12:39 AM +0200 David B Harrington wrote:

> Hi,
>
> Some wordsmithing comments inline.
>
> dbh
>
>> =========================================
>> 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/m
>> aillist.html
>>
>> Description of Working Group
>>
>> The Simple Network Management Protocol version 3 (SNMPv3) provides
>> message security services through the User-based security model
>
> Message security services through the security subsystem, for which
> there is one currently defined model - the User-based security model

Fine.

>> (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
>
> The goal of the ISMS working group is developing a new

Fine.

>> security model for SNMP that integrates with widely deployed user
> and
>> key management systems.
>
> key management systems, as a supplement to the USM security model.

Done.

>>
>> 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.
>
> at managed devices, the new security model will use the SSH protocol
> for
> message protection, and RADIUS for AAA-provisioned user authentication
> and  authorization.

Done.

>> However, the integration of an SSH transport mapping security
>
>> However, the integration of a transport mapping security

Done.

>> 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.
>
> [ 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.]

I see.  I suggest deleting the sentence you refer to.

>>
>> 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
>
> - Specify an architectural extension that describes how transport
> mapping security models (TMSMs) fit into
>
>>     the SNMPv3 architecture.
>>   - 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.

Added.

>>     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.
>
> Dec 2006  Initial version of a document specifying the RADIUS
> authentication and 			authorization mapping model
> for SNMP.

Do you really think we need all five documents?
  - general TMSMs
  - RADIUS attributes for TMSMs (in RADEXT WG)
  - SSH TMSM
  - RADIUS mapping model for SNMP
  - applicability statement

If we add this document here, we also need a final submission
deadline further below.

Thanks,

    Juergen

>> 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
>>
>
>

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

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 25 Aug 2005 17:26:04 -0400

Hi Juergen,

I never answered this question for you.

> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]] 
> >
I think we have seven distinct pieces to document; some may be able to
be combined into the same documents. 

Be aware that the SNMPv3 documents combined architecture discussion
and model-specific stuff to reduce the number of documents, and it has
led to misunderstandings about the separation of architectural issues
from model-specific issues. YMMV.

Here are the things we need to document:
1) the architectural extensions (TMSM) needed to use lower-layer
protocols for message security. 
2) the SSH-specific model (SSHSM) to do this, including examples using
SSH local accounts and SSH-handoff-to-RADIUS for user authentication.

3) the architectural extensions needed to map AAA-provided
authorization into a user-to-group mapping for use by the Access
Control subsystem
4) the RADIUS attributes for management (to be done in the RADEXT WG)
5) the RADIUS-specific model for mapping attributes into a
user-to-group mapping for use by the Access Control subsystem
6) the VACM-specific addendum for mapping the user-to-group
information into a VACM-specific, backwards-compatible format

7) applicability statement, including discussion of the ramifications
of differences in security models - TCP vs UDP, message-based vs
session-based, and so on. 

Personally, I think the WG would be smart to solve 1, 2, and 7 first,
because there are plenty of issues in solving these problems, and we
have volunteers to research and edit the documents on these issues,
and previous work has already started addressing these issues (TMSM,
RFC 3430, Netconf, etc.)

Then we could recharter to solve 3 through 6, which is a separate set
of problems. I have not seen volunteers to research and edit the
documents on these issues, and the attributes we plan to use haven't
even been accepted as RADEXT work items yet, AFAIK. 

David Harrington
[email-masked]

---

From: Kaushik Narayan <[email-masked]>
Date: Thu, 25 Aug 2005 16:15:39 -0700

Hi David,

Please find my reply inline.

<snipped>

>even been accepted as RADEXT work items yet, AFAIK.

I am willing to volunteer to drive the discussions around solutions for #3
to #6 including any editorial responsibilities in documenting the solutions.
There is some ground work done part of our EUSM work and also work
done by Dave Nelson and Greg Weber's in RADEXT would seed this.

regards,
   kaushik!

---

From: Sam Hartman <[email-masked]>
Date: Fri, 26 Aug 2005 12:16:40 -0400

David, are you objecting to the proposed charter or just saying you
would do things differently?

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 26 Aug 2005 14:48:17 -0400

Hi,

I do not object to the proposed charter.

I am suggesting an alternative arrangement of the goals/deadlines that
keeps our promised deliverables in line with our committed resources,
to maximize our ability to meet the charter deadlines. So far, our
chairs have not aggressively recruited volunteers and then held their
feet to the fire to ensure deadlines were met. I am concerned that
committing to deliverables without having volunteers willing to commit
and follow-through to produce those deliverables increases our chance
of failure.

David Harrington
[email-masked]

> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Friday, August 26, 2005 12:17 PM
> To: [email-masked]
> Cc: 'Juergen Quittek'; [email-masked]
> Subject: Re: [Isms] draft of ISMS charter
>