Subject: [OPS-AREA] Issue 1: should we have a security boilerplate for management protocols and data models?

From: "David Harrington" <[email-masked]>
Date: Wed, 4 Feb 2009 10:46:54 -0500

Hi,

I plan to propose some replacement text for the current boilerplate
for secure management protocols, and for the sensitivity of data model
objects.

I think the debate aboiut whether we should have boilerplate is a
different issue than what the replacement text should be, so this
thread is for tha debate about whether a boilerplate is desirable.

Please keep the threads separate.

now, my opinion on whether to have boilerplate:

I have seen editors try to write their own recommendations for
securing management using SNMPv3 or other secure protocol, and they
typically get the text way wrong. I think it is important for us to
provide accurate text for them to use. 

I personally find the existing MIB object sensitivity boilerplate
longer than I like, and I think we should consider whether it can be
shortened, but I think it is important that the security
considerations for a data model document include a discussion of the
sensitivity, and potential problems, associated with the data model
objects.

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 4 Feb 2009 10:22:31 -0800

Hi -

> From: "David Harrington" <[email-masked]>
> To: "'ops-area (IETF)'" <[email-masked]>
> Sent: Wednesday, February 04, 2009 7:46 AM
> Subject: [OPS-AREA] Issue 1: should we have a security boilerplate formanagement protocols and data models?
...
> thread is for tha debate about whether a boilerplate is desirable.
...

While this is an admirable goal, I think it is premature.  Does *anyone*
have an idea of what *standardized* access control for netconf is going
to look like?  Though I know folks would like to make it simpler than
VACM, until folks work through how access control interacts with
augmentations and vendor extensions in that environment, I'd be
very wary of trying to set out meta-policies (which is what the filled-in
boilerplate will be) for that environment.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Wed, 4 Feb 2009 14:54:53 -0500

Hi, 

> boilerplate will be) for that environment.

I am not sure which goal you find admirable, but I assume you mean
suggesting that protocols should support access control, and the info
model access should differentiate between modify sensitivity and
expose sensitivity.

I tried to write the text to say that the protocol should support
control of access to the information. I tried to avoid saying anything
about using a particular conceptualization/model of access control.
"support" could be for a proprietary access control model, or a
standardized one - but some type of access control should be
supported. I think that whether the access control is standardized or
proprietary, it will be reasonable to expect that the access control
will differentiate between operations that expose and those that
modify (if there is a modify capability).

dbh

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 4 Feb 2009 17:24:32 -0800

Hi -

> To: "'Randy Presuhn'" <[email-masked]>; "'ops-area (IETF)'" <[email-masked]>
> Sent: Wednesday, February 04, 2009 11:54 AM
> Subject: RE: [OPS-AREA] Issue 1: should we have a security boilerplateformanagement protocols and data models?
...
> model access should differentiate between modify sensitivity and

However, it's not even clear whether netconf access control will
even be formulated in those terms (it might be "per RPC") nor
do we even know whether the granularity of "information element"
would be congruent with what netconf might do.  (I would hope so,
but then it might start to look surprisingly like VACM.)

> supported.

We're in agreement.  The difficulty is that access control models
aren't *necessarily* formulated in terms of information elements,
even though doing so is in my opinion a very sensible thing.

> I think that whether the access control is standardized or

Maybe.  If it looks like some CLI access control models, it will
be organized around a set of "verbs" rather than information objects.
I certainly don't recommend such an approach, but until netconf
nails this down, I'd be wary of trying to predict how it will end up.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Thu, 5 Feb 2009 13:03:39 -0500

Hi,

I think you may be reading more into "information element" than I am.
In a management information system that uses verbs or RPCs, I consider
those as information elements as well. Some verbs modify, some expose.
Some RPCs modify, some expose. In a system that uses hierarchies of
things, like MIBs and XML and UNIX filesystems, both leafs and
subtrees can be information elements that can expose or possibly be
modifed.

I do not think the whole IETF strategy for managing networks should be
totally dependent on what Netconf and netmod decide to do about access
control, anyway. There are quite a few different protocols in the IETF
that address network management.

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Wednesday, February 04, 2009 8:25 PM
> To: 'ops-area (IETF)'
> Subject: Re: [OPS-AREA] Issue 1: should we have a 
> securityboilerplateformanagement protocols and data models?
> 
> Hi -
> 
> > Subject: RE: [OPS-AREA] Issue 1: should we have a security 
> boilerplateformanagement protocols and data models?
> ...
> _______________________________________________
> OPS-AREA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-area
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 5 Feb 2009 12:48:52 -0800

Hi -

> Sent: Thursday, February 05, 2009 10:03 AM
> Subject: RE: [OPS-AREA] Issue 1: should we have a securityboilerplateformanagement protocols and data models?
...
> subtrees can be information elements that can expose or possibly be

Consequently, until we know the granularity and orientation of the netconf
access control model, the boilerplate is premature.  To be most useful,
it should make it abundantly clear to the document writer what bits
have to be filled in, and at what granularity.

> that address network management.

Agreed, and there seem to be more every week.  Though
it would be nice for there to be a coherent architecture, I'm
afraid the horses have already left the barn.  If a boilerplate
document like this is going to be truly useful, it needs appropriate
hooks corresponding to the knobs provided by the various
protocols' access control facilities.

Randy