OCF 2.0 Clarify 10 parts on Section 7 SecWG CR2473. Legal Disclaimer

Transcription

1 Template version: 1.0 page 1 OCF 2.0 Clarify 10 parts on Section 7 SecWG CR2473 Legal Disclaimer THIS IS A DRAFT SPECIFICATION DOCUMENT ONLY AND HAS NOT BEEN ADOPTED BY THE OPEN CONNECTIVITY FOUNDATION. THIS DRAFT DOCUMENT MAY NOT BE RELIED UPON FOR ANY PURPOSE OTHER THAN REVIEW OF THE CURRENT STATE OF THE DEVELOPMENT OF THIS DRAFT DOCUMENT. THE OPEN CONNECTIVITY FOUNDATION AND ITS MEMBERS RESERVE THE RIGHT WITHOUT NOTICE TO YOU TO CHANGE ANY OR ALL PORTIONS HEREOF, DELETE PORTIONS HEREOF, MAKE ADDITIONS HERETO, DISCARD THIS DRAFT DOCUMENT IN ITS ENTIRETY OR OTHERWISE MODIFY THIS DRAFT DOCUMENT AT ANY TIME. YOU SHOULD NOT AND MAY NOT RELY UPON THIS DRAFT DOCUMENT IN ANY WAY, INCLUDING BUT NOT LIMITED TO THE DEVELOPMENT OF ANY PRODUCTS OR SERVICES. IMPLEMENTATION OF THIS DRAFT DOCUMENT IS DONE AT YOUR OWN RISK AMEND AND IT IS NOT SUBJECT TO ANY LICENSING GRANTS OR COMMITMENTS UNDER THE OPEN CONNECTIVITY FOUNDATION INTELLECTUAL PROPERTY RIGHTS POLICY OR OTHERWISE. IN CONSIDERATION OF THE OPEN CONNECTIVITY FOUNDATION GRANTING YOU ACCESS TO THIS DRAFT DOCUMENT, YOU DO HEREBY WAIVE ANY AND ALL CLAIMS ASSOCIATED HEREWITH INCLUDING BUT NOT LIMITED TO THOSE CLAIMS DISCUSSED BELOW, AS WELL AS CLAIMS OF DETRIMENTAL RELIANCE. The OCF logo is a trademark of Open Connectivity Foundation, Inc. in the United States or other countries. *Other names and brands may be claimed as the property of others. Copyright 2018 Open Connectivity Foundation, Inc. All rights reserved. Copying or other form of reproduction and/or distribution of these works are strictly prohibited.

2 Template version: 1.0 page 2 ****** Paste the Change Request content here ****** **Change 1: ** 3.2 Acronyms a nd Abbreviations OC Owner Credential OCSP Online Certificate Status Protocol OBT Onboarding Tool OCF See section , OCF Core Specification. OID Object Identifier OTM Owner Transfer Method OWASP Open Web Application Security Project. See OOB out-of-band 7. Se curity Provisioning **Change 2: ** Device Identity for Devices with UAID Table 1 Acronyms and abbreviations For identifying and protecting Devices, the Platform Secure Execution Environment (SEE) may opt to generate new Dynamic Public Key Pair (DPKP) for each Device it is hosting, or it may opt to simply use the same public key credentials embedded by manufacturer; Embedded Platform Credential (EPC). In either case, the Platform SEE will use its Random Number Generator (RNG) to create a device identity called UAID for each Device. The UAID is generated using either EPC only or the combination of DPKP and EPC if both are available. When both are available, the Platform shall use both key pairs to generate the UAID as described in this section. The Device ID is formed from the device s public keys and associated OCF Cipher Suite. The Device ID is formed by: 3) From DPKP, extract the value of the public key. The value should correspond to the v alue o f subjectpublickey defined in SubjectPublicKeyInfo. In the following we refer to this as DPK Validation of UAID To be able to use the newly generated Device ID (UAID) and public key pair (DPKP), the device Platform shall use the embedded private key (corresponding to manufacturer embedded public key and certificate) to sign a token vouching for the fact that it (the Platform) has in fact generated the DPKP and UAID and thus deferring the liability of the use of the DPKP to the new device owner. This also allows the ecosystem to extend the trust from manufacturer certificate to a device issued certificate for use in the new DPKP and UAID. The degree of trust is in dependent of the level of hardening of the device SEE. Dev_Token=Info, Signature(hash(info)) Signature algorithm=ecdsa (can be same algorithm as that in EPC or that possible for DPKP) Hash algorithm=sha256 Info=UAID <Platform ID> UAID_generation_data validity

