Subject: [netmod] review of netmod-snmp-cfg

From: Wes Hardaker <[email-masked]>
Date: Fri, 02 Nov 2012 20:39:04 -0700

I reviewed, as promised at the last IETF, the netmod-snmp-cfg-00
document; in particular with respect to the TLS parts of it but I also
reviewed the USM configuration too.  Here's the notes I wrote up about
it (in no particular order):

1) Should, at least, the key objects be marked as nacm:default-deny-all?
   It's extremely sensitive data.  I'm not a yang expert and didn't look
   up the rules, so I'm not sure if it needs to go into the 'grouping'
   statement or in the 'uses' places.

2) the usm container has two user groupings: local and remote.  The
   local user set doesn't have an engineID associated with it, but local
   userIDs certainly do have an engineID (the local one).  Most
   importantly, the user in an SNMP agent would still be there and valid
   if the SNMP agent's engineID is changed (administratively) and would
   be attached to the *old* engineID.  But with the netconf setup, the
   user table would move right along to the new one and the (localized)
   key actually wouldn't be usable if the manager was deriving the key
   from a master key or password.

   In short: I think the local users need to be associated with the
   engineID too, since that's how every SNMPv3 engine out there
   fundamentally thinks.  And if the engineID changes within an SNMPv3
   engine, the user table needs to still exist *as it was before the
   change*.  A netconf dump, followed by an engineID change (inside or
   outside the yang data), followed by a restore will not let this
   happen properly.

3) the various references to "type security-level" need to be changed to
   "type snmp:security-level" (I think).  And probably for
   "admin-string" too.

4) The snmp:target augmentation for the usm I don't think is fully
   flexible enough.  The augmentation is only done with USM, but I'm not
   positive that's a good idea.  USM happens to be the first and only
   security model to use an engineID, but much of the v3 architecture
   seems to believe that other security models would likely have them
   too.  But I'm not 100% sure about this.

5) I know this was discussed heavily before, but I don't remember the
   results...  The yang model(s) imposes a number of constraints to the
   data that don't exist in any current implementations.  Things like
   references that "must" exist, etc.  I certainly understand the fact
   that in many cases the model as implemented in SNMP had to be done
   that way since SNMP doesn't have the power of netconf and sending
   lots of data at once and piece-by-piece uploading needed to be
   supported.  And thus, when we get to wrapping yang around past models
   "it's our chance to fix the model and impose proper constraints".  But
   the reality of the situation is that the underlying thing that yang
   is wrapping around, the SNMP engine and it's data, will both need to
   offer and accept data that doesn't conform to those constraints.
   Thus, as an implementer I'm not sure what I'd do.  Either way "I'd
   need to break something".  And it's unlikely, seeing as it's in an
   SNMP implementation, that I'd choose breaking the SNMP model vs the
   yang one.  There are times where the feature set is actually designed
   around "the disconnect" so they could be added later (like the radius
   based VACM modifications that added the group to the user at
   authentication time; the group would be empty before a user got
   assigned and it's possible the radius server would assigned a group
   to a user where the group hadn't been configured yet).  Again: as an
   implementer, what would you do when you tried to wrap netconf/yang
   around this problem?  You'd more than likely choose to ignore the
   yang constraints, not the other way around, because they didn't match
   the real implementation.  Most importantly, they didn't match *any*
   current implementation (it'd be somewhat different if only one
   implementation had a quirk; but in this case they *all* have that
   quirk because they're *all* conforming to an existing standard).

6) the tls-fingerprint typedef allows for 6-64 repeats of hex characters
   (and obviously :s inbetween).  But the SNMP definition is 0-255 (with
   a 1 octet prefix if non-zero).  I'm not sure why {4,31} was chosen,
   but it doesn't seem to match the flexibility in the MIB nor in the
   IANA registry.

7) There is no commonname mapping identity

8) there are multiple "FIXME" things that, um, probably need to be fixed :-)

