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

["Adrian Farrel" <[e-mail]>]

Hi Jeffrey,

Thanks for this input.

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

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

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