Subject: [OPS-AREA] Issue 2: replacement text for secure management protocol boilerplate

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

Hi,

The IETF has been in the process of changing from a managenent
strategy that basically said "write a MIB" (and presumably use SNMP to
access it) to a strategy that says "consider the nature of the
management functionality required, and select an appropriate protocol
to address the requirements. I think the existing boilerplate should
be modified to reflect this change.

OLD:
SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPsec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the
objects
   in this MIB module.

   It is RECOMMENDED that implementers consider the security features
as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access
to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

NEW:
Any protocol used to manage a device should support authentication,
encryption, integrity checking, and control of access to the
management information. It is RECOMMENDED that operators deploy an
IETF standard protocol for secure management, such as Netconf over SSH
[RFC4742] or SNMPv3 [RFC3410] or syslog over TLS [RFC5425].  Operators
SHOULD enable cryptographic security and ensure that the server/agent
giving access to management information is properly configured to give
access only to those principals (users) that have legitimate rights to
read/create/change/delete the information. 

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

---

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

Hi -

> From: "David Harrington" <[email-masked]>
> To: "'ops-area (IETF)'" <[email-masked]>
> Sent: Wednesday, February 04, 2009 7:47 AM
> Subject: [OPS-AREA] Issue 2: replacement text for secure management protocolboilerplate
...
> read/create/change/delete the information. 
...

I think the last sentence isn't quite right for syslog and SNMP notification
originators.  It's true that that's how we handle the "giving access" part in
VACM, but at the level of the cryptographic security happening during
the actual transfer of the information (rather than the configuration of how
the information is to be transferred) it's a different matter.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Wed, 4 Feb 2009 13:24:49 -0500

Hi,

Would the following be better?
 
"Operators SHOULD enable cryptographic security and ensure that the 
protocol giving access to management information is properly 
configured to give access only to those principals
(users/applications) that have legitimate rights to
read/create/change/delete the information." 

i.e., 
s:server/agent:protocol:
s:(users):(users/applications)/

or does that get so diluted as to be meaningless?

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Wednesday, February 04, 2009 1:12 PM
> To: 'ops-area (IETF)'
> Subject: Re: [OPS-AREA] Issue 2: replacement text for secure 
> managementprotocolboilerplate
> 
> Hi -
> 
> _______________________________________________
> OPS-AREA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-area
>

---

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

Hi -

> To: "'Randy Presuhn'" <[email-masked]>; "'ops-area (IETF)'" <[email-masked]>
> Sent: Wednesday, February 04, 2009 10:24 AM
> Subject: RE: [OPS-AREA] Issue 2: replacement text for secure managementprotocolboilerplate
...
> or does that get so diluted as to be meaningless?

I think it's better.  To more explicitly address the syslog/notification
cases, perhaps one could add "/receive" after "delete"?

Randy

---

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

Hi,

I think the original formulation could lead one to assume the access
control was "standardized" as part of the standard protocol. I think
it might be clearer to separate this into two separate
recommendations:

"Any protocol used to manage a device should support authentication,
encryption, integrity checking, and control of access to the
management information. It is RECOMMENDED that operators deploy an
IETF standard protocol for secure management, such as Netconf over SSH
[RFC4742] or SNMPv3 [RFC3410] or syslog over TLS [RFC5425].  

Operators SHOULD enable cryptographic security and ensure that the 
protocol giving access to management information is properly
configured 
to give access only to those principals (users/applications) that have

legitimate rights to create/change/delete/read/receive the
information."

dbh 

> Sent: Wednesday, February 04, 2009 1:28 PM
> To: 'ops-area (IETF)'
> Subject: Re: [OPS-AREA] Issue 2: replacement text for 
> securemanagementprotocolboilerplate
> 
> Hi -
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 5 Feb 2009 10:02:44 +0100

> Sent: Wednesday, February 04, 2009 8:28 PM
> To: 'ops-area (IETF)'
> I think it's better.  To more explicitly address the 
> syslog/notification cases, perhaps one could add "/receive" 
> after "delete"?
> 
> Randy
> 

+1 

Dan

(speaking as contributor)