Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-information-model-11: (with DISCUSS and COMMENT)

["STARK, BARBARA H" <[e-mail]>]

Hi Ben,
Thanks. I think I've resolved all your comments. I'm posting a -13.
Barbara

> Hi Barbara,
> 
> Thanks for the extra reminder, and sorry for needing it.
> 
> I think the -12 addresses most of my concerns, but we may need to talk a
> bit more about the HMAC key length topic -- I'm having a hard time matching
> the stated justification with my understanding of the facts.
> 
> More inline...
> 
> On Wed, Feb 03, 2021 at 10:31:12PM +0000, STARK, BARBARA H wrote:
> > Hi Ben (and IESG),
> > I just wanted to mention that I did publish a -12 draft that I think resolves all
> comments (in the manner I said I would in my various responses).
> > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-babel-
> information-model-
> 12__;!!BhdT!zBj3vBHMl67fealKQ4lVVarvHKEy_HaBF8ckZjMsyDy8bTal7UwG2yx0
> Bh0kqw$
> > Looking forward to getting these Discusses cleared... 😊
> > Thx,
> > Barbara
> >
> > > Hi Ben,
> > > Thanks a bunch for your comments. I'm sorry it's taken me a few weeks to
> > > provide a response. But, well, NomCom... 😊
> 
> Thank you (and NomCom) for your service!
> 
> > > And I wanted to give these comments the full attention they deserved.
> > > Barbara
> > >
> > > > ----------------------------------------------------------------------
> > > > DISCUSS:
> > > > ----------------------------------------------------------------------
> > > >
> > > > Section 2 says that the "DTLS certificate values" are required to return
> > > > no value when read, but this property seems to be intended for private
> > > > data such as DTLS private key values, not the certificates themselves
> > > > (which are public).
> > >
> > > Thanks. I agree and suggest in Section 2, changing "DTLS certificate values"
> to
> > > "DTLS private keys" (which are required to return no value when read).
> > >
> > > > While I appreciate that IPv6 is the current version of the internet
> > > > protocol, I do see that 6126bis allows for Babel to run over both IPv6
> > > > and IPv4, yet this document in multiple places implicitly assumes that
> > > > Babel runs over IPv6, to the exclusion of IPv4.  Such a restriction from
> > > > the core protocol spec should only be undertaken by an information model
> > > > with clear reasoning and loud disclaimer.
> > >
> > > The WG did discuss this and expressed the view that they were only
> interested
> > > in defining configuration for Babel over IPv6. Note that use of Babel to
> > > configure
> > > IPv4 routing tables can be done over IPv6.
> > >
> > > Perhaps if we added to the Abstract <Juliusz: please look at this and provide
> > > suggested changes>:
> > > "This information model only includes parameters and parameter values
> > > useful for managing Babel over IPv6.
> > > This model has no parameters or values specific to operating Babel
> > > over IPv4, although Babel can be operated over IPv4.
> > > Note that Babel over IPv6 can be used for configuration of both
> > > IPv4 and IPv6 routes."
> > >
> > > and then expand on this in the Introduction with
> > > "This information model only includes parameters and parameter values
> > > useful for managing Babel over IPv6.
> > > This model has no parameters or values specific to operating Babel
> > > over IPv4, even though [ID.ietf-babel-rfc6126bis] does define a multicast
> > > group for sending and listening to multicast announcements on IPv4.
> > > There is less likelihood of breakage due to
> > > inconsistent configuration and increased implementation simplicity
> > > if Babel is operated always and only over IPv6. Running Babel over IPv6
> > > requires IPv6 at the link layer and does not need advertised prefixes, router
> > > advertisements or DHCPv6 to be present in the network. Link-local IPv6 is
> widely
> > > supported among devices where Babel is expected to be used.
> > > Note that Babel over IPv6 can be used for configuration of both
> > > IPv4 and IPv6 routes."
> > >
> > > > Similarly (as Roman notes), we are putting requirements on the key
> > > > length for MAC keys (relative to the block size of the underlying hash
> > > > function) that have were once present in draft-ietf-babel-hmac but have
> > > > been removed as of draft-ietf-babel-hmac-10.  I assume that the intent
> > > > is not to impose additional restrictions compared to the protocol spec,
> > > > thus we need to catch up to those changes.
> > >
> > > How humans interact with configuration parameters presented through
> > > a data model instantiation of this information model is a concern. Having
> > > experienced the horrors of the days of configuring WEP keys (which were
> > > either ASCII or hex and caused most people not to use WEP with Wi-Fi)
> > > and witnessed (and been party to) the discussions in
> > > Babel where we wanted to ensure that whatever string was inputted for
> > > the key would yield consistent MAC computation across all implementations
> > > (i.e.,
> > > would yield consistent "actual key"), I believe
> > > it is imperative for the information model to constrain the input. As I
> explained
> > > in my response to Roman and Valery, we saw considerable variability in
> > > how existing libraries for allowing users to supply a key value treated
> > > values that could not be directly used as what RFC 2104 calls "the actual
> key".
> > > To ensure human users are successful in supplying the same "actual key"
> value
> > > to various
> > > implementations, it's necessary for user interfaces to restrict what is
> > > supplied to be "the actual key" so no extraneous hashing and processing
> > > is needed to generate "the actual key" (other than adding zeroes if the input
> > > key is shorter than an "actual key").
> 
> These are all important considerations, and I am glad that you are keeping
> them in mind (while simultaneously being sad that they are necessary).
> But they seem to mostly be concers with the translation layer between the
> input layer and the cryptographic API, and the restrictions that I am
> concerned about are ones that relate to processing done within the
> cryptographic API boundary.

