Re: pktcMtaDevProvConfigKey

Hi -

> From: "Sumanth Channabasappa" <[email protected]>
> To: <[email protected]>
> Sent: Monday, January 24, 2005 4:57 PM
> Subject: RE: [ipcdn] pktcMtaDevProvConfigKey
...
>> 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)

The point is that
    (1) subagent protocols provide no way for a subagent to know
          which encryption algorithm was used for a given request
    (2) SNMP engines may support multiple encryption algorithms
    (3) if PacketCable ever permits the use of the more secure AES,
         specifying things in terms of "the same 'encryption algorithm; as the
         one [sic] chosen for SNMPv3 privacy" is just plain broken.

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

As long as it's DES-CBC or nothing, you're probably ok.  If the architecture
is expected to ever be able to support anything else, you might give it
some thought.

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

It would help immensely.  When I read Jean-Francois' clarification, the part
that said " - 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" led me to believe that the text required different
behaviour depending on whether information was being accessed AuthPriv
or not.  Sorry about the confusion.  As long the "provisioning mode" has nothing
to do with the SNMP version or security level is use, I'll be less worried about it.

Randy