Subject: RE: [ipcdn] pktcMtaDevProvConfigKey

From: "Sumanth Channabasappa" <[email-masked]>
Date: Mon, 24 Jan 2005 17:57:46 -0700

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 

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 24 Jan 2005 17:35:35 -0800

Hi -

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

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

>Flows' (Since they are the technical terms used in PacketCable). Would

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