Subject: [Isms] status and future of the isms working group

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Sep 2010 10:20:39 +0200

Hi,

as you might have noticed, the last chartered WG document has been
approved by the IESG yesterday. I like to thank our document editors
and everybody who contributed to the development of this document.

The ISMS working started in 2004 to address the concern raised by
operators that using USM with its own key management scheme is costly.
The WG produced 6 RFCs (one still in the RFC editor queue) detailing:

- a transport subsystem of the RFC 3411 SNMP architecture
- a new transport security model supporting multiple secure transports
- an SSH secure transport model
- a DTLS/TLS secure transprot model
- the usage of RADIUS for session authorization
- the usage of RADIUS to provision VACM user to group mappings

This pretty much completes the mission of this WG and the natural next
step would be to close down this working group once the RFCs all have
appeared.

However, there might also be well justified reasons to keep the WG
running. One of them could be the advancement of some RFCs to Draft
standard. See section 4.1.2 of RFC 2026 for the detailed requirements
of a Draft standard. Please let the chairs know if you think the WG
should untertake such an activity. Please also mention whether you can
contribute implementation reports, provide interoperability tests, can
help with any document editing that might be needed etc.

If you think some other work should be undertaken by this WG, people
start a thread on the mailing list where you propose the work to be
done and where we can get a discussion going to see how much support
there is in the WG and how many people are willing to commit to help
with document editing and document reviewing tasks. As we have learned
here several times, writing SNMP specifications is not an easy task
given the architectural and terminology framework we are working
with. It is thus crucial to have sufficient people involved in the
reviewing and wordsmithing as well as the work needed to originally
produce and edit the specifications.

/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: "David Harrington" <[email-masked]>
Date: Fri, 17 Sep 2010 05:57:31 -0400

Hi,

I would like to take this opportunity to thank this working group.
I enjoyed working with all of you getting these specifications
produced. 
Juergen, thank you for providing a steady helm for a fairly turbulent
journey.

I have two suggestions for further ISMS work.

1) I think gathering implementation reports can be a good thing. I am
not sure how much having a document advance to Draft Standard is
important in the real world, but implementation reports could help
vendors decide which specfications to support in their products, and
possibly which toolkits might be useful in their product engineering.
So I do encourage this activity.

2) As you observe, and as I have experienced as an ISMS editor, it is
not easy writing SNMP specifications; the RFC 3411 architecture is
rather difficult to work with. Comparing the SNMP/TLS document with
the SYSLOG/TLS or Netconf/TLS documents readily shows that the SNMP
architecture adds tremedous complexity to IETF specifications for
SNMP. I believe this complexity makes maintaining and/or extending
SNMP far more difficult than is justified by the benefits of the RFC
3411 architecture in SNMP standards development.

RFC 3411 was very explicitly "AN" architecture for describing SNMP
frameworks. It was never meant to be "THE" mandatory architecture for
SNMP frameworks. It was written to be highly modular largely because
there were many demands for different designs by different segments of
the industry. During the "SNMP wars", there was tremendous acrimony,
and many people unwilling to compromise on their demands for various
design decisions, such as simplicity versus additional features. The
RFC3411 modular architecture allowed the SNMP community to develop
models following the 90/10 rule; we produced standard models that
addressed the most common demands, and allowed for subsequent
development of additional models to meet the demands of specific
industry segments. Additional models to meet the specific demands
identified at that time never materialized. But we have been burdened
with the RFC 3411 architecture, and its Abstract Service Interfaces,
ever since.

I would like to recommend a new work item for ISMS - design a new
architecture standard for SNMP development. 
I recommend developing "A Simple Architecture for Describing SNMP
Frameworks" that is more consistent with the simpler layered
architectural models used for Netconf [RFC 4741, section 1.1] and
Syslog [RFC 5424 section 3], to bring simplicity back into SNMP
standards development. 

This should be accompanied by an update to RFC 3410 that would include
discussion of the simpler architecture, secure transport, engineID
discovery, RADIUS support, syslog-snmp mappings, and the SMI-XML
datatypes. There has been lots of work in SNMP that is not reflected
in RFC 3410. Since RFC3410 is "Introduction and Applicability
Statements for Internet-Standard Management Framework", this update
might also discuss the comparative applicability of SNMP, Netconf,
Syslog, and Ipfix standards.

