Re: pktcMtaDevProvConfigKey

Hi -

> From: "Jean-Francois Mule" <[email protected]>
> To: "Randy Presuhn" <[email protected]>; <[email protected]>
> Cc: "Sumanth Channabasappa" <[email protected]>
> Sent: Monday, January 24, 2005 3:17 PM
> Subject: RE: [ipcdn] pktcMtaDevProvConfigKey
...
> I'll start with a few clarifications. See additional comments inline as
> well.

Thanks.  I have some responses inline below.

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

So far so good.

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

Multiple encryption algorithms may be in use concurrently in an SNMP engine.
For example, DES (RFC 3414) and AES (RFC 3826) can both be used in
USM.

> - 'DES in CBC mode' is the only privacy algorithm chosen today (Section
> 6.3)

Is the algorithm visible to or controllable via the management interface?

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

Fine with me, as long as it's spelled out.

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

Nice and clear.  Thanks.

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

If that's what you really want.

>           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

This is not implementable in AgentX environments, since the subagent
has no way of knowing what the security level of a given SNMP request is.
This kind of constraint should be left to VACM confirguration, not the object's
behaviour.

>           operations, and, the MTA MUST return a zero-length string
>           in response to SNMP GET operations."
...

The ", and," makes the specification ambiguous.
Does it ALWAYS return a zero-length string, or
only when in "non-secure provisioning modes"?  If it's the latter,
it won't be implementable using subagent technology like AgentX,
since that protocol does not give the subagent any knowledge of
the security level in effect for a given operation request.  If you really
do want these to be readable, then VACM configuration is the correct
way to prevent unencrypted access to this information.

Randy