RE: pktcMtaDevProvConfigKey

Randy,

I'll start with a few clarifications. See additional comments inline as
well.

You wrote:
> CBC mode requires an IV.  Section 6.3 of the reference you 
> gave seems to be about setting SNMP keys, where a 64-bit IV 
> needs to be supplied. Other sections of the document seem to 
> use other ways of deriving IVs, so something is still missing here.

DES CBC mode for SNMPv3 requires an IV indeed. The object description is
misleading and the explanation I provided (section 6.3 of the security
spec) was not the right one. I gave the reference to setting the SNMPv3
keys, where a 64-bit IV needs to be supplied. I pasted it quickly but
this section does not seem to apply.

Clarification: 
This config file key is not the same as the key used in SNMPv3 Privacy.
The key contained by the MIB Object pktcMtaDevProvConfigKey is the key
used to 'encrypt' the configuration file, not the key to secure the
SNMPv3 communications. 
The PacketCable/IPcablecom requirements for the config file key are:
- Use the same 'encryption algorithm' as the one chosen for SNMPv3
privacy (Privacy must be enabled),
- 'DES in CBC mode' is the only privacy algorithm chosen today (Section
6.3)
- For DES in CBC mode, during encryption, use "IV=0" for all cases
(Section 7.1.1.2.2 of
http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I11-040730.pdf ,
first paragraph of page 120).

Based on your comment and input from Sumanth, our recommendation would
be to change the description to:
pktcMtaDevProvConfigKey  OBJECT-TYPE
    SYNTAX      OCTET STRING (SIZE(0|8))
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
         "This object contains the key used to encrypt/decrypt
          the configuration file when the secure provisioning
          mode is selected to provision the MTA.

          The value of this object is provided along with the 
          configuration file information (pktcMtaDevConfigFile)
          and hash (pktcMtaDevProvConfigHash) by the Provisioning
          Server via SNMP SET once the configuration file has been
          created as defined by the PacketCable Security 
          specification.

          If the configuration file the MTA receives is not 
          encrypted, the length of this object value is zero. 
          If the file is encrypted, then the algorithm is DES in
          CBC mode and the length of this object value is 64 bits
          (an IV of zero is used to encrypt the file as specified
          in the PacketCable Security specification).

          If this object is set at any other provisioning steps than 
          the one(s) allowed by the PacketCable MTA Device
          Provisioning Specification, or, if this object is
          explicitely set to a zero-length string value, the MTA 
          MUST return an 'inconsistentValue' error.
          This object must not be used in non secure provisioning
          mode.  In non secure provisioning modes, the MTA MUST
          return an 'inconsistentValue' in response to SNMP SET 
          operations, and, the MTA MUST return a zero-length string
          in response to SNMP GET operations."
    REFERENCE
        " PacketCable MTA Device Provisioning Specification;
          PacketCable Security Specification."
    ::= { pktcMtaDevServer 10 } 


> ...
> > > Ok, though I meant that the MTA would ALWAYS return a zero-length 
> > > string in response to GET requests, not just in "non secure 
> > > provisioning modes."
> >
> > Ok. In secure mode, one could get the actual key in a GET
> > and that could help troubleshoot some issues when the MTA
> > has pbs to decrypt the configuration file. No changes required - if 
> > that's ok with you.
> 
> This begs the question of what is meant by "secure mode".

Note that we say secure provisioning mode. It is defined in the
provisioning spec, 
http://www.packetcable.com/downloads/specs/PKT-SP-PROV-I10-040730.pdf ,
section 7.
This is a normative reference to the MIB module and implementors
building such devices should know. I paste here the relevant intro:
An MTA device is provisioned via one of three provisioning flows:
 - The Secure Flow supports Kerberos mutual authentication between the
MTA and the provisioning system, as well as Kerberized SNMPv3 messaging.
The Secure Flow MUST be supported by PacketCable MTAs and the
Provisioning Applications.
 - The Basic Flows are a simplified DOCSIS-like provisioning flows with
no Kerberos or SNMPv3 security and no SNMP enrollment via SNMP INFORM.
The Basic Flows SHOULD be supported by PacketCable MTAs and Provisioning
Applications.
 - The Hybrid Flows are essentially the Secure flow with the Kerberos
message exchanges removed, and SNMPv2c substituted for SNMPv3. The
Hybrid Flows SHOULD be supported by PacketCable MTAs and Provisioning
Applications .

The bottom line is compliant implementations MUST support the secure
provisioning mode. We introduced the basic and hybrid modes to meet some
operator requirements, when security at the DOCSIS MAC layer (BPI+) is
provided and the back office tools our operators have are not yet
upgrade to deal with the secure flow provisioning.

> If it means "the SNMP request being processed arrived with
> an authPriv security level", then this solution won't work 
> with, for example, AgentX infrastructure.  In that 
> environment, the subagent has no idea what the security level 
> of the request was.  All the security-related aspects of SNMP 
> are handled in the master agent, and the AgentX protocol 
> provides no way to communicate this information.
> 
> If you *really* want keys to be readable (note that we went 
> out of our way to prevent them from being read in the USM 
> SNMPv3 security model), then the normal way of protecting 
> them would be through the VACM configuration, permitting them 
> to be read or written only by authorized users using authPriv 
> requests.
> 
> If "secure mode" means something else, then you're going to 
> have a really complicated security considerations section, I fear.
a PacketCable MTA can be provisioned in 3 modes:
- Secure, which enables SNMPv3 between the MTA and its Manager
- Basic or Hybrid, where the access is 'SNMPv2'

Sumanth & Jean-Francois.