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

From: peter van der Stok <[email-masked]>
Date: Fri, 01 Jun 2018 09:22:54 +0200

Hi Hannes, Matthias,

Below a proposal for the security considerations section in the RD draft

the last paragraph:
"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."

to be replaced with:
"A client MUST obtain an access token from an authorization server 
[draft-ietf-ace-oauth-authz]. For most installations the name of the 
endpoint does not need to be semantically meaningful. For those 
installations the endpoint name MUST be equated to the security 
identifier transported in the access token. For installations where the 
endpoint name must reflect the names of components of the installation, 
the access token MUST contain the values of the endpoint name and the 
optional domain name. A companion document SHOULD describe the format of 
the access tokens, the negotiation between client and Authorization 
server, and the treatment of the token by the RD server."

Will that be sufficient for you; or do you want more detailed text like 
yours below?
Looking forward to your improvements,

thanks,

peter

Hannes Tschofenig schreef op 2018-05-15 10:15:
> @Hannes: Could you provide some more detail, how exactly the Endpoint
> Client Name is extracted from "security context"? Overall, I like
> this, but we should provide concrete text on how people should do it.
> 
> You want to store the security context on the server side and the
> Endpoint Client Name points to the identifier part of it.
> (Other parts of the security context will be relevant for other 
> purposes.)
> 
>  * For PSK-based credential the Endpoint Client Name becomes the PSK 
> Identity
>  * For raw-public keys the Endpoint Client Name becomes the
> SubjectPublicKeyInfo structure (or a hash of it).
>  * For certificates the Endpoint Client Name becomes the leftmost CN
> component of subject name or the SubjectAltName of the certificate,
> depending on what you use.
> 
> Ciao
> Hannes
> 
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.

---

From: Mert Ocak <[email-masked]>
Date: Wed, 6 Jun 2018 14:06:35 +0000

Hi,

Confirming the endpoint name with the security context sounds reasonable but introducing a MUST for an authorization server is quite a big change, which I think we should avoid. ACE-Oauth could be one of the ways the RD supports for endpoint authentication but we should not invalidate other options the RD in different use cases can use for authentication, such as PSK, RPK or Certificates as Hannes mentioned.

Cheers,
Mert

On 01/06/2018, 10.23, "core on behalf of peter van der Stok" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Hannes, Matthias,

    the last paragraph:
    
    to be replaced with:

    thanks,
    
    peter
    
    > copy the information in any medium. Thank you.
    
    _______________________________________________
    core mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/core

---

From: Peter van der Stok <[email-masked]>
Date: Mon, 18 Jun 2018 11:52:34 +0200

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

---

From: Jim Schaad <[email-masked]>
Date: Mon, 18 Jun 2018 05:28:06 -0700

A couple of fast comments below

Jim

From: core <[email-masked]> On Behalf Of Peter van der Stok
Sent: Monday, June 18, 2018 2:53 AM
To: [email-masked]
Cc: Hannes Tschofenig <[email-masked]>; [email-masked]
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

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.

“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”

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

---

From: Peter van der Stok <[email-masked]>
Date: Fri, 22 Jun 2018 12:06:47 +0200

H JIm,

thanks, see below for fast questions

Peter
Jim Schaad schreef op 2018-06-18 14:28:

> to assign a value to the endpoint name of the endpoint to be registered. Three possibilities are supported: 
> 
> FROM: core <[email-masked]> ON BEHALF OF Peter van der Stok
> SENT: Monday, June 18, 2018 2:53 AM
> TO: [email-masked]
> CC: Hannes Tschofenig <[email-masked]>; [email-masked]
> SUBJECT: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft 
> 
> <pvds> I understand, Is there a standard way to do so? otherwise, a BSD64 representation of the RPK or PSK key is all-right? </pvds>
> 
> * 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.
> 
> "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? 
> 
> <pvds> I seem to miss this. the intention is to provide the same  three epn identifiers (RPK, PSK, certificate) for the three cases:
> - ep registers itself,
> - 3rd party registers ep,
> - multiple registries , links are changed.
> </pvds>

---

From: Jim Schaad <[email-masked]>
Date: Fri, 22 Jun 2018 07:56:42 -0700

Given that the ‘sub’ claim is a binary value (for CWT), if you don’t need to make a distinction on what the subject name was derived from then you could just use that rather than defining a new ‘epn’ claim.

From: Peter van der Stok <[email-masked]> 
Sent: Friday, June 22, 2018 3:07 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; 'Hannes Tschofenig' <[email-masked]>; [email-masked]
Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft

H JIm,

Peter

Jim

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

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