Subject: RE: [Isms] ISMS charter discussion

From: "Nelson, David" <[email-masked]>
Date: Mon, 15 Aug 2005 10:49:11 -0400

Juergen Quittek writes...

Specific suggestions in-line, below (DBN).

> -----------------------
> ISMS WG charter outline
> -----------------------
> 
> Background
>   - USM has limited deployment
>   - no standard for integrating key and user management into
>     deployed authentication infrastructures
>   - SSH is widely deployed
>   - SSH integration into AAA, e.g., Redius, is available

DBN:  - SSH integration into AAA, e.g., RADIUS, is available

> 
> WG goals
>   - define a new SNMP security model that utilzes the SSH protocol
>     to provide message security services for SNMP
>   - compliancy with SNMPv3, no modification of SNMPv3

DBN: - compliance with SNMPv3 architecture

>   - work on new access control models and VACM mappings out of scope

DBN: - work on new access control models and VACM mappings out of scope
       (except for mapping via securityName or security Group, see
below)

>   - open to further transport mappings, such as BEEP, TLS, ...
>   ? mentions session concept ?

DBN:  The concept of session is important, and could be easily supported
      via SSH.  I think we need to mention it.

>   ? mention user->group mapping via AAA ?

DBN: - define a standard method for mapping from AAA-provisioned
       authorization parameter(s) to SNMP securityName and securityGroup

>   ? authenticate user or command generator ?

DBN:  Are we talking about device authentication here? That is
      to say, non-human entity authentication?

> 
> Work Items:
>   - specify how transport mapping security models (TMSMs)
>     fit into the SNMPv3 architecture
>   - specify RADIUS attributes used to populate
>     securityName and other SNMP parameters

DBN:  I would specifically mention securityGroup here.

>   - define how to use SSH between the two snmp engines
>   - specify the SSH security model for SNMP
> 
> Documents
>   - A document that specifies how transport mapping security models
>     (TMSMs) fit into the SNMPv3 architecture and which defines the
>     requirements for transport mapping security models.
>   - A document specifying RADIUS attributes for TMSMs (in RADEXT WG?)
>   - A document specifying the SSH security model for SNMP.
>     This specification must comply with the TMSM requirements.
>   - An Applicability statement that sets up reasonable mandatory to
>     implement methods.
>   ? A Revision RFC 3430 (SNMP over TCP) to ensure it is aligned it
>     with the SSH transport model (or move RFC 3430 to historic) ?

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

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 17 Aug 2005 09:21:28 +0200

David,

Thanks for the comments.

> DBN:  - SSH integration into AAA, e.g., RADIUS, is available

Fixed.

> DBN: - compliance with SNMPv3 architecture

Fixed.

