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

["Christian M. Amsüss" <[e-mail]>]

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).
> 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.

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.
> 
> (It's not entirely clear to me what the reader is expected to do with
> the information about the previous formulation.)

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.

>    *  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).

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).

> 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.)

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)".

> 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/.

Good point, queued up.

>       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.)
>
> [...]
>
> (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.)

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