Subject: [Isms] reconstructed new charter text -- incorporates recent comments

From: Wes Hardaker <[email-masked]>
Date: Mon, 13 Apr 2009 11:03:10 -0700

After coming back into email-range again and after re-reading the list
from the last week I've pieced together the results of the recent
discussion into a new set of charter text that better describes what I
think everyone agrees to about the RADIUS work.  Specifically, the text
I wrote about it has been replaced by the latest of the text from David
Nelson:

---- Begin proposed charter text ----

Integrated Security Model for SNMP (isms)

Last Modified: XXXX

Additional information is available at tools.ietf.org/wg/isms

Chair(s):
* Juergen Schoenwaelder <[email-masked]>
* David Harrington <[email-masked]>

Security Area Director(s):
* Tim Polk <[email-masked]>
* Pasi Eronen <[email-masked]>

Security Area Advisor:
* Pasi Eronen <[email-masked]>

Mailing Lists:

General Discussion: [email-masked]
To Subscribe: [email-masked]
In Body: 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 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 the View-based
Access Control Model (VACM), to obtain authorization information for an
authenticated principal from RADIUS.  The authorization information will
be limited to mapping the authenticated principal to existing access
control polices, 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 a DTLS-based
transport that can offer support for environments that prefer
certificate authentication and/or datagram-based transmissions.
Certificate based authentication is desirable for many environments with
a centralized authentication service.  Datagram based transports may be
desired for environments where TCP performance suffers because of
network anomalies (e.g. high packet loss rates).  A DTLS-based transport
would offer a solution that addresses both of these situations.

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 a
DTLS-based Transport Subsystem.

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
    username-to-groupname dynamic mapping, that would provide a binding
    between a user and preconfigured VACM policies via dynamic additions
    to 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 the DTLS transport for SNMP.

Goals and Milestones:
Jul 2009        Publish initial documentation on the DTLS transport for SNMP
Jul 2009        Publish initial documentation for the centralized access control
Jan 2009        Submit documentation on the DTLS transport for SNMP to IESG
Jan 2009        Submit documentation for the centralized access control to IESG

-- 
Wes Hardaker
SPARTA National Security Sector
Cobham Analytic Solutions

---

From: "David Harrington" <[email-masked]>
Date: Mon, 13 Apr 2009 16:24:47 -0400

Hu,

The milestones are incorrect. Jan 2009 should either be Jan 2010, or
maybe Dec 2009.

The proposed charter proposes a new DTLS-based subsystem; this should
be DTLS transport model.

Should we also plan on a TLS-based transport model?

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Wes Hardaker
> Sent: Monday, April 13, 2009 2:03 PM
> To: [email-masked]
> Subject: [Isms] reconstructed new charter text -- 
> incorporates recentcomments
> 
> 
> Archive: 
> http://www.ietf.org/mail-archive/working-groups/isms/current/m
aillist.html
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 13 Apr 2009 13:35:14 -0700

>>>>> On Mon, 13 Apr 2009 16:24:47 -0400, "David Harrington" <[email-masked]> said:

DH> The milestones are incorrect. Jan 2009 should either be Jan 2010, or
DH> maybe Dec 2009.

Whoops.  Good catch.

DH> The proposed charter proposes a new DTLS-based subsystem; this should
DH> be DTLS transport model.

Also a good catch.

DH> Should we also plan on a TLS-based transport model?

That is subject to the WG belief that such a transport would be
beneficial.  Personally, I don't see a problem with it and I think it
would be easiest to roll such support into the current DTLS draft rather
than write a second document (in part because the MIBs are likely to
affect both equally).

---- Begin proposed charter text (take 3) ----

Last Modified: XXXX

Chair(s):

Security Area Advisor:

Mailing Lists:

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 a
DTLS-based Transport Model.

Goals and Milestones:
Jul 2009        Publish initial documentation on the DTLS transport for SNMP
Jul 2009        Publish initial documentation for the centralized access control
Jan 2010        Submit documentation on the DTLS transport for SNMP to IESG
Jan 2010        Submit documentation for the centralized access control to IESG

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 13 Apr 2009 22:50:11 +0200

> Should we also plan on a TLS-based transport model?

Speaking as contributor... There once was a TLS proposal:

http://tools.ietf.org/html/draft-marinov-isms-tlstm-00

This draft has not been updated for two years and I am sure it is not
in sync with Wes' DTLS document. But speaking as a contributor, I
prefer to get both TLS and DTLS done at the same time.

Whether this should be a single document or two separate documents, I
do not know yet since I do not yet fully understand how much is common
here. Having DTLS and TLS in different documents has the advantage
that the TMs can move on the standards-track independently at
different speeds.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 13 Apr 2009 14:45:31 -0700

>>>>> On Mon, 13 Apr 2009 22:50:11 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> Having DTLS and TLS in different documents has the advantage that
JS> the TMs can move on the standards-track independently at different
JS> speeds.

