Subject: [core] Benjamin Kaduk's No Objection on draft-ietf-core-resource-directory-26: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 10 Feb 2021 19:53:38 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-core-resource-directory-26: No Objection

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the updates in the -26; they help a lot.

I'm particularly happy to see the (default/example)
"first-come-first-remembered" policy in § 7.5, which does a good job of
documenting its properties (including potential deficiencies) and can be
usable for many environments.  (I do have some suggestions for
improvements to the specific wording in the section-by-section comments,
but on the whole I like it.)

It does lead in to a more general comment, though (which is not exactly
new to the changes in the -26 though it is reflected in several of
them): some aspects of the concept of "authorization" to appear in a
directory, and the verification of authorization for the entire flow
from client locating the RD server to final request at the discovered
resource, are somewhat subtle.  (The new text discusses, e.g., "repeat
the URI discovery step at the /.well-known/core resource of the
indicated host to obtain the resource type information from an
authorized source" and "a straightforward way to verify [discovered
information] is to request it again from an authorized server, typically
the one that hosts the target resource".)  The aspects I'm concerned
about are not matters of a resource server being authorized to publish
to a directory or a client deeming that a server is authorized to act as
an RD (though both of those are also important), but seems to rather
just be relating to the RD faithfully disseminating the information the
RD retrieved from /.well-known/core discovery on the given server(s)
(or otherwise learned via some other mechanism).
In this sense the RD is just acting as a cache or efficiency aid, but
the authoritative source of the information remains (in general) the
server hosting the resource.  To be clear, I think the procedures that
this document specifies are good and correct procedures for a client to
perform, I'm just not sure whether "authorized" is the right term in
these cases; "authoritative" might be more appropriate, in that the
operation in question is to verify the information retrieved from the RD
(which acts in some sense as an intermediary) at the more authoritative
source.

(On a tangent from that note, it seems that there is not necessarily any
indication to a client that a server claiming to provide a given
resource (whether discovered via RD or /.well-known/core) is actually
authorized to provide such a resource and be trusted by the client.  But
that's not really a property of RD, and rather the underlying CoRE
mechanism and any provisioned trust database, so my thoughts about it
seem out of scope for this document.)

Section 5.1

   URI Template Variables are as they are for registration in Section 5.
   The base attribute is not accepted to keep the registration interface
   simple; that rules out registration over CoAP-over-TCP or HTTP that
   would need to specify one.  For some time during this document's
   development, the URI template "/.well-known/core{?ep,...}" has been
   in use instead.

(It's not entirely clear to me what the reader is expected to do with
the information about the previous formulation.)

Section 7.3

   In this case, the endpoint (and not the lookup clients) needs to be
   careful to check the RD's authorization.

(It seems that something also needs to cause the RD to check the
authorization of lookup clients to receive the information in question,
which might be worth reiterating in this section.)

Section 7.5

   *  If the client's credentials indicate any subject name that is
      certified by any authority which the RD recognizes (which may be
      the system's trust anchor store), all those subject names are
      stored.  [...]

I'm pretty sure the intent here is that only the subject names that are
certified by the recognized authority(ies) are stored, in which case I'd
suggest to s/all those/all such/.

      With X.509 certificates, the Common Name (CN) and the complete
      list of SubjectAltName entries are stored.  In both cases, the
      authority that certified the claim is stored along with the
      subject, as the latter may only be locally unique.

(I can understand why the "store the whole list" logic is used, though
there may be some subtleties about name constraints on the (X.509) CAs
used, which is why we typically don't recomment treating the entire list
of names in the certificate as validated from a single operation,
instead preferring "is this certificate authenticated for this specific
name?" when the specific target name is available.)

   *  If neither is present, a reference to the security session itself
      is stored.  With (D)TLS, that is the connection itself, or the
      session resumption information if available.  With OSCORE, that is
      the security context.

Should we talk about whether the lifetime of registration entries is
related to the various lifetimes of these credentials/identifiers?  DTLS
without resumption is perhaps an interesting case, in that keeping the
DTLS association "live" just to be able to update the registration
information seems impractical, so perhaps some fixed cap would be
applied on the lifetime in that case.  If resumption is used, the
resumption information (ticket or session state) has some finite
lifetime that could be used to bound the lifetime of the registration.
IIRC an OSCORE security context can also have an expiration time;
certificates and JWT/CWT have expiration time as well (though the
procedures in the first bullet point would effectively allow a "renewal"
operation), but the validity period (if any) of a raw public key would
have to be provisioned along with that key (or just have RPK be handled
akin to DTLS without resumption, I guess).

   Any operation on a registration resource, including registrations
   that lead to an existing registration resource, MUST be rejected by
   the RD unless all the stored information is found in the new
   request's credentials.

(Similar to my earlier parenthetical comment, the requirement for exact
match of all subject name information is unusual.  In effect this is a
way of pinning the set of names that the CA has chosen to include in a
single certificate, which is arguably a stronger requirement than needed
but should not lead to any unauthorized access.)

---

From: Christian M. Amsüss <[email-masked]>
Date: Fri, 26 Feb 2021 16:32:25 +0100

Hello Ben,

thanks for the updates.

All but the last have, if any, editorial changes pending in the issue
tracker; on that certificates point I could use a short "yes that's what
I meant" or other suitable answer.

> [...], but seems to rather just be relating to the RD faithfully
> disseminating the information the RD retrieved from /.well-known/core
> discovery on the given server(s) (or otherwise learned via some other
> mechanism).

To get these fine points right I think I'd need an updated security
glossary and a generally more aligned CoRE terminology on authority and
information sources.

IMO the right place for this is the further discussion on how to do
better in the space between "trust the RD" and "ask again". The
continuing work on CoRAL at https://github.com/core-wg/coral/issues/59
is a starting point.

>    [...]  For some time during this document's development, the URI
>    template "/.well-known/core{?ep,...}" has been in use instead.
> 

New readers can take it as a curious historical note -- but even though
a rought survey indicated that all implementations are straightforward
to upgrade, we might have missed some that took this mechanism that sat
there stable for most of the lifetime of this document for stable and
deployed based on it. For those cases, this gives the RD operator who
finds themselves confused by such a POST the hint to find where things
went wrong.

> akin to DTLS without resumption, I guess).

For DTLS, I expect that this is either done with resumption in mind, or
on connections that are kept alive for other reasons (like the proxying
from resource-directory-extensions). When resumption is used, the finite
lifetime of the ticket does not give an automatic limit to the
permissible lifetime, for (AFAIK) a new ticket can be obtained.

If lifetime limits base on the authorization are, they should be applied
consistently not only to first-come-first-remembered, but also to other
time-limited authorizations and other circumstances (eg. RDs that only
take long-lived registrations from specially authorized registrants like
CTs). 

These are, in general, hard for the device to act on -- its choices are
to not be discoverable (which, in models like LwM2M makes them not even
available for reconfiguration) or to spend more resources for keepalives
than it is configured to (which we currently have no means to express;
core-problem-details would help here).

Under those considerations, I expect that the RD taking the registration
even with a longer-than-comfortable-or-realistic lifetime is usually the
best option and should thus be the generally expected way of operation.
Other modes can be explored as well, and I've taken this up in the
resource-directory-extensions collection (but can't promise that
anything will come of it).

> which might be worth reiterating in this section.)

Queued for updated text as "The RD (always, but especially here) then
needs to verify any lookup client's authorization before reveling this
information directly (in resource lookup) or indirectly (when using it
to satisfy a resource lookup search criterion)".

> suggest to s/all those/all such/.

Good point, queued up.

> [...]

Not sure I get this right -- would

    If the client's credentials indicate any subject name that is
    certified by any authority which the RD recognizes **for that name**
    (which may be the system's trust anchor store), all those subject
    names are stored." 

be a suitable resolution?

I'd prefer to stick with the possibly suboptimal but at any rate easy to
implement rule. I expect the typical RD to be coming more from a JWT /
CWT / ACE background and not so much from an X.509 one. (Of course that
may be just my personal angle speaking). "Match all" is hard to get
wrong, even if it may be a tad stricter than absolutely necessary.

If we can phrase the rule better in a concise form that is still easy to
understand for implementers, let's get this last point right --
other than that, there can still be documented variations on this
policy.

BR
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 27 Feb 2021 12:56:38 -0800

Hi Christian,

(inline)

> continuing work on CoRAL at https://github.com/core-wg/coral/issues/59

That seems like a fine place to have this discussion; the only thing I
might consider for this document is to use "authoritative" instead of
"authorized" in the couple places I indicated.  But I'll leave that up to
you, since you've thought about it more than I have...

> permissible lifetime, for (AFAIK) a new ticket can be obtained.

Yes.  I think my mental model was that the limit based on the ticket
lifetime would be provisional and could be extended if the ticket was used
to resume and a new ticket issued on the resumed session.

> anything will come of it).

Okay.  That's all I can ask for, and thanks for talking it through a bit
here.

> be a suitable resolution?

That might just be making things more complicated for minimal benefit (and
if it is used the s/those/such/ from an earlier comment would still be
needed).  Basically, what the current text is doing is saying that "we
trust this issuer at least sometimes, and will just lump everything they
named into a single conglomerate and treat that conglomerate as an opaque
thing that must match exactly in the future".  In that sense we don't
actually care which names the issuer put in or whether we trust the issuer
to be an authority for all those names -- the actual identifier is "the
stuff the CA put in the cert" and we only need it as an opaque identifier
like that.

> other than that, there can still be documented variations on this

I don't think we're really going to be able to do better than "match all"
here without a lot of complications.  The current "match all" is a little
constraining on the CA's operations, but it is simple, as you note.  So I
think my comment here is really just a comment, and not suggesting any
(additional) changes to this document at this time.  Maybe in the future
we'll have some better ideas...

Thanks,

Ben

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 27 Feb 2021 22:01:35 +0100

On 2021-02-27, at 21:56, Benjamin Kaduk <[email-masked]> wrote:
> 
> use "authoritative" instead of
> "authorized" in the couple places I indicated

Authoritative sounds like it is an intrinsic property of the source.
Authorized means that the specific policies that apply to the consumer authorize use of the source for the purpose at hand.
So I think this substitution should not occur lightly.

Grüße, Carsten

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 27 Feb 2021 13:37:59 -0800

> So I think this substitution should not occur lightly.

When the data in question is "what resources are available at this host", I
think authoritative is pretty intrinsically a property of the host itself :)

Now, if the question was "what resources are supposed to be at this host
that I'm allowed to use?", your considerations become quite relevant.

-Ben