RE: pktcMtaDevProvConfigKey

Randy,

Thanks, a few comments inline:

  
> 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.
[s] True, but the PacketCable Security Specification limits this to
DES/CBC (Section 6.3.1 of
http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I11-040730.pdf)


> - '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?
[s] It is controllable via the communication defined between the MTA and
the Provisioning Server (using Kerberos) as defined in the Security
Specification. However, the chosen privacy algorithm (DES or NULL) can
neither be controlled nor is it reflected in the 'MTA MIB'. 

  

 
>           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.
[s] Just to make it clear, 'Secure Provisioning' mode or 'non secure
provisioning' modes refer to the provisioning mode an MTA was
provisioned in and not necessarily the level of SNMP security. Perhaps
we should change 'non secure provisioning modes' to 'Basic and Hybrid
Flows' (Since they are the technical terms used in PacketCable). Would
that help?


regards
Sumanth