Subject: [ipcdn] pktcMtaDevProvConfigKey

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 21 Jan 2005 14:55:45 -0700

Hi Randy,

You wrote:
> > pktcMtaDevProvConfigKey  OBJECT-TYPE
> ...
> >           and, the MTA MUST return a 'genErr' error in response to
> >           SNMP GET operations."
> ...
> 
> This strikes me as very strange.  The intent in RFC 3416 section 4.2.1
> was for genErr to be the "error of last resort".   When one considers
> how this would interact with, for example, AgentX
> infrastructure, the consequences for Get-Next and Get-Bulk 
> processing could well be very bad.  

  Eugene and I discussed this live today. We had not thought about that
before, you have a point. 
  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.

> 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? 
 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.
          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.
          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."
    REFERENCE
        " PacketCable MTA Device Provisioning Specification;
          PacketCable Security Specification."
    ::= { pktcMtaDevServer 10 } 

Let us know if the above is acceptable. Thanks for raising this issue.

> (I also see no value to requiring that the three objects be
> set in the same PDU.  It would increase agent complexity, and 
> I see no benefits to doing so.)

  Removed from all objects where it had been inserted.
  Eugene will start a thread on this before the change gets in the
draft.

> Randy

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 21 Jan 2005 15:22:51 -0800

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
...
> get-next/get-bulk for e.g.? If that is the case, I agree we don't want

Yes, it would break MIB walks implemented using AgentX.
See RFC 2741 section 7.2.5.3. for details explaining why.

> I assume a "zero length string" means an octet string of size 0?

Yes.

>           The privacy algorithm is DES, the key length is 64 bits.

Which DES mode? CBC? CFB? ECB? ...?  Is there an IV for the DES?

>           an 'inconsistentValue' error.

One can also formalize this using the WRITE-SYNTAX in the OBJECT
clause of the conformance material.

...

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

Randy