Subject: RE: [ipcdn] pktcMtaDevProvConfigKey

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 21 Jan 2005 17:11:08 -0700

What's fun is that you always find more good stuff to address. 
see Inline.
Jean-François 

> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]] 
> Sent: Friday, January 21, 2005 4:23 PM
> To: [email-masked]
> Subject: Re: [ipcdn] pktcMtaDevProvConfigKey
> 
> 
> Hi -
> 
> > From: "Jean-Francois Mule" <[email-masked]>
> > To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> > Sent: Friday, January 21, 2005 1:55 PM
> > Subject: [ipcdn] pktcMtaDevProvConfigKey
> ...
> >   Do I interpret your comment above correctly by assuming that, on 
> > some SNMP agents, the return of a genErr would break a MIB 
> walktrhough 
> > via get-next/get-bulk for e.g.? If that is the case, I 
> agree we don't 
> > want this.
> 
> Yes, it would break MIB walks implemented using AgentX.
> See RFC 2741 section 7.2.5.3. for details explaining why.
> 
> > > My suggestion, since this
> > > object contains sensitive information anyway, is for it to always 
> > > return a zero-length string, rather than playing strange 
> games with 
> > > error codes.
> >
> > Ok.
> > I assume a "zero length string" means an octet string of size 0?
> 
> Yes.
> 
> >  How about this new text?
> >
> > pktcMtaDevProvConfigKey  OBJECT-TYPE
> >     SYNTAX      OCTET STRING (SIZE(0|8))
> >     MAX-ACCESS  read-write
> >     STATUS      current
> >     DESCRIPTION
> >         " This object contains the key used to encrypt/decrypt
> >           the configuration file when secure SNMPv3 provisioning
> >           is used.
> >           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.

> >           If this object is set at any other provisioning steps than
> >           the one(s) allowed by the PacketCable MTA Device
> >           Provisioning Specification, or, if this object is
> >           set to a zero-length string value, the MTA MUST return
> >           an 'inconsistentValue' error.
> 
> 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). No changes required - if that's ok with you.

> 
> >           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
> >           operations, and, the MTA MUST return a zero-length string
> >           in response to SNMP GET operations."
> ...
> 
> 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.

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

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 21 Jan 2005 18:06:05 -0800

Hi -

> To: <[email-masked]>
> Sent: Friday, January 21, 2005 4:11 PM
> Subject: RE: [ipcdn] pktcMtaDevProvConfigKey
...
> 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:

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.

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