I do not have the time to edit such documents, but would be willing to
provide reviews for such an effort.

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Friday, September 17, 2010 4:21 AM
> To: [email-masked]
> Subject: [Isms] status and future of the isms working group
> 
> Hi,
> 
> as you might have noticed, the last chartered WG document has 
> been approved by the IESG yesterday. I like to thank our 
> document editors and everybody who contributed to the 
> development of this document.
> 
> The ISMS working started in 2004 to address the concern 
> raised by operators that using USM with its own key 
> management scheme is costly.
> This pretty much completes the mission of this WG and the 
> natural next step would be to close down this working group 
> once the RFCs all have appeared.
> 
> However, there might also be well justified reasons to keep 
> the WG running. One of them could be the advancement of some 
> RFCs to Draft standard. See section 4.1.2 of RFC 2026 for the 
> detailed requirements of a Draft standard. Please let the 
> chairs know if you think the WG should untertake such an 
> activity. Please also mention whether you can contribute 
> implementation reports, provide interoperability tests, can 
> If you think some other work should be undertaken by this WG, 
> people start a thread on the mailing list where you propose 
> the work to be done and where we can get a discussion going 
> to see how much support there is in the WG and how many 
> people are willing to commit to help with document editing 
> and document reviewing tasks. As we have learned here several 
> times, writing SNMP specifications is not an easy task given 
> the architectural and terminology framework we are working 
> with. It is thus crucial to have sufficient people involved 
> in the reviewing and wordsmithing as well as the work needed 
> to originally produce and edit the specifications.
> 
> /js
> 
> -- 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Sep 2010 12:11:02 +0200

> Syslog [RFC 5424 section 3], to bring simplicity back into SNMP

ISMS stands for "Integrated Security Model for SNMP" and it seems the
work you are proposing really calls for a different working group,
likely located in the OPS area not in the security area (as can be
seen by the ADs you have put on the CC).

/js

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Sep 2010 15:48:22 +0200

While I agree with Juergen on the logistics, I think Dave highlights
interesting work to consider undertaking.  My only concern is that it
seems like people have tried to do this before, in particular in the
NMRG.  What's the trigger for success?

Eliot

---

From: "David Harrington" <[email-masked]>
Date: Fri, 17 Sep 2010 10:24:15 -0400

Hi,

NMRG worked on information/data models (RFC3444) and XML-based NM
(e.g., through proxies).

I don't believe NMRG ever tried to write a new SNMP architecture
document.
and in the IETF, WGs have been told that modifying the RFC 3411
architecture is definitely out of scope. 
The EOS and SMING and ISMS WGs were all told to "work within" the
RFC3411 architecture.
I think that restriction was part (but only part) of the reason for
the failures of EOS and SMING.
We only got to modify the architecture in ISMS when we needed to
define a transport subsystem in rfc5590.
So I don't agree this has been tried before.

I think SNMP could be brought out of the 1980's, but first we need to
make it easier to add new features, such as new operations, and new
data modeling approaches. I think the RFC3411 architecture makes it so
hard to write any extensions, even models that fit within the RFC3411
architecture, that it greatly increases the complexity. 
A simpler architecture would allow SNMP to be maintained and updated
more easily.

Netconf can certainly do some of the things that an extended SNMP
might, but netconf is designed for a different usage scenario. I
certainly would think twice about using Netconf to repeatedly poll
sysuptime from multiple devices across my network as a liveness and
reachability detector.

dbh

> From: Eliot Lear [mailto:[email-masked]] 
> Sent: Friday, September 17, 2010 9:48 AM
> To: David Harrington; [email-masked]; 'ext Romascanu, Dan 
> (Dan)'; Ron Bonica
> Subject: Re: [Isms] status and future of the isms working group
> 
>  While I agree with Juergen on the logistics, I think Dave 
> highlights interesting work to consider undertaking.  My only 
> concern is that it seems like people have tried to do this 
> before, in particular in the NMRG.  What's the trigger for success?
> 
> Eliot
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 17 Sep 2010 16:37:57 +0200

1. I agree that it's time to think about a new architecture which is
multiprotocol and does not impose the restrictions that 3411 had put on
SNMP. This work should start from the usage scenarios for SNMP, NETCONF
and other protocols and how we see them used by operators in real life
deployments. The example given by David was maybe talked about many
times, but was not (to my knowledge) put in any document.  

2. I think this discussion exceeds the scope of ISMS. I suggest to move
it on [email-masked]

Dan

> From: David Harrington [mailto:[email-masked]] 
> Sent: Friday, September 17, 2010 4:24 PM
> To: 'Eliot Lear'; [email-masked]; Romascanu, Dan (Dan); 'Ron Bonica'
> Subject: RE: [Isms] status and future of the isms working group
> 
> Hi,
> 
> NMRG worked on information/data models (RFC3444) and 
> XML-based NM (e.g., through proxies).
> 
> I don't believe NMRG ever tried to write a new SNMP 
> architecture document.
> and in the IETF, WGs have been told that modifying the RFC 
> 3411 architecture is definitely out of scope. 
> I think that restriction was part (but only part) of the 
> reason for the failures of EOS and SMING.
> We only got to modify the architecture in ISMS when we needed 
> to define a transport subsystem in rfc5590.
> I think SNMP could be brought out of the 1980's, but first we 
> need to make it easier to add new features, such as new 
> operations, and new data modeling approaches. I think the 
> RFC3411 architecture makes it so hard to write any 
> extensions, even models that fit within the RFC3411 
> A simpler architecture would allow SNMP to be maintained and 
> updated more easily.
> 
> Netconf can certainly do some of the things that an extended 
> SNMP might, but netconf is designed for a different usage 
> scenario. I certainly would think twice about using Netconf 
> to repeatedly poll sysuptime from multiple devices across my 
> network as a liveness and reachability detector.
> 
> dbh
>  
> 
> (Dan)'; Ron 
> > Bonica
> highlights

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 17 Sep 2010 09:44:10 -0700

