From nobody Fri Feb 26 12:44:09 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006223A00C4; Fri, 26 Feb 2021 12:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkC-BvnOHnUA; Fri, 26 Feb 2021 12:44:01 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2CAC3A00C8; Fri, 26 Feb 2021 12:44:00 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11QKhoLP031943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Feb 2021 15:43:55 -0500 Date: Fri, 26 Feb 2021 12:43:49 -0800 From: Benjamin Kaduk To: "STARK, BARBARA H" Cc: "'babel-chairs@ietf.org'" , "'d3e3e3@gmail.com'" , "'The IESG'" , "'babel@ietf.org'" , "'draft-ietf-babel-information-model@ietf.org'" Message-ID: <20210226204349.GA21@kduck.mit.edu> References: <160436211925.31069.7931310164710901437@ietfa.amsl.com> <20210209164932.GU21@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Archived-At: Subject: Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-information-model-11: (with DISCUSS and COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2021 20:44:05 -0000 Hi Barbara, Thanks for the -13 and the (extensive!) commentary here. Also inline... On Mon, Feb 22, 2021 at 09:33:12PM +0000, STARK, BARBARA H wrote: > Hi Ben, > Thanks. I think I've resolved all your comments. I'm posting a -13. > Barbara >=20 > > Hi Barbara, > >=20 > > Thanks for the extra reminder, and sorry for needing it. > >=20 > > 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 matc= hing > > the stated justification with my understanding of the facts. > >=20 > > More inline... > >=20 > > 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-ba= bel- > > information-model- > > 12__;!!BhdT!zBj3vBHMl67fealKQ4lVVarvHKEy_HaBF8ckZjMsyDy8bTal7UwG2yx0 > > Bh0kqw$ > > > Looking forward to getting these Discusses cleared... =F0=9F=98=8A > > > Thx, > > > Barbara > > > > > > > Hi Ben, > > > > Thanks a bunch for your comments. I'm sorry it's taken me a few wee= ks to > > > > provide a response. But, well, NomCom... =F0=9F=98=8A > >=20 > > Thank you (and NomCom) for your service! > >=20 > > > > And I wanted to give these comments the full attention they deserve= d. > > > > 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 pr= ivate > > > > > data such as DTLS private key values, not the certificates themse= lves > > > > > (which are public). > > > > > > > > Thanks. I agree and suggest in Section 2, changing "DTLS certificat= e values" > > to > > > > "DTLS private keys" (which are required to return no value when rea= d). > > > > > > > > > While I appreciate that IPv6 is the current version of the intern= et > > > > > 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 restricti= on from > > > > > the core protocol spec should only be undertaken by an informatio= n 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 Bab= el to > > > > configure > > > > IPv4 routing tables can be done over IPv6. > > > > > > > > Perhaps if we added to the Abstract > > > suggested changes>: > > > > "This information model only includes parameters and parameter valu= es > > > > 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 valu= es > > > > 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 mul= ticast > > > > 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 prefix= es, router > > > > advertisements or DHCPv6 to be present in the network. Link-local I= Pv6 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 bu= t have > > > > > been removed as of draft-ietf-babel-hmac-10. I assume that the i= ntent > > > > > 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-F= i) > > > > and witnessed (and been party to) the discussions in > > > > Babel where we wanted to ensure that whatever string was inputted f= or > > > > the key would yield consistent MAC computation across all implement= ations > > > > (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 tre= ated > > > > 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 wha= t is > > > > supplied to be "the actual key" so no extraneous hashing and proces= sing > > > > is needed to generate "the actual key" (other than adding zeroes if= the input > > > > key is shorter than an "actual key"). > >=20 > > These are all important considerations, and I am glad that you are keep= ing > > them in mind (while simultaneously being sad that they are necessary). > > But they seem to mostly be concers with the translation layer between t= he > > 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. >=20 > 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 (sup= plied 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. Well, my reasoning is basically that the information model is imposing a limitation on the inputs to the cryptographic API that is more stringent then the documented requirements for that API. The only vaguely plausible reason that I know of that one might want to impose this specific requirement is to affect the internal processing of that API (to avoid the extra "hash the key input" step). So, picking this specific limit on the input to the cryptographic API comes across as attempting to force a specific behavior path within the cryptographic API. IMO, if you are going to use HMAC, use the HMAC interface as documented and let HMAC determine which of its internal paths to take. If you need to impose some restriction on the inputs, do so for reasons related to processing at the application layer (including, potentially, existing implementations that do the wrong thing) and document it as such. > > > > The restrictions provided for the length of an input key are consis= tent with > > > > what the HMAC and BLAKE RFCs indicate for "actual key" length. > > > > > > > > This allows implementations of draft-ietf-babel-hmac to use existin= g HMAC > > > > and BLAKE2s libraries without worrying about what inconsistent > > manipulations > > > > the libraries or associated libraries for inputting keys do to stri= ngs that are > > > > too long to be directly used as "actual keys". > >=20 > > In particular, the procedures for using an HMAC key longer than the blo= ck > > 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.) >=20 > The Bird (language) implementation of Babel used existing code for OSPF. = That code was designed according to RFC 5709, which will hash any "Authenti= cation Key" (K) longer than the length of the hash (L) to create a cryptogr= aphic key (Ko) that is exactly L octets long. >=20 > 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 long= er than the block size of the hashing algorithm (B). For SHA-256, B !=3D 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 dif= ference was noted in RFC5709 errata. RFC 7166 updated RFC 6506 wrt this. Bu= t 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 cal= culation according to RFC 5709. Fortunately, there is great consistency amo= ng the various RFCs around zero-padding short authentication keys. >=20 > Furthermore, the Bird implementation allowed the key to be provided via a= GUI that treated the input sequence of characters as ASCII. This was, agai= n, from code that already existed for OSPF. But note there is no requiremen= t in any RFC for support of an authentication key entered in ASCII format. Thanks; this is really helpful information to know (and pretty unfortunate about the OSPF situation). But if issues with how an existing Babel implementation handles input keys longer than the output length of the hash are what motivate the key length restrictions, shouldn't the length restrictions reflect the hash output length rather than the hash block size? > The C implementation of Babel was designed with the expectation that a ce= ntralized 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 A= SCII 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. (I assume that "does not accept ASCII input" just means "does not do processing on input to take a human-presentable ASCII representation of a binary key and convert it into the underlying binary key", as opposed to "checks for the condition where all octets of the input are in the ASCII printable range and rejects that 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 Bab= el implementations (in the babel-mac draft). There was discussion of requir= ing the key supplied to an implementation to be exactly the cryptographic k= ey (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 addition= al restrictions on the format of provided keys (other than restrictions imp= osed by SHA-256 and BLAKE2s RFCs on keys) and not to choose between RFC 570= 9 or RFC 2104. So the Bird and C implementations did not need to change wha= t they were doing. But the info model would restrict the length and datatyp= e of "authentication key" values it supplied so the cryptographic keys the = implementations ended up calculating from the input binary authentication k= ey would always be the same. The values supplied by the info model will sim= ply never invoke code that would result in inconsistent cryptographic key v= alues. Thank you very much for the summary of the prior WG discussions; I cannot hope to try to repeat the depth of consideration that was already given. As above, though, my reading of the -13 is that it does allow hitting the code that would result in inconsistent key values, since the stated limit for HMAC-SHA256 is 64 bytes, not 32. > > 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 larg= er > > than 64 bytes (it talks only of padding the key and setting as d[0], wh= ere > > 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) th= at > > justification should probably be in the document, and (2) I don't see a > > factual basis for limiting HMAC keys to the block length. >=20 > 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 consist= ent cryptographic key calculation. I would strongly encourage adding some discussion of the motivation for the length limits into the draft itself. > > (For what it's worth I did do a bit of math, and even if the "actual ke= y" > > 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.) If the limit is actually going to be 32 characters, the numbers go down accordingly, but 165 bits is not shabby, and adding in lowercase letters gets you up to 190 bits, and the full 95 ASCII printables cap out at 210 bits. > -- snipped where there were no new comments to reply to --- >=20 > > > > > -----------------------------------------------------------------= ----- > > > > > COMMENT: > > > > > -----------------------------------------------------------------= ----- >=20 > -- snipped --- >=20 > > > > > babel-self-router-id: The router-id used by this instance of = the > > > > > Babel protocol to identify itself. [I-D.ietf-babel-rfc6126= bis] > > > > > describes this as an arbitrary string of 8 octets. The rou= ter-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 i= mplement > > > > 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 w= hether > > > > or not Babel was enabled. In the absence of YANG, a disabled > > implementation > > > > is happy for its router-id to be all zeroes. > >=20 > > I'd consider adding a parenthetical to explain why the requirement exis= ts, > > but that's editorial and up to your judgment. >=20 > After discussing with the WG, we determined that the YANG model didn't ne= ed the restriction, after all. So we're deleting the sentence "The router-id > value MUST NOT consist of all zeroes or all ones." >=20 > -- snipped -- >=20 > > > > > Section 3.7 > > > > > > > > > > I don't wish to revisit the decision, but it might have been inte= resting > > > > > to record some of the reasoning for having an additional abstract= ion 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 f= or > > > > different interfaces, the same keys for a set of interfaces, the sa= me > > > > keys for all interfaces, and have a default set of keys in case a n= ew > > > > interface were instantiated (e.g., a tunneled interface). Also, the= re > > > > 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 set= s, > > > > 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 explanat= ion is > > > > useful, I could add a paragraph explaining the sets as useful in ma= king > >=20 > > I found it useful, at least -- thank you! > >=20 > > > > it easy to change keys/certs to Security Considerations. Ensuring u= sability > > > > of key/cert change is, I think, a valid security consideration. > >=20 > > I agree; this is covered (somewhat) in BCP 107. >=20 > I did add a paragraph to the security section of the -12 version along th= is line. Thanks for that! >=20 > -- snipped -- >=20 > > > > > 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, s= ince > > > > > the value is too long to be useful for identification. Thi= s value > > > > > > > > > > Some guidance on whether or not it is expected to be useful to dr= aw > > > > > 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 requi= rements > > > > or expectations. Unless pressed, I will make no change here. > >=20 > > 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 invol= ved > > agrees on what name maps to what entity! I presume that the TR-181 sch= eme > > is not susceptible to collisions on the auto-generated names... >=20 > Auto-generated names in TR-181 are done by the managed device (residentia= l gateway, set-top-box, etc.) when it adds an object instance to the data m= odel. They are unique internal to the device. I'm not aware of any implemen= tations that do anything other than sequential processing of data model cha= nges, so it should be quite simple for a device to ensure internal uniquene= ss. If the managing entity wants consistent or identical naming across all = devices, then it's the responsibility of the managing entity (via the manag= ement system) to set the names and set them consistently. This is outside t= he 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 hav= e been fought over naming schemes, mechanisms, and parameters. This is wher= e we've landed. We do allow managing entities to shoot themselves in the fo= ot, if they so choose (e.g., if they allow multiple uncoordinated managemen= t systems to provide keys). Okay. Thanks for the TR-181 lesson :) > -- snipped -- >=20 > > > > > 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 sho= uld 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 certificat= e" > > > > is not acceptable, I could change to just "certificate". I don't wa= nt > > > > to constrain what type of certificate this table can support, beyond > > > > PEM format and for use with an implementation of draft-ietf-babel-d= tls. > >=20 > > 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. > >=20 > > (*) okay, X.509 certificates might have an extendedKeyUsage extension = that > > indicates they are intended for TLS connections, but they are still X.5= 09 > > certificates. >=20 > I searched for "certificate" and found 1 instance of "DTLS certificate" (= in the babel-dtls-cert-types description). I'll change "List of supported D= TLS certificate types." there to "List of supported certificate types." >=20 > -- snipped -- >=20 > > > > > Section 5 > > > > > > > > > > We do expose an operation to get a packet dump, but it's not clea= r that > > > > > there are particularly noteworthy security considerations regardi= ng that > > > > > -- the dump would appear to be the ciphertext based on the langua= ge > > > > > used, so it would not be a way to bypass DTLS encryption, for exa= mple. > > > > > > > > > > This information model defines objects that can allow credenti= als > > > > > (for this device, for trusted devices, and for trusted certifi= cate > > > > > authorities) to be added and deleted. Public keys may be expo= sed > > > > > through this model. This model requires that private keys nev= er 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 credent= ials > > > > (whether in error or in malice) will cause the Babel packets between > > > > the incorrectly configured router(s) and other routers in the netwo= rk > > > > not to be trusted by each other. It will not be possible to effecti= vely > > > > use Babel to determine and react to routing changes in the network, > > > > in this case." > >=20 > > 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, b= ut I > > find that it can be useful to have it stated explicitly. >=20 > I've added the sentence "Misconfiguration of security credentials can cau= se > a denial of service condition for the Babel routing protocol." > This new sentence comes after the sentence " Misconfiguration (whether un= intentional or malicious) can prevent > reachability or cause poor network performance (increased latency, jitter= , etc.)." Much appreciated. Thanks again, Ben