I suspect that there will be some common dependencies too, though, as I
mentioned in my other post.  EG, the current DTLS document defines X.509
to securityName mapping infrastructure that would be needed by both
solutions.

The current DTLS document already has two domains for it: DTLS over UDP
and DTLS over SCTP (which itself is subject to debate but I don't think
necessarily impacts the charter discussion).

The bigger question is whether we should be defining a TLS based
transport.  DTLS has the advantage of being UDP (or SCTP) based and was
the primary reason I wanted it available for use since it performs
better (IMHO) in badly behaving networks.  However, others have wanted
it for it's X.509 support (in fact, this aspect was discussed in
Dublin).  If people feel that TLS would be desired because it's TCP
based support might be important for certain environments, then defining
it now certainly seems wise.  Feature wise, it doesn't bring a huge
amount to the table beyond the existing features provided by SSH and
DTLS.  It combines a few of them, of course, and brings both TCP and
X.509 support together.  I'm happy either way.  As I said, I don't think
it's a huge amount of work to add it to the existing document.  Having
just described DTLS/SCTP within the document I'm quite familiar with the
level of effort to add yet another TLS-based transport to the mix).

---

From: "David Harrington" <[email-masked]>
Date: Mon, 13 Apr 2009 20:36:55 -0400

Hi,

In syslog/dtls, Pasi requested that we simply point to the security
features of syslog/tls because it is important to keep them
consistent.

I suspect the security aspects of snmp/tls and snmp/dtls would be
mostly the same, especially the recommended configuration and
mandatory support for certificate processing in the absence of a CA,
etc. Security consideratons might differ slightly because tls and dtls
have different approaches to reliability

I think, but am not sure, that adding tls to the dtls document would
be the simplest approach, possibly by defining the common certificate
processing and then defining three transport models that use the
general processing.

I suspect there will be quite a few devices that have web servers in
them, and would benefit from https for security. I think it also a
good thing to have relatively consistent security configuration for
syslog, netconf, and snmp interfaces.

IANA is considering using snmps to name the snmp/sshtm interface. For
consistency with https, do we want to request that they save snmps for
an snmp/tls interface, and use something like snmpssh to name the
interface?

<from IANA>
Upon approval of this document, IANA will make the following 
assignments in the registered port numbers registry located at
http://www.iana.org/assignments/port-numbers

Keyword Decimal Description References
------- ------- ----------- ----------
snmps tbd(x161)/tcp SNMP over SSH Transport Model
[RFC-isms-secshell-15]
snmps-trap tbd(x162)/tcp SNMP Notification over SSH Transport Model
[RFC-isms-secshell-15]
</IANA>

dbh

> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Monday, April 13, 2009 5:46 PM
> To: David Harrington
> Cc: 'Wes Hardaker'; [email-masked]
> Subject: Re: reconstructed new charter text -- incorporates 
> recentcomments
> 
> >>>>> On Mon, 13 Apr 2009 22:50:11 +0200, Juergen 
> Schoenwaelder <[email-masked]> said:
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 13 Apr 2009 23:28:28 -0400

> syslog, netconf, and snmp interfaces.

Doesn't netconf use SSH?

> Keyword Decimal Description References

IANA doesn't normally make up these names; we're supposed to have requested 
specific names.  In fact, -secshell section 10 does mention the names 
"SSHTM" and "SSHTM-TRAP", but only parenthetically; thus it may have been 
unclear to IANA what we meant.  The appropriate thing to do here is to 
respond and point out the names already mentioned in the document.  This is 
part of why IANA reviews documents at last call -- to insure that IANA's 
understanding of the changes to be made matches that of the working group 
and document authors.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 14 Apr 2009 10:20:09 +0200

> an snmp/tls interface, and use something like snmpssh to name the

Yes, I agree that it might be a better choice to allocate

  snmpssh tbd(x161)/tcp SNMP over SSH Transport Model
  snmpssh-trap tbd(x162)/tcp SNMP Notification over SSH Transport Model

> snmps-trap tbd(x162)/tcp SNMP Notification over SSH Transport Model

If someone disagrees, please speak up now.

/js

---

From: "David Harrington" <[email-masked]>
Date: Tue, 14 Apr 2009 06:51:40 -0400

Hi,

I agree.

dbh 

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Tuesday, April 14, 2009 4:20 AM
> To: David Harrington
> Cc: [email-masked]
> Subject: snmp over ssh iana allocation
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 14 Apr 2009 08:40:09 -0400

> If someone disagrees, please speak up now.

I did reply.  I don't feel particularly strongly about it, but I see no 
reason not to use the names actually mentioned in the SSHTM document, which 
are "sshtm" and "sshtm-trap".  If we decide to use some other set of names, 
the document should be updated to reflect that.

-- Jeff

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 14 Apr 2009 06:22:45 -0700

>>>>> On Tue, 14 Apr 2009 10:20:09 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> snmpssh tbd(x161)/tcp SNMP over SSH Transport Model
JS> snmpssh-trap tbd(x162)/tcp SNMP Notification over SSH Transport Model

Agreed.