>>>>> On Fri, 17 Sep 2010 10:20:39 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> However, there might also be well justified reasons to keep the WG
JS> running. One of them could be the advancement of some RFCs to Draft
JS> standard.

As you know based on our discussions and the messages that you've seen
recently from us about interoperability testing, I'm very interested in
pushing the 5953 to the Draft level.  We have two implementations of
5953 that already interoperate and we're continuing to work further to
perform even more testing between the two implementations.

I do see the "Draft" level standard as being an important step.  I know
in the IETF we've frequently wondered "whether it's worth it or not",
but I think definitely is as it shows the user community that a protocol
is considered important by the vendors that are offering it.  Most
importantly, when the protocol is a mission critical protocol then
advancing it to Draft shows that the protocol has been tested and is
thus more likely to get deployment.  Operators that make use of
management protocols like SNMP have always been wary of using new
features because SNMP is such a mission-critical protocol.
Demonstrating and documenting interoperability shows that the technology
is ready for deployment.

I would like to request that the ISMS working group take on the work of
documenting the interoperability results and pushing the 5953 (and
the needed pre-requisites mentioned in my other message) forward to
Draft.  I and other members of my team at Cobham are very willing to
help write, edit and review documents that work toward this goal.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "t.petch" <[email-masked]>
Date: Mon, 20 Sep 2010 09:28:49 +0200

----- Original Message -----
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "David Harrington" <[email-masked]>; "Eliot Lear" <[email-masked]>;
<[email-masked]>; "Ron Bonica" <[email-masked]>
Sent: Friday, September 17, 2010 4:37 PM

> times, but was not (to my knowledge) put in any document.