9) The cert-specified-tm-security-name "FIXME" wonders if it should be a
   generic text in order to be as flexible as the MIB, or whether it
   to remove the identities and use augmentation.  My take is that the
   MIB was done generically because augmentation of tables is a pain in
   SNMP and that's one of the benefits of netconf, so I'd do it the
   netconf way and say that cert-specified-tm-security-name needs to
   exist if map-type == specified.  Future mappings, if ever actually
   created, can create new augmentations where the data field in the
   SNMP mib may mean something different but can be contained in a
   different netconf variable.  It makes the netconf data cleaner and
   clearer, while still allowing the netconf agent to magically map the
   two together.  But, you do need to say something like "if multiple
   data fields are defined in the netconf data, then only the current
   mapping type data will be saved to the corresponding MIB object and
   the other will be lost" or something.

10) the server-identification choice will be losing mib data if netconf
   pulls it out and then puts it back because only one set of MIB data
   will be kept (specifically, the snmpTlstmAddrServerFingerprint must
   take priority and be kept while the other is dropped, though you'd
   have to read the MIB to understand that.

   [I realize this losing of data is a fairly common one with netconf to
    snmp configuration mappings when "choice" or other restrictive data
    components are used; this is actually likely to be a common problem
    among many data models where we decide that netconf is going to be
    more restrictive than an implementation; eg, consider transferring
    DNS data where there is a choice of CNAME or anything-else;
    unfortunately real world people put both CNAMEs and MX records at
    the same location in the DNS even though the protocol specifies this
    shouldn't be done; nothing enforces it though]

11) the snmp params vs address separation in the target mib was done
    that way to reduce the data sent when zillions of addresses are
    targets and they all use the same client authentication components
    (eg, one TLS client-side certificate).  The netconf implementation
    of the target mib and the tls related components seem to require
    that all that client data be duplicated for every remote address.
    That means if a netconf manager needs to change out the client side
    certificate it'll need to probably pull and replace the whole table
    since it can't simply "edit" a single row to replace the client
    fingerprint with a simple edit operation.  I assume this is by
    design on the netconf side, but it is discarding some of the point
    of the original designed of the SNMP target mib: to separate the
    client side authentication from the address lists that you might
    talk to in order to simplify updating the client data components?

    11b) note that it also makes it difficult to switch simply between
    tls and dtls, as you need to pull and add entirely new rows to make
    it happen rather than just switch the transport type.

-- 
Wes Hardaker
SPARTA, Inc.

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 Nov 2012 13:35:47 -0500 (EST)

Hi Wes,

Thank you for this review, comments inline!

>    statement or in the 'uses' places.

Yes.  We didn't have NACM when we started this, but now that we have
we should use it.

>    fundamentally thinks.

Well, as you say, local users *does* have an engine id, but it is
implicit.  It is always the local one.  So if the local engine id
changes (which should be rare), the keys have to be updated.

So one change in the YANG view (engine-id), implies many changes in
the SNMP tables (all local users are changed).  I don't think this is
inconsistent with the MIB model.

>    And if the engineID changes within an SNMPv3

They don't have to, but we should be consistent, and snmp: is more
clear, I agree.

>    too.  But I'm not 100% sure about this.

One option could be to remove this leaf, and do what RFC 3412 says -
determine the engine id in an implementation-specific manner.

Another option could be to rename the leaf to engine-id-for-usm or
something.

>    "it's our chance to fix the model and impose proper constraints".

Actually, I think we removed all of these restrictions, based on your
previous comments.  What did we miss?  (ok, the choice in 10 below is
one)

>    but it doesn't seem to match the flexibility in the MIB nor in the

Copy & paste bug.

> 7) There is no commonname mapping identity

Bug.

> 8) there are multiple "FIXME" things that, um, probably need to be fixed :-)

I guess so...

>    the other will be lost" or something.

Ok.

>    have to read the MIB to understand that.

Ok, so you suggest we remove the choice?

>     that all that client data be duplicated for every remote

Yes.  "all client data" is in this case one leaf, the fingerprint.
But see below...

>     talk to in order to simplify updating the client data components?