I find this statement a little confusing, since the info model is placing no restrictions on processing done within a cryptographic API boundary. It's only placing restrictions on the length and datatype of a parameter (supplied via a management protocol or user interface) that is then provided to a Babel implementation. What the Babel implementation does to or with this parameter is not something the info model cares about.

> > > The restrictions provided for the length of an input key are consistent with
> > > what the HMAC and BLAKE RFCs indicate for "actual key" length.
> > >
> > > This allows implementations of draft-ietf-babel-hmac to use existing HMAC
> > > and BLAKE2s libraries without worrying about what inconsistent
> manipulations
> > > the libraries or associated libraries for inputting keys do to strings that are
> > > too long to be directly used as "actual keys".
> 
> In particular, the procedures for using an HMAC key longer than the block
> length of the underlying hash function (hash the key first) are
> longstanding and well-implemented.  Are you saying that you have
> experiences with buggy HMAC implementations that don't do this?  (If so,
> that would be a great tidbit to mention in the document as motivation.)

The Bird (language) implementation of Babel used existing code for OSPF. That code was designed according to RFC 5709, which will hash any "Authentication Key" (K) longer than the length of the hash (L) to create a cryptographic key (Ko) that is exactly L octets long.

What RFC 5709 describes is different than what RFC 2104 (HMAC) describes. RFC 2104 says to create a hash of the authentication key (K) if it is longer than the block size of the hashing algorithm (B). For SHA-256, B != L. Therefore, using RFC 5709 will get a different value for the cryptographic key than RFC 2104, for authentication key length between L and B. This difference was noted in RFC5709 errata. RFC 7166 updated RFC 6506 wrt this. But RFC 7166 didn't update RFC 5709.  RFC 7474 updated RFC 5709 and kept the L boundary. We looked at the Bird library code which does indeed do the calculation according to RFC 5709. Fortunately, there is great consistency among the various RFCs around zero-padding short authentication keys.

Furthermore, the Bird implementation allowed the key to be provided via a GUI that treated the input sequence of characters as ASCII. This was, again, from code that already existed for OSPF. But note there is no requirement in any RFC for support of an authentication key entered in ASCII format.

The C implementation of Babel was designed with the expectation that a centralized system would push the key out to all the routers. It assumed the supplied key was in binary format. Preferably, the centralized system would randomly generate the binary value. But if there were a user entering an ASCII string at the centralized system, the centralized system would be able to do whatever desired manipulation and push a suitable binary out to all routers. The C implementation does not accept ASCII input.

The WG discussed all of this extensively in January of 2019. And then re-hashed it (haha) in August of 2019. There was discussion of imposing either RFC 5709 or RFC 2104 calculation for long "authentication keys" on the Babel implementations (in the babel-mac draft). There was discussion of requiring the key supplied to an implementation to be exactly the cryptographic key (so all manipulation was done external to Babel). And other ideas (I can point to the emails in the archive, if you like; there were many emails). The August 2019 decision was for the babel-mac draft not to impose additional restrictions on the format of provided keys (other than restrictions imposed by SHA-256 and BLAKE2s RFCs on keys) and not to choose between RFC 5709 or RFC 2104. So the Bird and C implementations did not need to change what they were doing. But the info model would restrict the length and datatype of "authentication key" values it supplied so the cryptographic keys the implementations ended up calculating from the input binary authentication key would always be the same. The values supplied by the info model will simply never invoke code that would result in inconsistent cryptographic key values.