>        (except for mapping via securityName or security Group, see

Fine.

>       via SSH.  I think we need to mention it.

What about:

  - following a session-based approach

?

>        authorization parameter(s) to SNMP securityName and securityGroup

fine.

> DBN:  I would specifically mention securityGroup here.

Would we then still need to say "and other SNMP parameters"?

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 17 Aug 2005 11:38:37 +0200

Dear all,

Here is an update based on David's comments:

-----------------------
ISMS WG charter outline
-----------------------

Background
  - USM has limited deployment
  - no standard for integrating key and user management into
    deployed authentication infrastructures
  - SSH is widely deployed
  - SSH integration into AAA, e.g., RADIUS, is available

WG goals
  - define a new SNMP security model that utilzes the SSH protocol
    to provide message security services for SNMP
  - compliancy with SNMPv3 architecture, no modification of SNMPv3
  - work on new access control models and VACM mappings out of scope
    (except for mapping via securityName or security Group)
  - open to further transport mappings, such as BEEP, TLS, ...
  - following a session-based approach
  - define a standard method for mapping from AAA-provisioned
    authorization parameter(s) to SNMP securityName and securityGroup

Work Items:
    securityname and other SNMP parameters

Documents

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 19 Aug 2005 10:18:44 +0200

Dear all,

Please have a look at the outline of our new charter.
You will find the current outline below.

Particularly, I would like you to express your opinion about

  - explicitly mentioning securityName and securityGroup
  - having a revision RFC 3430 as one of our work items

Ken and I will turn the outline into a text version and post
it on Monday.  Then we will have next week for discussing wordings.

Thanks,

    Juergen

-----------------------
ISMS WG charter outline
-----------------------

Background

WG goals
    (except for mapping via securityName or securityGroup)

Work Items:

Documents
  ? A revision RFC 3430 (SNMP over TCP) to ensure it is aligned it

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 22 Aug 2005 15:11:50 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Juergen Quittek" <[email-masked]>
To: <[email-masked]>
Sent: Friday, August 19, 2005 10:18 AM
Subject: RE: [Isms] ISMS charter discussion

> it on Monday.  Then we will have next week for discussing wordings.

Not quite right IMHO; even with SSH, there is no standard for integrating SSH
with eg RADIUS (nor do I think isms should work on one).  Rather it is the
nonstandard approach - in the sense of not conforming to pre-existing standards,
RFC 3414 itself is of course a standard - to key and user management taken by
USM that makes integration difficult.  Defining SNMP over SSH leverages the
existing deployments of SSH which have performed this integration to the
satisfaction of users - how, I would love to know, but noone seems to know, but
what the heck, they have done it so we should trust them and get on with it.

>   - open to further transport mappings, such as BEEP, TLS, ...

I think it wrong to include this potential can of worms at this point in time;
later, yes.
As several have pointed out, achieving consensus in isms is hard work.  I
strongly believe we should focus on as limited an objective as is beneficial at
this time, the one transport we select, to give us the best chance of success.
We can always request a more relaxed charter once we have achieved our next
goal; allowing all possible options in
parallel at this time can only dilute our efforts and make success less likely.

>   - define how to use SSH between the two snmp engines

this is overwhelmingly IMHO the top of the list (assuming we reach consensus on
SSH as the chosen protocol)

>     (TMSMs) fit into the SNMPv3 architecture and which defines the

Disagree, for the reasons stated above.  We should focus on making work our one
chosen transport. Considering all the features present and
not present in other alternatives that we have not chosen can only compromise
this one; if I support the choice of protocol X because it fits well with SNMP
on account of unique features A and B, but then we are not allowed to use
features A and B because they are not present in protocols Y
or Z and so cannot form part of a generic TMSM. Forget it, choose a protocol and
may be we can make it work.

USM is one document, model, protocol, MIB module etc; I see no benefit in
splitting up our work into multiple documents.

---

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

Hi Tom,

Thanks for the comments.  Please see replies inline.

> what the heck, they have done it so we should trust them and get on with it.

I agree in general and take the 'no standard' phrase out.

> parallel at this time can only dilute our efforts and make success less likely.

I think it is important to be open to future transport mappings.
This does not imply that a BEEP or a TLS security model is included
in the charter.  But this (hopefully) also does not discourage
people working on other solutions.

> splitting up our work into multiple documents.

I want to see more opinions on this issue.
I see your point, but I am not yet convinced.

Thanks,

    Juergen

---

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

> I see your point, but I am not yet convinced.

TMSM is an architectural document by nature which explains how a
transport mapping security model fits into the existing SNMPv3
architecture. We need in addition a document which defines how SNMP
over SSH actually works (and I would have no problem to include in
this document an applicability statement if the goal is to reduce the
number of documents).

It is an open question for me whether the RADIUS specific work belongs
into RADEXT rather than ISMS - but in any case, I consider this
another document.

You seem to dislike the architectural work Dave has been doing and
from the emails I have read you seem to prefer to have things muddled
together in one piece of document. I do not think this is the right
approach - in fact, the BEEP document does refer back to the TMSM
document so there seems to be some value in having worked out the
architectural issues separate from the SNMP over SSH details.

Anyway, it is fine to have different opinions. I think I just stated
my preference.

/js

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

---

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

> this time, the one transport we select, to give us the best 

I agree that we need to allow for this potential can of worms later,
and that for now we should focus on one chosen security model.

For that reason, I believe we need to discuss how additional proposals
fit within the architecture of SNMPv3, i.e. by defining an
architectural extension in TMSM to show how multiple models could
exist concurrently (in keeping with the general philosophy of RFC
3411), and by focusing the WG efforts on ONE security model based on
SSH ast this time.

If proponents of alternative models want to spend time developing
their proposals in parallel, I have no problem wth that, since we
obviously cannot prohibit them from doing so, but the WG should assign
no resources to that task, and should be careful that input from the
parallel effort be constrained to being relevant to the SSH proposal
or TMSM architectural extension.

> splitting up our work into multiple documents.

USM is one document, one model WITHIN the SNMPv3 architecture. RFC3414
cannot stand alone.

ISMS is not working on developing one security model WITHIN the SNMPv3
architecture; It appears to be the consensus of the ISMS WG to also
include 
1) new transport mappings (TCP-based transport PLUS "application"
layers such as TLS, BEEP, and SSH), 
2) message security applied by the transport mapping/application layer
rather than in doing it strictly within the RFC3411 security
subsystem,
3) sessions that can be used for multiple SNMP messages, 
4) authorization mappings from authenticated identities to access
control groupNames, and so on.

These are significant changes to the architecture defined in RFC3411
and RFC3412 and other SNMPv3 documents. The TMSM document serves the
purpose of identifying the architectural changes, and defining how
TMSM-based models fit within the SNMPv3 architecture. That is very
different than simply defining a security model within the RFC3411
security subsystem.

The TMSM document also provides a place to discuss the common issues
that will apply to future TMSM-based security models, such as session
management.

David Harrington
[email-masked]