Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft

[Peter van der Stok <[e-mail]>]

HI Hannes, Matthias,

After some additional discussions, I think it is best to write an extra
section into the resource-directory draft.
Please have a look at my suggestion below.

@Hannes, can you comment on the correctness and sufficiency of the text?
thanks,

Peter

________________________________________________________
Ietf-core-resource-directory text proposal. 

Suggestion to add a new section x on Authorization. 

Section x, use of Authorization Server. 

When threats may occur as described in section 8.1, an Authorization
Server (AS) as specified in ietf-ace-oauth-authz SHOULD be used. A
request to the Resource Directory is accompanied by an Access Token that
validates the access of the client to the RD. The URI of an authorized
request cannot contain the ep= or the d= parameters. When these
parameters are present, the request is rejected with CoAP response code
4.00 (bad request). The identifier part of the security context in the
Access Token is used to assign a value to the endpoint name of the
endpoint to be registered. Three possibilities are supported: 

 	* For PSK-based credential, the Endpoint Name becomes the PSK Identity
 	* For raw-public keys, the Endpoint Name becomes the
SubjectPublicKeyInfo structure (or a hash of it).
 	* For certificates, the Endpoint Name becomes the leftmost CN
component of subject name or the SubjectAltName of the certificate,
depending on what is used.

An access token MAY include one of the two following new claims: 

"epn" endpoint name with value the identifier part of one of the 3
possible identifier parts of the security ccontext. 

"dnm" domain name with value "name of the domain" 

Three scenarios for registration in the RD MUS be supported. 

Section x.1 endpoint registers with RD 

The endpoints sends a Request to the RD accompanied by a CBOR Web Token
(CWT). The identifier part of the security context is used to assign the
endpoint name. 

Section x.2 3rd party Commissioning Tool (CT) registers endpoint with
RD. 

The CT sends a Request to the RD accompanied by a CBOR Web Token (CWT).
The identifier part of the CWT refers to the security context of the CT.
The CWT validates the registration by the CT. The CWT MUST contain the
"epn" claim to assign a value to the endpoint that is registered. The
CWT MAY contain the "dnm" claim to assign a domain name. 

Section x.3 Updating multiple links 

Section 5.4.4 of RD specifies that multiple links can be updated with a
media format to be specified. The updating endpoint sends a Request to
the RD accompanied by a CBOR Web Token (CWT). The identifier part of the
CWT refers to the security context of the updating endpoint. The
updating endpoint is authorized to change all links of all existing
registrations but MUST NOT delete or add registrations. 

IANA regsitration.

Two new parameters need to be registered in the OAuth Parameter
Registration with names ""epn" and "dnm". The last paragraph in section
8.1 is to be replaced:
OLD
"Therefore, Endpoints MUST include the
Endpoint identifier in the message, and this identifier
MUST be checked by a resource directory to match the Endpoint identifier
included in the Registration message."
NEW
"Therefore, Endpoints SHOULD follow the guidelines of section x."