> The situation for Blake2s-128 (which is being used directly and not via
> HMAC) is not quite so clear to me since it's a more recent innovation, and
> RFC 7693 seems rather unclear about what to do if the input key is larger
> than 64 bytes (it talks only of padding the key and setting as d[0], where
> d[0] is a 16-word block, and for Blake2s words are 32 bits).  So while
> limiting the length of the Blake2s key may be justified in fact, (1) that
> justification should probably be in the document, and (2) I don't see a
> factual basis for limiting HMAC keys to the block length.

And we also could find nothing that described what to do for long keys in BLAKE2s. So the datatype and length restriction would again ensure consistent cryptographic key calculation.

> (For what it's worth I did do a bit of math, and even if the "actual key"
> is limited to uppercase letters plus digits, a 64-character string can
> still contain some 330 bits of entropy, which is stronger than a 32-byte
> random string.  You'd have to be really limited in what characters can be
> used, e.g., to only digits, in order to have the maximum theoretical
> entropy of the 64-character string fall below 256 bits.)

-- snipped where there were no new comments to reply to ---

> > > > ----------------------------------------------------------------------
> > > > COMMENT:
> > > > ----------------------------------------------------------------------

-- snipped ---

> > > >    babel-self-router-id:  The router-id used by this instance of the
> > > >       Babel protocol to identify itself.  [I-D.ietf-babel-rfc6126bis]
> > > >       describes this as an arbitrary string of 8 octets.  The router-id
> > > >       value MUST NOT consist of all zeroes or all ones.
> > > >
> > > > Why is the MUST NOT a requirement of the information model rather than
> > > > the protocol?
> > >
> > > Because it isn't an issue for a Babel implementation that doesn't implement
> > > this information model. It only became an issue when the YANG model
> > > needed to use this as a unique key and needed the object to exist whether
> > > or not Babel was enabled. In the absence of YANG, a disabled
> implementation
> > > is happy for its router-id to be all zeroes.
> 
> I'd consider adding a parenthetical to explain why the requirement exists,
> but that's editorial and up to your judgment.

After discussing with the WG, we determined that the YANG model didn't need the restriction, after all. So we're deleting the sentence "The router-id
value MUST NOT consist of all zeroes or all ones."

-- snipped --

> > > > Section 3.7
> > > >
> > > > I don't wish to revisit the decision, but it might have been interesting
> > > > to record some of the reasoning for having an additional abstraction for
> > > > "key set" and having a list of key-sets, vs just having a list of keys
> > > > directly.  (Similarly for the DTLS cert sets.)
> > >
> > > There were requirements that it be possible to use different keys for
> > > different interfaces, the same keys for a set of interfaces, the same
> > > keys for all interfaces, and have a default set of keys in case a new
> > > interface were instantiated (e.g., a tunneled interface). Also, there
> > > was a requirement that it be easy to change the current key by first
> > > adding the new key and then removing the old key. By having key sets,
> > > it was easy to do a key change without explicitly adding the new
> > > key to and deleting the old key from each impacted interface. Only
> > > the key set needed to be updated. Ditto for certs. If this explanation is
> > > useful, I could add a paragraph explaining the sets as useful in making
> 
> I found it useful, at least -- thank you!
> 
> > > it easy to change keys/certs to Security Considerations. Ensuring usability
> > > of key/cert change is, I think, a valid security consideration.
> 
> I agree; this is covered (somewhat) in BCP 107.

I did add a paragraph to the security section of the -12 version along this line.


-- snipped --

