RE: pktcMtaDevProvConfigKey

Hi Randy,
Inline.
Jean-François 
> -----Original Message-----
> From: Randy Presuhn [mailto:[email protected]] 
> Sent: Monday, January 24, 2005 6:36 PM
> To: [email protected]
> Subject: Re: [ipcdn] 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.

Your comment here is on the PacketCable and Ipcablecom 1.0 security specifications to which the MTA MIB module is just providing managed objects. I would not argue that some improvements could be made in the spec itself - but that's what we have today and we can't fix this by MIB changes. This is not specific to IPCDN: we define often mibs after protocols and when we find issues, we log them for the next revision. I think we can record your comment and pass it on to the proper folks for consideration when they update the security spec.
Ok?

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


> 
> >>           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.
I would actually rather not since we now use "provisioning modes" through the mib module. I would prefer introducing a paragraph or 2 upfront specifying what the provisioning modes are and what they refer to in terms of provisioning flows.
Is that ok?

>  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.  
We can point this out in the new section proposed above.

> 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.
Thanks for your comments.

> 
> Randy
> 
> 
> 
> _______________________________________________
> IPCDN mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 
>