Re: pktcMtaDevProvConfigKey

Hi -

> From: "Jean-Francois Mule" <[email protected]>
> To: <[email protected]>
> Sent: Friday, January 21, 2005 4:11 PM
> Subject: RE: [ipcdn] pktcMtaDevProvConfigKey
...
> > >           The privacy algorithm is DES, the key length is 64 bits.
> >
> > Which DES mode? CBC? CFB? ECB? ...?  Is there an IV for the DES?
> This was there before, nobody commented.... Arg...
> DES CBC mode as defined the reference of the object, PacketCable security
> spec, http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I11-040730.pdf ,
> section 6.3. I will add CBC mode in the text but I'm reluctant to mention the section
> number or add more. Text now says:
>           The privacy algorithm is defined by the PacketCable
>           Security Specification, it is DES in CBC mode and the key
>           length is 64 bits.

CBC mode requires an IV.  Section 6.3 of the reference you gave seems
to be about setting SNMP keys, where a 64-bit IV needs to be supplied.
Other sections of the document seem to use other ways of deriving IVs,
so something is still missing here.

...
> > One can also formalize this using the WRITE-SYNTAX in the
> > OBJECT clause of the conformance material.
> Ok, this is a refinement, nice to have but believe the above is enough
>  for now (we are trying to close this revision tonight).

Ok with me.  Since there had been a previous question about nailing
down implementation requirements in the conformance material, I
thought it helpful to point out the *opportunity* (not requirement)
to do so here.

...
> > Ok, though I meant that the MTA would ALWAYS return a
> > zero-length string in response to GET requests, not just in
> > "non secure provisioning modes."
>
> Ok. In secure mode, one could get the actual key in a GET
> and that could help troubleshoot some issues when the MTA
> has pbs to decrypt the configuration file. No changes required -
> if that's ok with you.

This begs the question of what is meant by "secure mode".
If it means "the SNMP request being processed arrived with
an authPriv security level", then this solution won't work with,
for example, AgentX infrastructure.  In that environment, the
subagent has no idea what the security level of the request
was.  All the security-related aspects of SNMP are handled
in the master agent, and the AgentX protocol provides no way
to communicate this information.

If you *really* want keys to be readable (note that we went out
of our way to prevent them from being read in the USM SNMPv3
security model), then the normal way of protecting them would
be through the VACM configuration, permitting them to be read
or written only by authorized users using authPriv requests.

If "secure mode" means something else, then you're going to
have a really complicated security considerations section, I fear.

Randy