> > > > Section 3.10
> > > >
> > > >    babel-cert-name:  A unique name for this DTLS certificate that can be
> > > >       used to identify the certificate in this object instance, since
> > > >       the value is too long to be useful for identification.  This value
> > > >
> > > > Some guidance on whether or not it is expected to be useful to draw
> > > > naming information from the certificate's Subject information, vs an
> > > > arbitrary or fingerprint-based naming scheme, might be in order.
> > >
> > > All constraints from an info model perspective are provided in the
> > > description: unique and not empty. An implementation that supports
> > > auto-generation of the name can use whatever rules it wants.
> > > My TR-181 data model will allow the user to provide any unique and
> > > non-empty string they want. If the user provides none, the
> > > auto-generation scheme is implementation-specific and common
> > > across the entire TR-181 data model (and not just Babel). I think it
> > > would be odd to explicitly call out the absence of additional requirements
> > > or expectations. Unless pressed, I will make no change here.
> 
> I don't have any specific text that I want to press for, but I will
> reiterate that when names are used for making authentication and
> authorization decisions, it is critically important that everyone involved
> agrees on what name maps to what entity!  I presume that the TR-181 scheme
> is not susceptible to collisions on the auto-generated names...

Auto-generated names in TR-181 are done by the managed device (residential gateway, set-top-box, etc.) when it adds an object instance to the data model. They are unique internal to the device. I'm not aware of any implementations that do anything other than sequential processing of data model changes, so it should be quite simple for a device to ensure internal uniqueness. If the managing entity wants consistent or identical naming across all devices, then it's the responsibility of the managing entity (via the management system) to set the names and set them consistently. This is outside the scope of the scheme. The device will reject attempts to set a name to a value already being used in its data model. Major battles and even wars have been fought over naming schemes, mechanisms, and parameters. This is where we've landed. We do allow managing entities to shoot themselves in the foot, if they so choose (e.g., if they allow multiple uncoordinated management systems to provide keys).

-- snipped --

> > > > Also, it's somewhat unusual to talk about "(D)TLS certificates" as
> > > > opposed to X.509 certificate, raw public key, etc..
> > >
> > > The TLS RFCs refer to these things as "certificates" in all cases, and
> > > the IANA registry that lists defined types of these things is titled
> > > "TLS Certificate Types". This info model table is defined so it should be
> > > possible for other certificate types to be supported (if desired or
> > > implemented) with no change to this table structure -- so long as
> > > the certificate can be expressed in PEM format. If "DTLS certificate"
> > > is not acceptable, I could change to just "certificate". I don't want
> > > to constrain what type of certificate this table can support, beyond
> > > PEM format and for use with an implementation of draft-ietf-babel-dtls.
> 
> I would (mildly) prefer just "certificate" -- in my mind, certificates are
> things that (D)TLS consumes, but other than having a list of preexisting
> certificate types for which the mapping into TLS codepoints, there is
> nothing (*) TLS-specific about those certificates.
> 
> (*) okay, X.509 certificates  might have an extendedKeyUsage extension that
> indicates they are intended for TLS connections, but they are still X.509
> certificates.

I searched for "certificate" and found 1 instance of "DTLS certificate" (in the babel-dtls-cert-types description). I'll change "List of supported DTLS certificate types." there to "List of supported certificate types."

-- snipped --

> > > > Section 5
> > > >
> > > > We do expose an operation to get a packet dump, but it's not clear that
> > > > there are particularly noteworthy security considerations regarding that
> > > > -- the dump would appear to be the ciphertext based on the language
> > > > used, so it would not be a way to bypass DTLS encryption, for example.
> > > >
> > > >    This information model defines objects that can allow credentials
> > > >    (for this device, for trusted devices, and for trusted certificate
> > > >    authorities) to be added and deleted.  Public keys may be exposed
> > > >    through this model.  This model requires that private keys never be
> > > >
> > > > It might be worth another sentence indicating the scale of the
> > > > consequences of erroneously/maliciously setting such credentials.
> > >
> > > I'm not quite sure what to say? "Incorrect configuration of credentials
> > > (whether in error or in malice) will cause the Babel packets between
> > > the incorrectly configured router(s) and other routers in the network
> > > not to be trusted by each other. It will not be possible to effectively
> > > use Babel to determine and react to routing changes in the network,
> > > in this case."
> 
> Or just "incorrect provision of credentials (whether due to error or
> malice) will cause a denial of service condition for the Babel routing
> protocol on the node in question".  It may seem obvious to you and I, but I
> find that it can be useful to have it stated explicitly.

I've added the sentence "Misconfiguration of security credentials can cause
a denial of service condition for the Babel routing protocol."
This new sentence comes after the sentence " Misconfiguration (whether unintentional or malicious) can prevent
reachability or cause poor network performance (increased latency, jitter, etc.)."

-- snipped to end ---