Subject: [secdir] SECDIR review of draft-ietf-ccamp-pc-and-sc-reqs-06

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 11 Feb 2009 13:12:30 -0500

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document describes requirements for a procedure to be used within a 
GMPLS network to convert a permanent connection, which is provisioned 
throughout the network, into a soft permanent connection, which is 
provisioned at the edges but set up by the control plane in the middle, and 
back, without interrupting the flow of data.

As a requirements document, this document does not directly create any new 
security considerations, but does raise some points which must be addressed 
by any solution.  Overall, I think this document is fine.

I also asked David Harrington <[email-masked]> to take a look at a 
paragraph referring to SNMP, which seemed to me to make too many 
assumptions about which pieces would "always" be used together.  David had 
the following to add:

> OK. It is incorrect to reference to MIBs as SNMP MIBs. MIBs are
> defined indepednently from SNMP. MIBs can theoretically be used by
> other protocols.
>
> There is standard boilerplate for MIB documents. Since this document
> does not contain a MIB module, most of it does not directly apply.
> However, the boilerplate discusses using a secure protocol and access
> control. I recommend that these authors use that section of the
> boilerplate text:
>
> <full boilerplate>
>    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.
> <boilerplate>
>
> This could be as simple as
>
>    If SNMP is used for configuration, then 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).
>
> As the IETF is moving toward a multi-protocol approach to network
> management, I would change the paragraph to encompass a wider
> approach:
>
> "Any protocol used to configure a device should support
> authentication, encryption, integrity checking, and control of access
> to the configuration parameters. It is RECOMMENDED to deploy an IETF
> standard protocol for secure configuration, such as Netconf [RFC4741]
> or SNMPv3 [RFC3410].  Operators SHOULD enable cryptographic security
> and ensure that the entity giving access to configuration parameters
> is properly configured to give access only to those principals (users)
> that have legitimate rights to read/create/change/delete the
> parameters."
>
> I have asked the OPS and Security ADs to comment on this last
> paragraph as a proposed new boilerplate regarding secure management.

My only other comment is regarding the abstract.  A document and its 
abstract should each stand on their own, independently.  In particular, it 
should not be necessary to read the abstract in order to understand the 
document, and the abstract should contain only a brief description of what 
the document is about, intended to be read by someone trying to determine 
whether the document is of interest.  In the case of this document, text 
invoking RFC2119 does not belong in the abstract; rather, it belongs in the 
main document body.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Carnegie Mellon University - Pittsburgh, PA

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 11 Feb 2009 21:44:15 -0000

Hi Jeffrey,

Thanks for this input.

>> I would change the paragraph to encompass a wider approach:
>>

I am not happy that the Security section should recomend the use of a 
particular management protocol, and certainly not in 2119 language. This I-D 
is not an IETF policy statement for the security of management protocols.

I am also not particularly happy with your "SHOULD" guidance to the 
operator. This I-D is a requirements spec for the development of protocol 
solutions. It is not a protocol spec, and certainly not a deployment guide.

But it is good to pick up some words here. I propose...

OLD
   If SNMP MIBs are used for configuration, then the Management Plane
   should support authentication for PC-SC configuration changes as
   specified in [RFC3414].
NEW
   The Management Plane interactions MUST be supported through protocols
   that can offer adequate security mechanisms to secure the
   configuration and protect the operation of the devices that are
   managed. These mechanisms MUST include at least cryptographic
   security and the abilty to ensure that the entity giving access to
   configuration parameters is properly configured to give access only
   to those principals (users) that have legitimate rights to
   read/create/change/delete the parameters. IETF standard management
   protocols (Netconf [RFC4741] and SNMPv3 [RFC3410]) offer these
   mechanisms.
END

> invoking RFC2119 does not belong in the abstract; rather, it belongs in 
> the main document body.

Sure.
There is an indentation issue in the current version that makes this look 
worse than it is.
The 2119 boilerplate often seems to be placed immediately after the Abstract 
in I-Ds.
But anyway, the RFC Editor has a special place for this text and will sort 
it out.

However, you have just made me note that this is an Informational 
requirements draft, and so the 2119 language is not completely appropriate. 
A hoary old chestnut, this. We want to use some strong requirements 
language, but 2119 is intended only for protocol specs.

I guess we will morph this to...

   Although this requirements document is an informational document not
   a protocol specification, the key words "MUST", "MUST NOT",
   "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
   "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be
   interpreted as described in RFC 2119 [RFC2119] for clarity of
   requirement specification.

Many thanks,
Adrian

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 11 Feb 2009 17:26:20 -0500

--On Wednesday, February 11, 2009 09:44:15 PM +0000 Adrian Farrel 
<[email-masked]> wrote:

> particular management protocol

In fact, one of David's points was that SNMP is not the only management 
protocol.  And, the point that caused me to raise this to begin with is 
that the protocol defined in RFC3414 is not the only SNMP security model

> and certainly not in 2119 language. This
> I-D is not an IETF policy statement for the security of management
> protocols.
>

That's not my text; some of it is David's, and some comes from existing 
boilerplate used in MIB documents.  It is certainly the case that in some 
ways that text is not directly applicable to a requirements document.  But 
the gist is right, I think.

>    protocols (Netconf [RFC4741] and SNMPv3 [RFC3410]) offer these

I think this is a good change.

> requirements draft, and so the 2119 language is not completely
> appropriate. A hoary old chestnut, this. We want to use some strong
> requirements language, but 2119 is intended only for protocol specs.

My personal take here is that, despite its own introduction, it really is 
appropriate to use 2119-like language in some contexts other than protocol 
specs, and that this is one of them.

>    requirement specification.

I like that.

-- Jeff