3 Template version: 1.0 page 3 UAID_generation_data=data passed to the hash algorithm used to generate UAID. Validity=validity period in days (how long the token will be valid) **Change 3: ** 7.2 De vice Ownership This is an informative section. Devices are logical entities that are security endpoints that have an identity that is authenticable using cryptographic credentials. A Device is un-owned when it is first initialized. Establishing device ownership is a process by which the device asserts its identity to an OBT and the OBT asserts its identity to the device. This exchange results in the device changing its ownership state, thereby preventing a different OBT from asserting administrative control over the device. **Change 4: ** 7.3 De vice Ownership Transfer Methods SharedKey Credential Calculation - M essage is a concatenation of the following: Dox mtype string for the current onboarding method (e.g. "oic.sec.doxm.jw ") See "Section OCF defined OTMs for specific DoxmTypes" O w ner ID is a UUID identifying the device owner identifier and the device that maintains Share dkey. Use raw bytes as specified in RFC4122 section Device ID is new device s UUID Device ID **Change 5: ** Use raw bytes as specified in RFC4122 section Certificate Credential Generation All OTMs included in this document are considered optional. Each vendor is required to choose and implement at least one of the OTMs specified in this specification. The OCF, does however, anticipate vendor-specific approaches will ex ist. Should the vendor wish to have interoperability between a vendor-specific OTM and OBTs from other vendors, the vendor must work directly with OBT vendors to ensure interoperability. Notwithstanding, standardization of OTMs is the preferred approach. In such cases, a set of guidelines is provided below to help vendors in designing vendor-specific OTMs. (See Section 7.3.7).

4 Template version: 1.0 page 4 **Change 6: ** Esta blishing Owner Credentials Once the OBT and the new Device have authenticated and established an encrypted connection using one of the defined OTM methods. Owner credentials may consist of certificates signed by the OBT or other authority, user network access information, provisioning functions, shared keys, or Kerberos tickets. The OBT might then provision the new Device with additional credentials for Device management and Device-to-Device communications. These credentials may consist of certificates with signatures, UAID based on the Device public key, PSK, etc. The steps for establishing Device's owner credentials (OC) are detailed below: 1) The OBT shall establish the Device ID and Device owner uuid - Figure 19 2) The OBT then establishes Device s OC - Figure 20. This can be either: a) Sym metric credential - Figure 21 b) Asymmetric credential - Figure 22 3) Configure Device services - Figure 23 4) Configure Device for peer to peer interaction - Figure 24 Figure 1 - Asymmetric Owner Credential Provisioning Sequence

5 Template version: 1.0 page 5 Figure 2 - Configure Device Services

6 Template version: 1.0 page 6 Figure 3 - Provision New Device for Peer to Peer Interaction Sequence

7 Template version: 1.0 page 7 **Change 7: ** 13.7 Provisioning Status Resource Property Title Propert y Name Value Type Value Rule Mand atory Access Mode Device State Description Current Mode cm oic.sec.dpmtype bitmask Yes R RESET Serv er shall set to 0000,0001 RW RFOTM Should be set by DOXS after successful OTM to 00xx,xx10. RW RW R RFPRO RFNOP Set by CMS, AMS, DOXS after successful authentication Set by CMS, AMS, DOXS after successful authentication SRESET Serv er shall set to XXXX,XX01 Table 2 Properties of the oic.r.pstat Resource

