Draft: draft-ietf-core-resource-directory

Commentary: This provides two band - aids to , and may also close it far enough that RD can progress without the underlying topic being solved in full . 
 This is a tracking issue to cover the topics of -- see there for discussion , the issue is primarily kept for cross - linking PRs . 
 Since this is covered well enough that it need not stop RD . Further exploration should happen in ACE and CoRE .
Mailing list commentary: Hello CoRE , one of the outstanding issues in RD is server authorization with respect to operations on particular paths . This continues an ACE thread[1 ] I regrettably missed to follow up on , but simplifies the examples based on the recent interims . While originally phrased as the attacker tricking the server into using the client 's good credentials for something the client did not intend , here they are phrased now in terms of server authorization as relevant for RD discovery and RD security policies . For two examples , a client needs to trust a server to provide a service , but has received misleading hints that cause disagreement between the client and the server about the performed operation . Example 1 = = = = = = = = = An RD with a " links are confidential " policy also operates a bulletin board at . During the unprotected discovery phase , the endpoint is fed a link . The client connects to , verifies that its server credentials are good for an RD that will reveal links posted to it only to authorized lookup clients . It then posts all its links to /bb , where anyone who knows to use a bulletin board can read them . Example 2 = = = = = = = = = A time server also exposes its current core temperature as . A malicious RD operator modifies the time server 's registration to read . A starting device in the network asks the RD for any rt = unixtime , verifies that is indeed authorized to give the right time , and wakes up on the morning of January 1st , 1970 . Problem summary = = = = = = = = = = = = = = = The client has an abstract intention with an operation , which it checks against the server 's authorization . Then it forms that intention , with additional unverified knowledge about the server , into a request , which it protects . The server then reconstructs that intention with its authoritative knowledge of itself , and uses any client provided credentials to act on it . If the client 's knowledge about the server is erroneous , the intentions are misaligned . Neither is the intention protected , nor does the client point out the claims it wants to hold the server to in its request ( or , in the original examples from the ACE thread , express the precise claims about itself it intends the server to assess ) . Solution approaches = = = = = = = = = = = = = = = = = = = In the ACE thread back then , said that he 'd expect the client to use different keys ( originally in talking to the AS , and thus different keys in talking to the RS ) . Doing that to the end would probably result in the devices having to handle a lot more keys , something like one for any operation that could be mixed up with any other ? in the last interim mentioned that in OAuth it 's common to only run one service on one host for the very same reason . Kind of boils down to the same thing , as virtual - hosting these services would create multiple keys . My approach in the -25 RD Section 7.2 is to ( losely , there ; would need stronger and more precise wording ) say that any information that any information using which intention is encoded in the request in a lossy way is to be rechecked from the origin server . That 'd be more or less straightforward for example 1 , but incur an additional costly recheck with the origin server about many things that could be learned efficiently from the RD . Does any of that solve the issues ? Can we do any better ? How do we put that into RD to satisfy the small comment about Section 7.2 that opens this can of worms ? Is there anything quotable on OAuth 's best practices on multiple services on the same host ? Best regards Christian [ 1 ] :
Paragraph (version B):
With security policies where the client requires the RD to be
authorized to act as an RD, that authorization may be limited to
resources on which the authorized RD advertises the adequate resource
types.  Clients that have obtained links they can not rely on yet can
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.
Paragraph (version A):
As above, the impact of undesirable links depends on the extent to
which the lookup client relies on the RD.  To avoid the limitations,
RD applications should consider prescribing that lookup clients only
use the discovered information as hints, and describe which pieces of
information need to be verified with the server because they impact
the application's security.
Paragraph (version B):
As above, the impact of undesirable links depends on the extent to
which the lookup client relies on the RD.  To avoid the limitations,
RD applications should consider prescribing that lookup clients only
use the discovered information as hints, and describe which pieces of
information need to be verified because they impact the application's
security.  A straightforward way to verify such information is to
request it again from an authorized server, typically the one that
hosts the target resource.  That similar to what happens in discovery
when the URI discovery step is repeated.