Subject: [Sandbox-mailoutput] [Django development] ID list for Constrained RESTful Environments notification: Changes to draft-ietf-core-resource-directory

From: IETF Secretariat <[email-masked]>
Date: Thu, 13 Aug 2020 03:25:58 -0700

The attached message would have been sent, but the tracker is in development mode.
It was not sent to anybody.

Subject: ID list for Constrained RESTful Environments notification: Changes to draft-ietf-core-resource-directory
From: IETF Secretariat <[email-masked]>
To: <[email-masked]>
Date: Thu, 13 Aug 2020 03:25:58 -0700

Hello,

This is a notification from the ID list for Constrained RESTful Environments.

Document: draft-ietf-core-resource-directory,
https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/

Change by Roman Danyliw on 2020-08-13 03:25 PDT:

[Ballot discuss]
There appear to be a few areas of straightforward, under-specified elements of the authorization model. 

-- How does the RD know that a node claiming to be a CT is in fact a CT and is permitted to register on behalf of end-points?  It seems like there is a missing, simple statement to make that this is configured out of band with the RD?  Or is that carrier somehow in a authentication credentials?	

-- Is there are reason why there is not normative guidance requiring the RD to check whether authentication clients are authorized to register particular resources?  Section 7.1 covers the issue, but all of Section 7.* is explicitly noted as informative.  Section 8.1. says “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)” but this text seems to frame it as authentication issue.  Section 8.2 seems to stress only the distinction between the registration and lookup API.

-- Section 8.1.  Per “If the server does not check whether the identifier provided in the DTLS handshake matches the identifier used at the CoAP layer then it may be inclined to use the endpoint name for looking up what information to provision to the malicious device.”, this is good advice.  If DTLS PSK and RPK are used, what identifiers does the RD have to check to ensure the DTLS and CoAP layers match?  Per 9.1.3.1. (for PSK) and 9.1.3.2.1 (for RPK) of RFC7252 there is the notion of identifiers for DTLS but those don’t manifest in CoAP?  Additionally, when DTLS with a certificate is used, is it intended to compare the subjectAltName with the authority in the Registration Base URI (i.e., which exact certificate fields should it compare with the CoAP)?

Best regards,

        The Datatracker draft tracking service
        (for the IETF Secretariat)