There is always a tradeoff when you decide if you should you an
inderection or inline the data.  Inlining is easier, but indirection
is more flexible.  If we believe that there will be zillions (or at
least "many") of targets and the client certificate is changed often
enough, then we should keep the indirection.

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 7 Nov 2012 11:00:08 -0800

Hi -

> From: "Martin Bjorklund" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, November 06, 2012 10:35 AM
> Subject: Re: [netmod] review of netmod-snmp-cfg

...
> inconsistent with the MIB model.

Just to be absolutely clear: if the only information on hand is
the "old" engine id, the "new" engine id, and a set of localized
keys, computing the new set of localized keys is computationally
infeasible by design.

> >    outside the yang data), followed by a restore will not let this

Particularly in the case where the keys in use were *not* generated by
a localization algorithm!

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 Nov 2012 14:12:41 -0500 (EST)

> keys, computing the new set of localized keys is computationally

Sure.  So the keys needs to be re-calculated.  This is of course not
different from what you have to do with normal usm if the engine id is
changed.

> a localization algorithm!

Can the keys be non-localized?  It seems 3414 just talks about the key
being localized.

But if the key is not localized, it doesn't matter if the engine id is
modified, right?

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 7 Nov 2012 11:42:12 -0800

Hi -

> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, November 06, 2012 11:12 AM

The point is that the information necessary for recalculation is NOT THERE.
By design.  Changing the engineId should normally require the user to
re-supply the master key (since master keys should not be stored) if
localized keys are to be used.

> Can the keys be non-localized?  It seems 3414 just talks about the key

Yes.

There's nothing in the way USM works that requires keys to have been
be derived using a localization algorithm.  Using localized keys is a
matter of maintaining a reasonable level of security while respecting
the limits of human memory - an operational question, rather than a
matter of interoperability.

> But if the key is not localized, it doesn't matter if the engine id is

That is correct.  The administrator (or the administrator's tool) needs
to know whether to employ a master key + engineID + localization
algorithm, or a key directly supplied by the user, or possibly something
else.  How the key was derived is not recorded in the MIB, since
USM doesn't know or care how the key came to be.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Nov 2012 21:23:58 +0100

> matter of interoperability.

Sure? The RFC 3414 elements of procedure talk at several places about
localized keys. Are you saying that this is just a term that might
also mean non-localized keys?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 7 Nov 2012 13:42:28 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, November 06, 2012 12:23 PM
...
> also mean non-localized keys?

Yes.  In those places there are typically words like "the user's localized
private privKey is the secret key that can be used by the decryption algorithm."
Whatever secret key happens to be there is referred to as "localized
private".  The authentication and privacy algorithms work whether the keys
are derived using a localization algorithm or not.

This is a little clearer in section 11.2, where it says "If the Appendix A algorithm
is used..."  Note the "if".  Use of that (or some other!) key localization algorithm
is optional.  *Implementation* of the key localization algorithm is required (in 11.3),
but the specification of the algorithms (A.2) also makes it clear that their *use* is
optional.  

I'm certainly NOT going to recommend that folks start using non-localized keys
as a matter of day-to-day practice!  But I do think we need to recognize that
the specification does *permit* their use.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 06 Nov 2012 13:54:37 -0800

> also mean non-localized keys?

I've always described it to people thusly:

   +----------+     +--------+     +-----------+
   |  master  |     | master |     | localized |
   | password | --> |  key   | --> |    key    |
   +----------+     +--------+     +-----------+

You can start with any particular point to get to the final box.  You
can use random bits to generate a "localized key" if you want, and
upload it to the box (inside or outside of SNMP itself) and it'll work
just fine.  Or you can start with a master key and use that master key
(and the local engineID) to generate the localized key.  Or you can
start with a human password, use that to generate the master key and
then ...

And yes, I'm sure, because I've written the code to support it (and
verified it works with a bunch of other implementations).

Oh, and the SNMP-USNM-DH-OBJECTS-MIB and related RFC *could not* work
without this ability :-)
-- 
Wes Hardaker
SPARTA, Inc.