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

[Jim Schaad <[e-mail]>]

A couple of fast comments below

 

Jim

 

 

From: core <[e-mail]> On Behalf Of Peter van der Stok
Sent: Monday, June 18, 2018 2:53 AM
To: [e-mail]
Cc: Hannes Tschofenig <[e-mail]>; [e-mail]
Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft

 

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 

[JLS] s/as specified/like the one specified/

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:

1.	For PSK-based credential, the Endpoint Name becomes the PSK Identity

[JLS] PSK identities are binary and not text strings so a mapping is going to be needed here as with RPKs.

2.	For raw-public keys, the Endpoint Name becomes the SubjectPublicKeyInfo structure (or a hash of it).
3.	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.

[JLS] Why not use the ‘normal’ subject name? Would you think that they are the same or different?

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