8 Template version: 1.0 page 8 **Change 8: ** 7.4 Provisioning Provisioning Flows Client-directed Provisioning Figure 4 Example of Client-directed provisioning

9 Template version: 1.0 page 9 Step Description 1 Discover Devices that are owned and support Client-directed provisioning. 2 The /oic/sec/doxm Resource identifies the Device and its owned status. 3 Provisioning Tool(PT) obtains the new Device s provisioning status found in /oic/sec/pstat Resource 4 The pstat Resource describes the types of provisioning m odes supported and which is currently configured. A Device m anufacturer should set a default current operational mode (om ). If the O m isn t configured for Client-directed provisioning, its om value can be changed. Change state to Ready-for-Provisioning. cm is set to provision credentials. 5-6 PT instantiates the /oic/sec/cred Resource. It contains credentials for the provisioned services and other Devices 7-8 cm is set to provision ACLs PT instantiates /oic/sec/acl Resources. 11 The new Device provisioning status mode is updated to reflect that ACLs have been configured. (Ready-for-Normal-Operation state) 12 The secure session is closed. Table 3 Ste ps describing Client -directed provisioning **Change 9: **

10 Template version: 1.0 page Server-directed Provisioning Figure 5 Example of Server-directed provisioning using a single provisioning service

11 Template version: 1.0 page 11 Step Description 1 The new Device verifies it is owned. 2 The new Device verifies it is in self-provisioning mode. 3 The new Device verifies its target provisioning state is fully provisioned. 4 The new Device verifies its current provisioning state requires provisioning. 5 The new Device initiates a secure session with the provisioning tool using the /oic/sec/doxm. DevO wner value to open a TLS connection using SharedKey. 6 The new Device updates Cm to reflect provisioning of security services. 7-8 The new Devices gets the /oic/sec/cred Resources. It contains credentials for the provisioned services and other Devices. 9 The new Device updates Cm to reflect provisioning of credential Resources The new Device gets the /oic/sec/acl Resources. 12 The new Device updates Cm to reflect provisioning of ACL Resources. 13 The secure session is closed. Table 4 Steps for Server-directed provisioning using a single provisioning service

12 Template version: 1.0 page 12 **Change 10: **

13 Template version: 1.0 page Se rver-directed Provisioning Involving Multiple Support Services Figure 6 Example of Server-directed provisioning involving multiple support services

14 Template version: 1.0 page 14 Step Description 1 The new Device verifies it is owned. 2 The new Device verifies it is in self-provisioning mode. 3 The new Device verifies its target provisioning state is fully provisioned. 4 The new Device verifies its current provisioning state requires provisioning. 5 The new Device initiates a secure session with the provisioning tool using the /oic/sec/doxm. DevO wner value to open a TLS connection using SharedKey. 6-7 The new Device gets credentials Resource for the provisioned services and other Devices 8 The new Device updates Cm to reflect provisioning of support services. 9 The new Device closes the DTLS session with the provisioning tool. 10 The new Device finds the CMS from the /oic/sec/cred Resource, rowneruuid Property and opens a DTLS connection. The new device finds the credential to use from the /oic/sec/cred Resource The new Device requests additional credentials that are needed for interaction with other devices. 13 The new Device updates Cm to reflect provisioning of credential Resources. 14 The DTLS connection is closed. 15 The new Device finds the ACL provisioning and management service from the /oic/sec/acl2 Resource, rowneruuid Property and opens a DTLS connection. The new device finds the ACL to use from the /oic/sec/acl2 Resource The new Device gets ACL Resources that it will use to enforce access to local Resources The new Device should get SACL Resources immediately or in response to a subsequent Device Resource request The new Device should also get a list of Resources that should consult an Access Manager for m aking the access control decision. 22 The new Device updates Cm to reflect provisioning of ACL Resources. 23 The DTLS connection is closed. Table 5 Steps for Server-directed provisioning involving multiple support services