Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-resource-directory-25: (with DISCUSS and COMMENT)

[Barry Leiba <[e-mail]>]

Authors and WGCs,
We have four DISCUSS ballots on this and a number of other IESG comments,
and I haven’t seen responses to the ADs.  When can we get some engagement
on these issues?

Barry

On Thu, Aug 13, 2020 at 4:12 AM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

> Benjamin Kaduk has entered the following ballot position for
>
> draft-ietf-core-resource-directory-25: Discuss
>
>
>
> When responding, please keep the subject line intact and reply to all
>
> email addresses included in the To and CC lines. (Feel free to cut this
>
> introductory paragraph, however.)
>
>
>
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>
> for more information about IESG DISCUSS and COMMENT positions.
>
>
>
>
>
> The document, along with other ballot positions, can be found here:
>
> https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/
>
>
>
>
>
>
>
> ----------------------------------------------------------------------
>
> DISCUSS:
>
> ----------------------------------------------------------------------
>
>
>
> I agree with Roman that the authorization model seems under-developed.
>
> While I recognize that there is need for flexibility across various
>
> deployments, I think that we should be providing a default model (and
>
> procedures for it) that will apply in many cases, and let
>
> deployments specify alternate models if needed.  This stuff is hard
>
> enough to get right that we should have a secure option that people can
>
> use if they don't need to have customized details.  (To be clear, I
>
> agree with the change of focus from -24 to -25 on the properties that a
>
> security policy needs to provide and/or consider, as that is
>
> fundamentally the important thing.  I just want a fallback/default
>
> option that "does something reasonable in most cases" in addition.
>
> Doing that by reference to some other existing thing would be fine, if
>
> such a thing exists.)
>
>
>
> In particular, the current text seems to rely on the authorization
>
> model including:
>
>
>
> (1) the RD knowing how clients will be using it (and thus what
>
> properties the RD needs to enforce), which in the general case cannot be
>
> known (though for static networks it could be), yet I don't see any
>
> discussion that indicates this as a prerequisite; and
>
>
>
> (2) the client either knowing out-of-band that an entity is authorized
>
> to act as a RD or just blindly trusting any of the unauthenticated (*)
>
> advertisement mechanisms.  (* Yes, there may be some protection in the
>
> network on subscribing to the relevant multicast address, DNS-SD, etc.,
>
> but the client cannot a priori know that such protections are in place.)
>
>
>
> Relatedly, the naming model and naming authority should have some
>
> clearer discussion.  We do mention in Section 7 the possibility for a
>
> weak naming model where the RD is responsible for enforcing uniqueness
>
> of names but otherwise link attributes are the primary authorization
>
> criteria (vs. a traditional scheme with a naming authority and naming
>
> hierarchy), but with naming as a fundamental prerequisite of any
>
> authentication/authorization scheme, I think clearer discussion of how a
>
> naming model is to be selected (and, perhaps more importantly, that it
>
> must be fixed as part of a given deployment) for a given network is
>
> needed.
>
>
>
> If I understand correctly, we have some codepoint squatting going on in
>
> the examples (e.g., for resource types).
>
>
>
> We should talk about the security properties of the various RD discovery
>
> mechanisms that are defined.
>
>
>
>
>
> ----------------------------------------------------------------------
>
> COMMENT:
>
> ----------------------------------------------------------------------
>
>
>
> My apologies for where these comments diverge off into rambling
>
> incoherency, or where I'm misunderstanding something that's clearly laid
>
> out; this document had the misfortune of being the last one I got to
>
> this week.
>
>
>
> Section 1
>
>
>
>    [RFC6690] only describes how to discover resources from the web
>
>    server that hosts them by querying "/.well-known/core".  In many
>
>    constrained scenarios, direct discovery of resources is not practical
>
>    due to sleeping nodes, disperse networks, or networks where multicast
>
>    traffic is inefficient.  These problems can be solved by employing an
>
>    entity called a Resource Directory (RD), which contains information
>
>    about resources held on other servers, allowing lookups to be
>
>    performed for those resources.
>
>
>
> nit(?): I'd consider specifying that the RD is "a trusted entity".
>
> (Even when the resources themselves are authenticated, a hostile RD can
>
> still deny existence of a given resource, so by choosing to use an RD
>
> there is some level of trust involved.)
>
>
>
> Section 2
>
>
>
>    Resource Directory (RD)
>
>       A web entity that stores information about web resources and
>
>       implements the REST interfaces defined in this specification for
>
>       discovery, for the creation, the maintenance and the removal of
>
>       registrations, and for lookup of the registered resources.
>
>
>
> nit: the list structure is not parallel here.  Maybe "for discovery,
>
> creation, maintenance, and removal of registrations, and for lookup of
>
> the registered resources"?
>
>
>
>    Commissioning Tool
>
>       Commissioning Tool (CT) is a device that assists during the
>
>       installation of the network by assigning values to parameters,
>
>       naming endpoints and groups, or adapting the installation to the
>
>       needs of the applications.
>
>
>
> Is "the installation of the network" a one-time event?   (Might a CT be
>
> involved when adding a new device to a network at a later time?)
>
>
>
> Section 3.1
>
>
>
>    Information SHOULD only be stored in the RD if it can be obtained by
>
>    querying the described device's /.well-known/core resource directly.
>
>
>
> When might that not be the case?
>
>
>
> Section 3.2
>
>
>
>    The RD architecture is illustrated in Figure 1.  An RD is used as a
>
>    repository of registrations describing resources hosted on other web
>
>    servers, also called endpoints (EP).  An endpoint is a web server
>
>    associated with a scheme, IP address and port.  A physical node may
>
>
>
> (side note) hmm, I feel like in the HTTP world an endpoint is more
>
> likely to be associated with a DNS name than an IP address, in common
>
> usage.  Also, we later go on to assert that the endpoint's name has
>
> primacy and that the IP address/port can be ephemeral.
>
>
>
>    An endpoint uses specific interfaces to register, update and remove a
>
>    registration.  It is also possible for an RD to fetch Web Links from
>
>    endpoints and add their contents to its registrations.
>
>
>
>    At the first registration of an endpoint, a "registration resource"
>
>    is created, the location of which is returned to the registering
>
>    endpoint.  The registering endpoint uses this registration resource
>
>    to manage the contents of registrations.
>
>
>
> Does the "RD fetches links unilaterally" case count as a "first
>
> registration of an endpoint"?  I'm having a hard time seeing how these
>
> two statements are consistent with each other, and a naive reading
>
> admits the possibility that a given endpoint could be "locked out" of
>
> the ability to manage the contents of its registrations.
>
>
>
> Section 4
>
>
>
>    REST clients (registrant-EPs and CTs during registration and
>
>    maintenance, lookup clients, RD servers during simple registrations)
>
>    MUST be prepared to receive any unsuccessful code and act upon it
>
>    according to its definition, options and/or payload to the best of
>
>    their capabilities, falling back to failing the operation if recovery
>
>    is not possible.  In particular, they should retry the request upon
>
>
>
> "MUST be prepared [...] to the best of their abilities" seems
>
> non-actionable.  The stuff after "In particular", on the other hand, is
>
> actual concrete guidance that could be mandated using normative
>
> language.
>
>
>
> Section 4.1
>
>
>
>    1.  In a 6LoWPAN, just assume the Border Router (6LBR) can act as an
>
>        RD (using the ABRO option to find that [RFC6775]).  Confirmation
>
>        can be obtained by sending a Unicast to "coap://[6LBR]/.well-
>
>        known/core?rt=core.rd*".
>
>
>
> nit(?): I was unaware that "Unicast" was a proper noun.
>
>
>
> Section 4.3
>
>
>
>    "core.rd" in the query string.  Likewise, a Resource Type parameter
>
>    value of "core.rd-lookup*" is used to discover the URIs for RD Lookup
>
>    operations, core.rd* is used to discover all URI paths for RD
>
>    operations.  [...]
>
>
>
> Is the distinction between URIs (for RD Lookup) and URI paths (for RD)
>
> important here?
>
>
>
>    While the link targets in this discovery step are often expressed in
>
>    path-absolute form, this is not a requirement.  Clients of the RD
>
>    SHOULD therefore accept URIs of all schemes they support, both as
>
>    URIs and relative references, and not limit the set of discovered
>
>    URIs to those hosted at the address used for URI discovery.
>
>
>
> I'm not sure I see how the "not limit [...] to those hosted at the
>
> address used for URI discovery" follows from the non-requirement for
>
> expression of the link-targets from discovery in path-absolute form.
>
> (Given the ability to send the discovery query to a multicast address,
>
> the guidance seems okay; it's just the "therefore" that is puzzling me.)
>
>
>
>    It would typically be stored in an implementation information link
>
>    (as described in [I-D.bormann-t2trg-rel-impl]):
>
>
>
>    Req: GET /.well-known/core?rel=impl-info
>
>
>
> This seems to be depicting a link-relation type that is not registered
>
> at https://www.iana.org/assignments/link-relations/link-relations.xhtml
>
> , i.e., codepoint squatting.  Please put in a stronger disclaimer that
>
> this is an example link relation type, not just an example exchange.
>
>
>
> Section 5
>
>
>
> These first few paragraphs give the impression that this is
>
> first-come-first-served with minimal authentication or authorization
>
> checking.  Mentioning that there are authorization checks, with a
>
> forward-reference, might be helpful.
>
>
>
>    further parameters (see Section 9.3).  The RD then creates a new
>
>    registration resource in the RD and returns its location.  The
>
>
>
> Is this returned "registration resource" expected to function as a
>
> "capability URL" (https://www.w3.org/TR/capability-urls/) that would
>
> need to contain an appropriate amount of entropy to be reasonably
>
> unguessable by parties other than the registrant-ep/CT responsible for
>
> it?
>
>
>
>    The registration request interface is specified as follows:
>
>
>
>    Interaction:  EP -> RD
>
>
>
> I thought that the CT could be a requestor as well as the EP.
>
>
>
>          well.  The endpoint name and sector name are not set when one
>
>          or both are set in an accompanying authorization token.
>
>
>
> What should the RD do if they are set but also present in the
>
> accompanying authorization token?
>
>
>
>    Req: POST coap://rd.example.com/rd?ep=node1
>
>    Content-Format: 40
>
>    Payload:
>
>    </sensors/temp>;ct=41;rt="temperature-c";if="sensor",
>
>
>
> (side note) XML for the sensors, not SenML?  With Carsten as an author,
>
> even? ;)
>
>
>
>    An RD may optionally support HTTP.  Here is an example of almost the
>
>    same registration operation above, when done using HTTP.
>
>
>
>    Req:
>
>    POST /rd?ep=node1&base=http://[2001:db8:1::1] HTTP/1.1
>
>    Host: example.com
>
>
>
> Wouldn't "Host: rd.example.com" be closer to "almost the same
>
> registration"?
>
>
>
> Section 5.1
>
>
>
> I'm a little uneasy about specifying new behavior for POST to the
>
> existin /.well-known/core that was defined by RFC 6690 for other uses.
>
> What factors go into using the same well-known URI vs. defining a new
>
> one for this usage?
>
>
>
>    The sequence of fetching the registration content before sending a
>
>    successful response was chosen to make responses reliable, and the
>
>    caching item was chosen to still allow very constrained registrants.
>
>
>
> I'm not sure what "the caching item" is supposed to be (if it's not a
>
> typo/misordering of words).
>
>
>
> Section 5.3
>
>
>
>    queries concerning this endpoint.  The RD SHOULD continue to provide
>
>    access to the Registration Resource after a registration time-out
>
>    occurs in order to enable the registering endpoint to eventually
>
>    refresh the registration.  The RD MAY eventually remove the
>
>    registration resource for the purpose of garbage collection.  If the
>
>    Registration Resource is removed, the corresponding endpoint will
>
>    need to be re-registered.
>
>
>
> (This MAY is actually a MUST for the simple registration case, per §5.1,
>
> right?)
>
>
>
> Section 5.3.1
>
>
>
>    An update MAY update the lifetime or the base URI registration
>
>    parameters "lt", "base" as in Section 5.  Parameters that are not
>
>
>
> What about the "extra-attrs"; are they inherently forbidden from
>
> updates?
>
>
>
>                             base :=  Base URI (optional).  This
>
>          parameter updates the Base URI established in the original
>
>          registration to a new value.  If the parameter is set in an
>
>          update, it is stored by the RD as the new Base URI under which
>
>          to interpret the relative links present in the payload of the
>
>          original registration, following the same restrictions as in
>
>          the registration.  If the parameter is not set in the request
>
>
>
> nit: is it the interpretation of relative links that is following the
>
> same restrictions as in the registration, or the new value of the
>
> parameter being supplied in the update?
>
>
>
>    The following example shows how the registering endpoint updates its
>
>    registration resource at an RD using this interface with the example
>
>    location value: /rd/4521.
>
>
>
> The path component "4521" contains a worryingly small amount of
>
> unpredictableness; I would prefer examples that used longer random
>
> locations, as for capability URLs.  (Throughout the document, of
>
> course.)  See also draft-gont-numeric-ids-sec-considerations, that I'm
>
> AD sponsoring, though I do not see any clear issues on first glance.
>
>
>
> (Also, it might be worth another sentence that this update is serving
>
> just to reset the lifetime, making no other changes, since this might be
>
> expected to be a common usage.)
>
>
>
> Section 6
>
>
>
> With "Resource Lookup" and "Endpoint Lookup" as (apparent) top-level
>
> siblings, would it make sense to put 6.2, or at least 6.3, as
>
> subsections under 6.1?
>
>
>
> Section 6.1
>
>
>
>    Resource lookup results in links that are semantically equivalent to
>
>    the links submitted to the RD.  The links and link parameters
>
>    returned by the lookup are equal to the submitted ones, except that
>
>    the target and anchor references are fully resolved.
>
>
>
> Are the "submitted ones" the submissions at registration time, or during
>
> the lookup query itself?  (I assume registration-time, but being
>
> explicit costs little.)
>
>
>
>    If the base URI of a registration contains a link-local address, the
>
>    RD MUST NOT show its links unless the lookup was made from the same
>
>    link.  The RD MUST NOT include zone identifiers in the resolved URIs.
>
>
>
> Same link as what?
>
>
>
> Section 6.2
>
>
>
>    The page and count parameters are used to obtain lookup results in
>
>    specified increments using pagination, where count specifies how many
>
>
>
> (We haven't introduced the page and count parameters yet.)
>
>
>
>    operator as in Section 4.1 of [RFC6690].  Attributes that are defined
>
>    as "link-type" match if the search value matches any of their values
>
>
>
> Where is it specified how an attribute might be "defined as
>
> 'link-type'"?  This is the only instance of the string "link-type" in
>
> this document, and it does not appear in RFC 6690 at all...
>
>
>
>    references) and are matched against a resolved link target.  Queries
>
>    for endpoints SHOULD be expressed in path-absolute form if possible
>
>    and MUST be expressed in URI form otherwise; the RD SHOULD recognize
>
>    either.  The "anchor" attribute is usable for resource lookups, and,
>
>    if queried, MUST be for in URI form as well.
>
>
>
> I don't see how it can be only a SHOULD to recognize either given these
>
> generation criteria.
>
>
>
> Section 6.3
>
>
>
>    The following example shows a client performing a lookup of all
>
>    resources of all endpoints of a given endpoint type.  It assumes that
>
>    two endpoints (with endpoint names "sensor1" and "sensor2") have
>
>    previously registered with their respective addresses
>
>    "coap://sensor1.example.com" and "coap://sensor2.example.com", and
>
>    posted the very payload of the 6th request of section 5 of [RFC6690].
>
>
>
> Er, the 6th request is a GET; do we mean to say the response to the 6th
>
> request?
>
>
>
> Section 6.4
>
>
>
>    The endpoint lookup returns registration resources which can only be
>
>    manipulated by the registering endpoint.
>
>
>
> This seems to leave it unclear whether the endpoint lookup is expected
>
> to return resources that the requestor will not have permission to
>
> manipulate (in addition to those it does have permission for).
>
>
>
>    While Endpoint Lookup does expose the registration resources, the RD
>
>    does not need to make them accessible to clients.  Clients SHOULD NOT
>
>    attempt to dereference or manipulate them.
>
>
>
> But why expose them at all if they're not going to be accessible?
>
>
>
>    An RD can report endpoints in lookup that are not hosted at the same
>
>    address.  [...]
>
>
>
> The "same address" as what?
>
>
>
> Section 7.1
>
>
>
>    Whenever an RD needs to provide trustworthy results to clients doing
>
>    endpoint lookup, or resource lookup with filtering on the endpoint
>
>
>
> How will the RD know whether the client is expecting trustworthy
>
> results?  (When would a client *not* expect trustworthy results?)
>
>
>
>    name, the RD must ensure that the registrant is authorized to use the
>
>    given endpoint name.  This applies both to registration and later to
>
>    operations on the registration resource.  It is immaterial there
>
>    whether the client is the registrant-ep itself or a CT is doing the
>
>    registration: The RD can not tell the difference, and CTs may use
>
>
>
> I suppose there might be plausible authorization models where a
>
> return-routability check to a given address constitutes authorization to
>
> use that address as an endpoint name, in which case the RD can tell the
>
> difference between a registrant-ep and a CT attempting to act on its
>
> behalf.
>
>
>
>    When certificates are used as authorization credentials, the
>
>    sector(s) and endpoint name(s) can be transported in the subject.  In
>
>    an ACE context, those are typically transported in a scope claim.
>
>
>
> As Russ noted in the Gen-ART review, "transported in the subject" is
>
> sufficiently vague to not really be actionable.  It might be better to
>
> say that the holder of the private key corresponding to the public key
>
> certified in the certificate is generally considered authorized to act
>
> on behalf of any identities (including endpoint names) contained in the
>
> certificate's subject name.
>
>
>
> Section 7.1.1
>
>
>
>    Conversely, in applications where the RD does not check the endpoint
>
>    name, the authorized registering endpoint can generate a random
>
>    number (or string) that identifies the endpoint.  The RD should then
>
>
>
> How much entropy/randomness in the random name?  Does a CSPRNG need to
>
> be used?  (I do see the follow-up about doubling the length in case of
>
> failure or starting with a UUID if that's not possible, but some
>
> guidance on where to start still seems appropriate.)
>
>
>
> Section 7.2
>
>
>
>    When lookup clients expect that certain types of links can only
>
>    originate from certain endpoints, then the RD needs to apply
>
>    filtering to the links an endpoint may register.
>
>
>
> As before, how will the RD know what behavior clients are relying on?
>
>
>
>    An RD may also require that only links are registered on whose anchor
>
>    (or even target) the RD recognizes as authoritative of.  One way to
>
>
>
> I don't think I can parse this sentence (especially "the RD recognizes
>
> as authoritative of").
>
>
>
> Section 8
>
>
>
> In contexts where we discuss DTLS and TLS as being generally comparable,
>
> we typically will state that DTLS replay protection is required in order
>
> to provide equivalent levels of protection.
>
>
>
> We might also want to reiterate or refer back to the previous discussion
>
> of the potential for attributes or resource/endpoint names, link
>
> relations, etc. that may need to be confidential, the relevant access
>
> control/filtering, and the avenues by which disclosure of resource names
>
> can occur even when access to those resources will not be permitted.  (I
>
> think some of this overlaps with 8288 and 6690, but don't mind repeating
>
> it.)
>
>
>
> Section 8.1
>
>
>
> It's probably worth reiterating that all name comparisons must be done
>
> at sector scope (since failing to do so can lead to attacks).
>
>
>
>    Endpoint authentication needs to be checked independently of whether
>
>    there are configured requirements on the credentials for a given
>
>    endpoint name (Section 7.1) or whether arbitrary names are accepted
>
>    (Section 7.1.1).
>
>
>
> I think this is more properly authorization than authentication.
>
>
>
> Section 8.3
>
>
>
>    attacks.  There is also a danger that NTP Servers could become
>
>    implicated in denial-of-service (DoS) attacks since they run on
>
>    unprotected UDP, there is no return routability check, and they can
>
>    have a large amplification factor.  The responses from the NTP server
>
>    were found to be 19 times larger than the request.  An RD which
>
>
>
> (It's not clear to me why the specific discussion of NTP numbers is
>
> relevant here, since RD is not NTP.)
>
>
>
> Section 9.3
>
>
>
> Should we also include "rt" in the initial entries?  I see it is used as
>
> a query parameter for resource lookup in the examples in Section 6.3.
>
>
>
>    *  indication of whether it can be passed as a query parameter at
>
>       registration of endpoints, as a query parameter in lookups, or be
>
>       expressed as a target attribute,
>
>
>
> (Since this text does not clarify about lookup of endpoints vs.
>
> resources...
>
>
>
>    Review" as described in [RFC8126].  The evaluation should consider
>
>    formal criteria, duplication of functionality (Is the new entry
>
>    redundant with an existing one?), topical suitability (E.g. is the
>
>    described property actually a property of the endpoint and not a
>
>    property of a particular resource, in which case it should go into
>
>    the payload of the registration and need not be registered?), and the
>
>
>
> .... and this text suggests that query parameters for *resource* lookups
>
> need not be registered.)
>
>
>
>    potential for conflict with commonly used target attributes (For
>
>    example, "if" could be used as a parameter for conditional
>
>    registration if it were not to be used in lookup or attributes, but
>
>    would make a bad parameter for lookup, because a resource lookup with
>
>    an "if" query parameter could ambiguously filter by the registered
>
>    endpoint property or the [RFC6690] target attribute).
>
>
>
> Then why do we use it as an example of lookup filtering in Section 6.2?
>
>
>
> Section 10.1.2
>
>
>
> Should we really be using unregistered resource types (i.e., codepoint
>
> squatting) in the examples?
>
>
>
>    After the filling of the RD by the CT, the application in the
>
>    luminaries can learn to which groups they belong, and enable their
>
>    interface for the multicast address.
>
>
>
> Just to check: the luminaries are learning their own group membership by
>
> querying the resource directory?
>
>
>
> Section 10.2.2
>
>
>
> Please expand MSISDN.
>
>
>
> Section 13.2
>
>
>
> I think RFC 7252 should probably be normative.
>
>
>
> Likewise for RFC 8288 ("the query parameter MUST be [...] a token as
>
> used in [RFC8288]").
>
>
>
>
>
>
>
>