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

Jeffrey Hutzelman <jhutz@cmu.edu> Wed, 11 February 2009 22:26 UTC

Return-Path: <jhutz@cmu.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADCCF28C389; Wed, 11 Feb 2009 14:26:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.072
X-Spam-Level:
X-Spam-Status: No, score=-5.072 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8G27JSHk8fm; Wed, 11 Feb 2009 14:26:30 -0800 (PST)
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id A7B9C28C387; Wed, 11 Feb 2009 14:26:30 -0800 (PST)
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n1BMQLJD016282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2009 17:26:21 -0500 (EST)
Date: Wed, 11 Feb 2009 17:26:20 -0500
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Adrian Farrel <adrian@olddog.co.uk>, iesg@ietf.org, secdir@ietf.org, ccamp-chairs@tools.ietf.org, diego.caviglia@ericsson.com, dino.bramanti@ericsson.com, dan.li@huawei.com, dave.mcdysan@verizon.com
Message-ID: <8711BD60B6F8AC0239858382@minbar.fac.cs.cmu.edu>
In-Reply-To: <23E53B36510442F1B64C24DFE059AF91@your029b8cecfe>
References: <29CB4AF52E418956F8DAC191@minbar.fac.cs.cmu.edu> <23E53B36510442F1B64C24DFE059AF91@your029b8cecfe>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Subject: Re: [secdir] SECDIR review of draft-ietf-ccamp-pc-and-sc-reqs-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Feb 2009 22:26:31 -0000

--On Wednesday, February 11, 2009 09:44:15 PM +0000 Adrian Farrel 
<adrian@olddog.co.uk> wrote:

> I am not happy that the Security section should recomend the use of a
> 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.
>
> 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.

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.


> 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

I think this is a good change.


> 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.

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.


> 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.

I like that.

-- Jeff