RFC3411 was a great piece of work, but turned out to be fatally flawed.  The
first time it was put to the test, introducing a new security model, it proved
unusable.  At the same time, the IESG said it was immutable and the isms working
group wasted years squaring that circle, producing RC5590 which is, to any
independent observer, replacing parts of RFC3411.  So great piece of work,
causing much damage.  With the benefit of hindsight, the isms working group
should have said 'Mission Impossible' and refused to continue until it was
allowed to replace RFC3411 (but I did not see that until 2008:-(

I see no reason to suppose we would do any better now, be it a single or multi
protocol architecture.

At the same time, there is activity currently taking the Management out of OAM,
in the mpls-tp nexus but in other related activities as well and it is that that
I think needs tackling.  What is management?  Can we agree an IETF wide
definition any more? I see
draft-ietf-opsawg-mpls-tp-oam-def
as just the tip of this iceberg.

Tom Petch

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 20 Sep 2010 12:28:06 +0200

Hi Tom,

See in text. 

Regards,

Dan

> From: t.petch [mailto:[email-masked]] 
> Sent: Monday, September 20, 2010 9:29 AM
> To: Romascanu, Dan (Dan); David Harrington; [email-masked]; Ron Bonica
> Cc: [email-masked]
> To: "David Harrington" <[email-masked]>; "Eliot Lear" 
> <[email-masked]>; <[email-masked]>; "Ron Bonica" <[email-masked]>
> > multiprotocol and does not impose the restrictions that 
> 3411 had put 
> > on SNMP. This work should start from the usage scenarios for SNMP, 
> > NETCONF and other protocols and how we see them used by 
> operators in 
> > real life deployments. The example given by David was maybe talked 
> > about many times, but was not (to my knowledge) put in any document.
> 
> RFC3411 was a great piece of work, but turned out to be 
> fatally flawed.  The first time it was put to the test, 
> introducing a new security model, it proved unusable.  At the 
> same time, the IESG said it was immutable and the isms 
> working group wasted years squaring that circle, producing 
> RC5590 which is, to any independent observer, replacing parts 
> of RFC3411.  So great piece of work, causing much damage.  
> With the benefit of hindsight, the isms working group should 
> have said 'Mission Impossible' and refused to continue until 
> it was allowed to replace RFC3411 (but I did not see that 
> until 2008:-(
> 
> I see no reason to suppose we would do any better now, be it 
> a single or multi protocol architecture.

Does this mean that we should not / need not try? 

> 
> At the same time, there is activity currently taking the 
> Management out of OAM, in the mpls-tp nexus but in other 
> related activities as well and it is that that I think needs 
> tackling.  What is management?  Can we agree an IETF wide 
> definition any more? I see draft-ietf-opsawg-mpls-tp-oam-def 

One of the points that draft-ietf-opsawg-mpls-tp-oam-def makes is that
management is not part of OAM, the M in the trinity standing for
Maintenance. Right now draft-ietf-opsawg-mpls-tp-oam-def is being
returned by the IESG to the OPSAWG with the recommendation to broaden
its scope beyond mpls-tp. I would agree that it's still the tip of the
iceberg.  

> Tom Petch
> 
> 
> 
> 
> >
> > 2. I think this discussion exceeds the scope of ISMS. I suggest to 
> > move it on [email-masked]
> >
> > Dan
> >
> >
> > > I think SNMP could be brought out of the 1980's, but 
> first we need 
> > > to make it easier to add new features, such as new 
> operations, and 
> > > new data modeling approaches. I think the
> extensions, even 
> > > models that fit within the RFC3411 architecture, that it greatly 
> > > increases the complexity.
> > > > >> I would like to recommend a new work item for ISMS - 
> design a 
> > > > >> new
> > >
> > > > >> architectural models used for Netconf [RFC 4741, 
> section 1.1] 
> > > > >> and
> > >
> > > > > likely located in the OPS area not in the security 
> area (as can 
> > > > > be
> > >

---

From: "t.petch" <[email-masked]>
Date: Mon, 20 Sep 2010 11:57:49 +0200

----- Original Message -----
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "t.petch" <[email-masked]>; "David Harrington"
Cc: <[email-masked]>
Sent: Monday, September 20, 2010 12:28 PM

<tp>
I think that our resources are limited, and tend to decay with the age of a
working group, so I would rather see them applied elsewhere.  I look back at the
effort that went into RFC3411, over many years, and yet it fell at the first
hurdle, not accommodating the move of security from deep inside the engine to
off the bottom of the radar; why should we do any better this time?

I see comparisons with the architecture of syslog and netconf, and yet ...
There is a structure of layers, hardly an architecture.  syslog was doing nicely
without it, and I am not sure that it is any better with it.  netconf has been
debating recently how and where the messages should be delineated within a
stream transport, with various views of what it means in architectural terms,
yet I see the architecture as no help in resolving the issue of delineation.

So, potentially much work, for little or no gain.

Tom Petch

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 20 Sep 2010 10:04:37 -0700

Hi -

> From: "t.petch" <[email-masked]>
...
> off the bottom of the radar; why should we do any better this time?
...

The problem as I see it was that RFC3411 was intended to be the glue
describing how a particular set of specifications fit together, *not* as
*the* architecture for all future SNMP work.  *Requiring* extensions,
additions, and embellishments to adhere to that architecture is in
my opinion a huge mistake.  From my perspective, the real problem
addressed by RFC 3411 was that some of the preceding proposals
for securing SNMP had so many convolutions and interactions that
a lot of folks had trouble wrapping their heads around them.  The
modularity brought by RFC 3411 was modularity of *specification*,
not necessarily implementation.  The ASIs were rather controversial
because folks were (rightly, in retrospect) concerned that they would
be understood in a prescriptive sense, rather than descriptive sense
in which they were intended.

More importantly, I think focusing energy on this "problem" (which is
tempting because it's something we think we understand) would be
a huge distraction from the *real* problem: the kinds of information models
this infrastructure should provide access to.  If the information models
can't support the high-value functions administrators / operators need,
then embellishing the protocol engine architecture is a waste of time.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 20 Sep 2010 11:43:29 -0700

>>>>> On Mon, 20 Sep 2010 09:28:49 +0200, "t.petch" <[email-masked]> said:

tp> RFC3411 was a great piece of work, but turned out to be fatally
tp> flawed.  The first time it was put to the test, introducing a new
tp> security model, it proved unusable.

Well, I'm not sure that's an entirely fair characterization.  The
problem wasn't that the model was flawed, it was that it wrapped *only*
around its own notion of the SNMP protocol.

When ISMS came along and the decision was to outsource the security to
something in a lower layer, then yes the original model had issues with
that because it didn't take that possibility into account.  5590 simply
fixed that.  Interestingly enough by providing some extra transmission
lines to the model and extra information to the data passed via the
ASIs.

However, the ISMS solutions were the first "standardized" ones.  More
documents and code have been written to provide other security models
that were either implemented or partially implemented and worked just
fine without changing the underlying 3411 model: KSM (which is now being
brought forward again) and SBSM (which is how the ISMS working group got
started but went the SSH-underneath route instead of an
in-SNMPv3-protocol integrated model).
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "t.petch" <[email-masked]>
Date: Mon, 20 Sep 2010 22:31:33 +0200

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Romascanu, Dan (Dan)" <[email-masked]>; "David Harrington"
<[email-masked]>; <[email-masked]>; "Ron Bonica" <[email-masked]>;
<[email-masked]>
Sent: Monday, September 20, 2010 8:43 PM
> lines to the model and extra information to the data passed via the

Well, yes and no.  In isms, we retained the idea of 'no sessions', and I was
interested to see in the most recent I-D ....  vacmAaaSessionID OBJECT-TYPE

I always thought that SNMP had sessions, just that some of them were rather
short, and I that that is another disconnect that took quite a lot of time to
sort out in the isms work; it would have been easier if RFC3411 or RFC5590 had
had sessions in the architecture.

And yes, I am making my point quite strongly, because I think that an 'RFC6411'
would be a poor use of IETF resources.

Tom Petch

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 20 Sep 2010 17:30:52 -0700

>>>>> On Mon, 20 Sep 2010 22:31:33 +0200, "t.petch" <[email-masked]> said:

tp> And yes, I am making my point quite strongly, because I think that
tp> an 'RFC6411' would be a poor use of IETF resources.

Well, I won't dive into "sessions" because it's way beyond a useful
argument at this point.

But, I will agree I don't think the WG should go down the path of
defining a new architecture.  It just won't help much.

As I've said before, I think it's more important that developers can or
can't make the changes need to create a feature.  The architecture was a
way to say "if you can make the architecture bend in this way, then all
the implementations should".  But because we can, in general, enumerate
the SNMPv3 stack implementations on one hand it's not hard to survey
them and say "could you implement this new feature of the protocol in
your implementation"?

Trying to define a model that will always account for every way you
might need to break the rules in the future is an impossible task.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Sep 2010 08:36:21 +0200

> defining a new architecture.  It just won't help much.

The ISMS working group is not going to do any architecture work. This
is way out of the scope of the ISMS charter. Hence, I would appreciate
if any followup discussion of the SNMP architecture or the lack of a
multiprotocol network management architecture moves to the
<[email-masked]> mailing list.

Summarizing the discussion so far, I have only seen a proposal to
extend the ISMS lifetime in order to move some of the WG RFCs to Draft
Standard. There are two independent implementations and
interoperability testing is ongoing. If others are implementing or
planning to do so very soon, this would be nice to know.

/js

---

From: "t.petch" <[email-masked]>
Date: Tue, 21 Sep 2010 16:22:42 +0200

----- Original Message -----
From: "Jon Saperia" <[email-masked]>
To: "Randy Presuhn" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, September 20, 2010 7:43 PM

> I could not agree more.
>
> I would add  that additional protocol/architecture/framework on any of the
management infrastructures we have does not address the key point I took from
Randy's post.  What we need are widely implemented objects (however you want to
call the structures) that give real visibility into what is going on in the
devices and networks.  That has always been the problem and until we address
that who cares how we transport the data. I would settle for RFC2549, if it
contained the right information.
Jon

My current hot button is not data but protocols.  I am worried about the
explosion in 'OAM' (ie ping, traceroute etc) protocols to run in the MPLS
dataplane, that are being defined in the MPLS-TP nexus.  Before long, we might
have Y.1731 as a standards track RFC:-(

I was relieved to see the IESG sending back
draft-ietf-opsawg-mpls-tp-oam-def
but what happens next, metaphorically speaking? I would rather more people with
a background in the IETF were involved with this.

Tom Petch

> /jon
> On Sep 20, 2010, at 1:04 PM, Randy Presuhn wrote:
>
> > Hi -
> >
> > OPS-AREA mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ops-area
> >
>
> OPS-AREA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-area

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 23 Sep 2010 08:13:19 +0200

Since advancement of the SNMP over [D]TLS specification has to wait
until early next year, I do not plan to ask for a WG meeting slot at
the upcoming IETF in Beijing. If you believe a WG meeting is needed,
speak up as soon as possible but no later than Sunday September 26th.

/js

---

From: "Pejaver, Rajaram" <[email-masked]>
Date: Fri, 24 Sep 2010 11:16:03 -0400

Juergen,

At Comcast, we are interested in defining the KSM security model.
An initial draft proposal was submitted to this WG on July 7, 2010.
A copy is at
http://www.lee-networks.com/draft-pejaver-isms-kerberos-00.txt

We are implementing it and expect to test it soon.
If it is successful, we will require our vendors to support it.
We would like the ISMS WG to consider adopting this work.

Besides Comcast, we have a working group hosted by CableLabs addressing
this issue.
This WG consists of several Cable companies, including Cablevision, Cox,
& Time Warner.

Regards

Rajaram Pejaver & Yiu Lee
Comcast Cable

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Schoenwaelder
Sent: Thursday, September 23, 2010 2:13 AM
To: [email-masked]
Subject: Re: [Isms] status and future of the isms working group

/js

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 24 Sep 2010 14:00:42 -0400

> http://www.lee-networks.com/draft-pejaver-isms-kerberos-00.txt

Comments the content of the draft:

   SNMPv3 allows the definition of new security models.  The first
   security models [I-D.ietf-isms-radius-vacm] defined, USM and VACM,
   did not support centralized security administration.

DBN:  [I-D.ietf-isms-radius-vacm] is not a reasonable reference for "first security models".

   Recent work based on session based approaches are not 
   suitable for large networks containing untrusted managed devices.

DBN: Can your provide a technical justification for this assertion?

   Ideally, RADIUS and Two factor authentication should be invoked only
   once when the administrator is "logging in".  These services should
   not be invoked each time a different managed device is selected.  If
   RADIUS is the source of authorization information, then this
   information should be cached somewhere.  Alternatively, it can be
   inserted into the AuthorizationData field in the TGT.  Thereafter,
   this data can be copied from the TGT into each service ticket.

DBN:  This section seems a bit sketchy.  Does it intent to indicate any actual integration between RADIUS and Kerberos, e.g. a shard back-end user/principal and authorization database?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 24 Sep 2010 21:23:09 +0200

> This WG consists of several Cable companies, including Cablevision, Cox,

So will this group contribute actively to the work of ISMS or will it
remain a closed group at CableLabs? As said earlier, we need to make
sure we have sufficient human resources available for any new work.
It will also help if you can come up with a suggested timeline for
this work.

/js

---

From: "Yiu L. Lee" <[email-masked]>
Date: Fri, 24 Sep 2010 15:28:48 -0400

Hi Juergen,

We would like to make it as openly as possible. This is why we submitted the
draft to IETF. We also like to see any other in the WG is also interested in
this work.

>From the timeline perspective, we would like the WG would adopt this a WG
item (if we get enough interested people) this year and WGLC Q1/Q2 next
year. Do you think this timeline reasonable?

Thanks,
Yiu

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 24 Sep 2010 13:05:08 -0700

>>>>> On Fri, 24 Sep 2010 21:23:09 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> So will this group contribute actively to the work of ISMS or will it
JS> remain a closed group at CableLabs? As said earlier, we need to make
JS> sure we have sufficient human resources available for any new work.

I'd like to see the work continue through the WG and would be willing to
read/review the document.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Pejaver, Rajaram" <[email-masked]>
Date: Fri, 24 Sep 2010 16:24:29 -0400

David,

> DBN:  [I-D.ietf-isms-radius-vacm] is not a reasonable reference for
"first security models".

Agreed.  It should have been RFC3414 USM.

> DBN: Can you provide a technical justification for this assertion?

Our target devices include millions of Cable Modems and TV Set top
boxes.
An ssh session involves sending an administrator's ID & password to the
modem so that it can do RADIUS authentication.
These devices which reside in our customer's homes may have been
compromised and cannot be trusted with admin credentials.
GSSAPI helps, but may not work if authorization values are to be
retrieved from RADIUS as in draft-ietf-isms-radius-vacm.
Also, every managed device would need to be a RADIUS client.

An ssh session requires establishing a TCP connection and exchanging a
few packets to set up the ssh session.
When we want to periodically poll many devices for a SNMP status
snapshot, a simple UDP request & response is more preferable.

Lastly, for low end devices like CPE bridges, it would be nice if they
did not need to maintain state between SNMP requests.

> DBN:  This section seems a bit sketchy.  Does it intent to indicate
any actual integration between RADIUS and Kerberos, e.g. a shard
back-end user/principal and authorization database?

Agreed.  We suggest that the initial proposal not deal with RADIUS and
2factor authentication.  I was trying to describe the flow in an ideal
situation.
We have ideas for how to integrate Kerberos & RADIUS, and would be glad
to present them, but it is a whole different discussion.  (It would also
need to be prototyped)
It is much easier to integrate a stock Kerberos server with a vanilla
LDAP based authorization database.

Regards

Rajaram Pejaver
Comcast Cable, NETO

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 24 Sep 2010 22:27:22 +0200

> year. Do you think this timeline reasonable?

It all boils down to the resources put into this. From a cursory read
of the I-D, I think some work needs to be done to get the document
into a shape that fits the RFC3411 architecture etc. I have not looked
at the details of the Kerberos interface itself and of course it would
help a lot if some Kerberos expert gets involved into this. So we are
again back at the resources. ;-)

/js

---

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Sun, 26 Sep 2010 19:33:52 -0400

I am in support of the WG adopting this item and am willing review the
draft documents. 
-- Andy Donati

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Schoenwaelder
Sent: Friday, September 24, 2010 4:27 PM
To: Yiu L. Lee
Cc: [email-masked]
Subject: Re: [Isms] status and future of the isms working group

On Fri, Sep 24, 2010 at 09:28:48PM +0200, Yiu L. Lee wrote:
> Hi Juergen,
> 
> We would like to make it as openly as possible. This is why we 
> submitted the draft to IETF. We also like to see any other in the WG 
> is also interested in this work.
> 
> From the timeline perspective, we would like the WG would adopt this a

> WG item (if we get enough interested people) this year and WGLC Q1/Q2 
> next year. Do you think this timeline reasonable?

It all boils down to the resources put into this. From a cursory read of
the I-D, I think some work needs to be done to get the document into a
shape that fits the RFC3411 architecture etc. I have not looked at the
details of the Kerberos interface itself and of course it would help a
lot if some Kerberos expert gets involved into this. So we are again
back at the resources. ;-)

/js

---

From: "t.petch" <[email-masked]>
Date: Tue, 28 Sep 2010 16:24:28 +0200

----- Original Message -----
From: "Yiu L. Lee" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>;
"Pejaver,Rajaram" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 24, 2010 9:28 PM

> year. Do you think this timeline reasonable?

Looking back at the progress of other I-Ds, this might be a mite optimistic.

Also, having it adopted as a WG item gives the WG change control over it, so
what emerges as an RFC is what the WG (and others) agrees on, which might not be
what you are currently proposing.  Nothing new there, but something to be aware
of.  I am thinking that the WG might want this I-D recast in the style of other
such models, with elements of procedure and such like, an exercise which
has proven time consuming.

And looking in the archives, I find
  draft-pejaver-ismi-kerberos-00
which has just a subtle difference.

Tom Petch

---

From: "Yiu L. Lee" <[email-masked]>
Date: Tue, 28 Sep 2010 11:31:23 -0400

Hi Tom,

I agree I may be a little optimistic to the dates. I think the first step is
to get enough interest to make it a WG item before end of 2010. Then, we can
work together to make progress to the WGLC. I am also interested to hear
from you about the general approach of using Kerberos.

Thanks,
Yiu

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 28 Sep 2010 15:00:12 -0400

> http://www.lee-networks.com/draft-pejaver-isms-kerberos-00.txt

So, why does TSM + SSHTM + RFC4462 + GSS-krb5 not meet your needs?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 28 Sep 2010 22:35:06 +0200

On Tue, Sep 28, 2010 at 05:31:23PM +0200, Yiu L. Lee wrote:
 
> I agree I may be a little optimistic to the dates. I think the first
> step is to get enough interest to make it a WG item before end of
> 2010. Then, we can work together to make progress to the WGLC.

There are two incredients here: WG interest and author activity, and
sometimes both depend on each other. While WG interest is difficult to
control, author activity is in your hands. So what is supposed to
happen until end of 2010? Will we see a revised version of the
individual I-D before the cutoff where the authors try to express the
new security model in RFC3411 style, similar to other security models
we have?

/js

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 28 Sep 2010 16:47:30 -0400

Hi Juergen,

Yes, we are working on the revision and try to release it next week.  
Meanwhile, we love to hear more comments so that we can address them  
in the next revision.

Thanks,
Yiu

On Sep 28, 2010, at 4:35 PM, "Juergen Schoenwaelder" <[email-masked] 
 > wrote:

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 28 Sep 2010 20:00:50 -0700

>>>>> On Tue, 28 Sep 2010 15:00:12 -0400, Jeffrey Hutzelman <[email-masked]> said:

JH> So, why does TSM + SSHTM + RFC4462 + GSS-krb5 not meet your needs?

He mentioned a single round trip stateless UDP message at one point....
SSHTM won't fit that model.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "t.petch" <[email-masked]>
Date: Wed, 29 Sep 2010 09:44:51 +0200

Yiu

I think that
draft-hornstein-snmpv3-ksm
should disappear except in the Acknowledgements; an out-of-date, expired I-D is
not something I want to look at, so any reference to it must be a distraction.

Rather, your model should be RFC5591 which is the most recent Security Model and
yes, you must include processing of tmStateReference etc since that is now part
of 'An Architecture'.

Likewise, Transport is now part of 'An Architecture' and you are going back to
the UDP Transport Model, except we have never defined that beyond showing that
if you mix and match Models, it doesn't work, you can send a message from
Command Generator to Command Responder but will never get a response, a trap you
might also fall into:-( so perhaps you will need to define the UTM as well.

So, 1Q/2Q yes, but perhaps 2010.

Tom Petch

----- Original Message -----
From: "Lee, Yiu" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: "t.petch" <[email-masked]>; "Pejaver,Rajaram"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, September 28, 2010 10:47 PM
Subject: Re: [Isms] status and future of the isms working group

---

From: "Yiu L. Lee" <[email-masked]>
Date: Wed, 29 Sep 2010 09:13:17 -0400

Hi Tom,

Good comments. We will consider them and capture the necessary changes in
the next revision.

My mind set is still stuck in 2010 and I am not ready to let it go! Thanks
for finding the year wrong. I mean 2011 Q1/Q2. But it may be overly
optimistic. Raj and I will continue to work hard to make sure to address all
the questions and issues in the mailing list. Please don't stop giving us
feedback!

Thanks,
Yiu

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 29 Sep 2010 07:21:11 -0700

>>>>> On Wed, 29 Sep 2010 09:44:51 +0200, "t.petch" <[email-masked]> said:

tp> Rather, your model should be RFC5591 which is the most recent
tp> Security Model and yes, you must include processing of
tp> tmStateReference etc since that is now part of 'An Architecture'.

He's right you should mention it, but it could be as trivial as "we
don't care about it".  Though caring about it will let you properly send
KSM protected SNMPv3 over DTLS, for example, and if you don't at least
do minimal processing [see 5591] then KSM won't work over DTLS, TLS or SSH.

tp> Likewise, Transport is now part of 'An Architecture' and you are
tp> going back to the UDP Transport Model, except we have never defined
tp> that beyond showing that if you mix and match Models, it doesn't
tp> work, you can send a message from Command Generator to Command
tp> Responder but will never get a response, a trap you might also fall
tp> into:-( so perhaps you will need to define the UTM as well.

That's unfair.  The security architecture is modular and the original
intent of SNMP was to complete separate out the message format and
security from the transport over which it is sent.  Yes, the UDP
transport model isn't spelled out, but neither is SNMP over appletalk,
SNMP over unix domain socket, or any of the transports that SNMP
actually works over.  Note the "works over" part of that sentence.  They
are defined and work today, just not inline with 5590 wording.

Making a new security model which is transport agnostic, which is how
proper layering should work, should not require redefining all the
potential other layers over which the new SNMPv3 with the new security
model (KSM) "might" go over.

If there was a problem unless it was defined, sure.  But there isn't one.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 29 Sep 2010 16:29:05 +0200

> do minimal processing [see 5591] then KSM won't work over DTLS, TLS or SSH.

As far as I understand, KSM would do security processing in the
traditional way and not outsource the security processing to the
transport model. As such, I do not see any benefit of having KSM over
DTLS, TLS, or SSH. As matter of fact, USM over DTLS, TLS, or SSH does
not work either - except in the sense that all the DTLS, TLS, or SSH
stuff is simply ignored by the security model. And this is frankly
what I would expect to happen. So I guess the answer is really "KSM
does not care about any tmStateReference", like USM does.

> If there was a problem unless it was defined, sure.  But there isn't one.

I agree.

/js (speaking as technical contributor)

---

From: "Pejaver, Rajaram" <[email-masked]>
Date: Wed, 29 Sep 2010 10:39:44 -0400

> So, why does TSM + SSHTM + RFC4462 + GSS-krb5 not meet your needs?

Jeff,  We seek a lightweight transaction.  
TCP+TSM+... is a lot of overhead for a quick status check on a managed
device.

Regret the slow response; I'm in an Internetless, airless lab this week.

--raj

---

From: "t.petch" <[email-masked]>
Date: Wed, 29 Sep 2010 18:47:07 +0200

Wes, I am getting bounces from your e-mail address, so we will have to use the
list:-) - see below
----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Lee, Yiu" <[email-masked]>; "Juergen Schoenwaelder"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, September 29, 2010 4:21 PM

> model (KSM) "might" go over.

Yeah, and you know well that we don't have proper layering - tmStateReference
being a good example - which is why we sometimes do have to specify the
interactions since, as you and I demonstrated, to the surprise of some, USM will
not work over the existing secure Transport Models.

I am saying that at the least, a KSM I-D has to parallel RFC5591 (not USM),
covering all the topics that that covers.  It will probably specify that all
the additional parameters introduced by RFC5590 are ignored, but if it says
anything else, then I think we will need a UDP Transport Model.

And then there are the interactions with Kerberos; shades of VACM and RADIUS
perhaps, in that the Command Responder is setting up a
connection(/session/transport) to a third party, which needs specifying?

It's quite a lot of work.

Tom Petch

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 29 Sep 2010 11:45:17 -0700

Hi -

> Cc: "isms" <[email-masked]>; "Lee, Yiu" <[email-masked]>
> Sent: Wednesday, September 29, 2010 9:47 AM
...
> It's quite a lot of work.

Perhaps, but let's not make it more work than is really necessary.
Imposing constraints that don't actually affect the bits on the wire
or make the specification clearer is not helpful, in my opinion.
In particular, I think alignment with a particular architectural model
should *not* be an absolute requirement.   Elements of the architecture
should be mentioned IFF they make it easier to understand how
something is supposed to work.

In my opinion, the important thing is to nail down any bits on the
wire, along with the operational and management characteristics.
If the resulting spec has a gestalt that makes for a clear description
in the terms of an existing architecture, great.  If it doesn't, I see no
benefit to subjecting it to procrustean edits to align it.

The fact of life is that the modularity of the architecture does NOT
correspond to implementation modularity.  Perhaps a concrete
example would be helpful.  Consider what a master agent needs
to do to process a get-next or get-bulk request in the presence of
access control.  The architecture would suggest an iterative solution,
applying isAccesAllowed() to each potential intermediate result
returned from a subagent.  From the point of describing the externally-
observable SNMP behaviour, this is fine.  But from the subagent protocol
perspective, or from an implementation perspective, this is crazy.  With
fine-grained access control  and/or tables distributed across multiple
subagents, this can be spectacularly inefficient.  Subagent query optimization
is possible, but requires operating directly on both the VACM and subagent
registration tables.  This is clearly not supported by the ASIs. but also not
something the standard should even talk about, since it is highly vendor-specific.
We shouldn't try to use the 3411 architecture for anything more than what it
was designed to do: to modularize the description of how USM, VACM,
and a more-or-less generic SNMP protocol engine work together to support
SNMP applications.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 29 Sep 2010 11:47:13 -0700

>>>>> On Wed, 29 Sep 2010 18:47:07 +0200, "t.petch" <[email-masked]> said:

tp> I am saying that at the least, a KSM I-D has to parallel RFC5591
tp> (not USM), covering all the topics that that covers.  It will
tp> probably specify that all the additional parameters introduced by
tp> RFC5590 are ignored, but if it says anything else, then I think we
tp> will need a UDP Transport Model.

Sounds like a one bullet incoming request saying "ignore the
tmStateReference" solves all your problems then.  (and the outgoing
doesn't need anything since by not creating a tmStateReference on the
outgoing path, you're already ignoring it).

tp> And then there are the interactions with Kerberos; shades of VACM
tp> and RADIUS perhaps, in that the Command Responder is setting up a
tp> connection(/session/transport) to a third party, which needs
tp> specifying?

I think I'll stop suggesting solutions as we haven't agreed to do the
work.  That being said, all of the above have already been accomplished
by two independent sets of folks so I know they can be worked out.
-- 
Wes Hardaker
Cobham Analytic Solutions