Re: [dev] SaveOwnerPSK - Bug or Intentional

Oleksiy Volkov Fri, 02 Mar 2018 07:44:12 -0800

Hi Ravee,

Looks like current implementation of provisioning client doesn't check doxm.sct value from server and use PSK credential type by default.

Best regards,

Aleksey Volkov

--------- Original Message ---------

Sender : Raveendranath Kondrakunta <raveendranath.kondraku...@gmail.com>

Date : 2018-03-02 17:05 (GMT+2)

Title : Re: [dev] SaveOwnerPSK - Bug or Intentional

Apologies Nathan, for dragging the topic.

As part of the onboarding procedure, once the devowneruuid of New Device is updated with OBT deviceuuid, the next step is Owner Credential provisioning.

The current stack implementation, does install the Owner PSK, which is fine. But aren't we supposed to check the "sct" property of doxm and install the new Credential, based on the "sct" property?. Let's say, if "sct" is only set to "Certificate type", we are still getting a PSK..

-Ravee

On Thu, Mar 1, 2018 at 9:57 PM, Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com> wrote:

Hi Ravee,

If I’ve understood your question, I think your intuition is correct: the Server should normally be just a “dumb endpoint” directed by the OBT as much as possible. But in the case of a mutually calculated symmetric key, the key generation function is run at the same time (during the calculate PSK step of onboarding) on the OBT and on the Server… this PSK isn’t transmitted over the wire, it’s calculated locally by both ends. So in this case it is indeed the Server that saves the actual PSK (the /cred entry’s “privatedata”), while the OBT is responsible for updating the /cred Properties outside of the “privatedata”.

Hope that addresses your question,

Thanks,
Nathan

From: Raveendranath Kondrakunta [mailto:raveendranath.kondraku...@gmail.com]
Sent: Thursday, March 1, 2018 2:19 AM
To: Heldt-Sheller, Nathan <nathan.heldt-sheller@intel.com>
Cc: Nash, George <george.n...@intel.com>; a.vol...@samsung.com; iotivity-dev@lists.iotivity.org

Subject: Re: [dev] SaveOwnerPSK - Bug or Intentional
Hi Nathan,

On re-reading the spec, I understand that the Owner Credential(OC) should be provisioned by the OBT(i.e., DOXS). Do we really need to provision the OC from the stack? Shouldn't this SaveOwnerPSK and PostOwnerCredential calls in OwnerUuidUpdateHandler be moved into the Provisioning Client, ideally?

-Ravee
On Thu, Mar 1, 2018 at 12:38 AM, Heldt-Sheller, Nathan <nathan.heldt-sheller@intel.com> wrote:
I’ve created a JIRA ticket and assigned to Aleksey: https://jira.iotivity.org/browse/IOT-3001

However (admittedly not having had much time to look at it yet) this is actually a provisioningclient example app bug, I think. The rowneruuid of the /cred Resource should be explicitly set by the OBT (e.g. provisioningclient), *not* implicitly set as part of calculating the PSK (e.g. by the Server).

The provisioningclient app and related APIs are not technically part of the certified stack (they are example app code to be replaced by vendor OBT) and so I’m not sure how critical it is, especially since we expect vendor OBTs will use the forthcoming OBT from Dekra. Still, it probably makes sense to pick this change to 1.3.1, just in case it’s referenced by a vendor somewhere, but I’ll let Aleksey recommend.

Aleksey, please see the JIRA ticket above and add your comments.

Thanks,
Nathan

From: Nash, George
Sent: Wednesday, February 28, 2018 10:33 AM
To: a.vol...@samsung.com; Raveendranath Kondrakunta <raveendranath.kondrakunta@gmail.com>; Heldt-Sheller, Nathan <nathan.heldt-sheller@intel.com>
Cc: iotivity-dev@lists.iotivity.org
Subject: RE: [dev] SaveOwnerPSK - Bug or Intentional
Should we create a Jira ticket for this issue so it can be tracked?

Also Ravee reported the issue for 1.3.1 should we check the fix into the 1.3 branch?

George Nash

From: iotivity-dev-bounces@lists.iotivity.org [mailto:iotivity-dev-bounces@lists.iotivity.org] On Behalf Of Oleksiy Volkov
Sent: Wednesday, February 28, 2018 5:06 AM
To: Raveendranath Kondrakunta <raveendranath.kondrakunta@gmail.com>; Heldt-Sheller, Nathan <nathan.heldt-sheller@intel.com>
Cc: iotivity-dev@lists.iotivity.org
Subject: Re: [dev] SaveOwnerPSK - Bug or Intentional

Hi Ravee,

you are right, this is a bug.

I prepared a fix: https://gerrit.iotivity.org/gerrit/#/c/24239/, you can use it for your tests.

Best regards,

Aleksey Volkov

--------- Original Message ---------

Sender : Raveendranath Kondrakunta <raveendranath.kondraku...@gmail.com>

Date : 2018-02-28 11:22 (GMT+2)

Title : Re: [dev] SaveOwnerPSK - Bug or Intentional
Hi Nathan,

Sorry, I've a typo in the earlier mail.

In the persistent store(oic_svr_db_server.dat and oic_svr_db_client.dat) rowneruuid of the Owner Credential (OC) stored as nil uuid.

Test setup

Using release 1.3.1
Created my svr db files(both client and server) with initial values suitable for OTM. The content of db is attached. Please note that, no credential resources defined in db.

Since, there is not Cred Resource in the db and also "GetCredDefault() in credresource.c is not defined yet, gRownerId is set to Nil UUID, as per InitCredResource definition.

OTM successful, and SaveOwnerPSK called, followed by PostOwnerCredential

SaveOwnerPSK, while saving cred to local db uses gRownerID, which is nil uuid
PostOwnerCredential, doesn't post rowner at all

These are my observations.
-Ravee
On Tue, Feb 27, 2018 at 10:26 PM, Heldt-Sheller, Nathan <nathan.heldt-sheller@intel.com> wrote:
Hi Ravee,

The MULTIPLE_OWNER support is a vendor-defined feature (meaning, not in OCF Specifications), so the M_O behavior may not be clear if you’re reading the Specifications and looking at the M_O code.

However with M_O compiled out, what you are seeing looks correct: after completing the JustWorks OTM, the /cred Resource should have rowneruuid = <OBT UUID>, which should not be the Nil UUID (all zeroes). Can you explain if there is an issue/concern? Or are you just confirming what you see is expected?

Thanks,
Nathan

From: iotivity-dev-bounces@lists.iotivity.org [mailto:iotivity-dev-bounces@lists.iotivity.org] On Behalf Of Raveendranath Kondrakunta
Sent: Tuesday, February 27, 2018 8:31 AM
To: a.vol...@samsung.com
Cc: iotivity-dev@lists.iotivity.org
Subject: Re: [dev] SaveOwnerPSK - Bug or Intentional
Thanks Aleksey.

Yes, from the Cred data structure, for MULTIPLE_OWNER scenario, there is eownerID. How is it expected to behave, if the stack is not built for MULTIPLE_OWNER support.

I've built the stack without MULTIPLE_OWNER support.

Completed Ownership transfer, using just works
OBT is trying to install Owner Credential(OC) using SaveOwnerPSK
The persistent store(oic_svr_db_server.dat and oic_svr_db_client.dat) have Owner Credential (OC) stored in them without rowneruuid all zeros.

-Ravee
On Tue, Feb 27, 2018 at 8:54 PM, Oleksiy Volkov <a.vol...@samsung.com> wrote:
Hi Raveendranath,

This isn't ownerid, this is eownerID for MULTIPLE_OWNER scenario.

Best regards,

Aleksey Volkov

--------- Original Message ---------

Sender : Raveendranath Kondrakunta <raveendranath.kondraku...@gmail.com>

Date : 2018-02-27 17:14 (GMT+2)

Title : [dev] SaveOwnerPSK - Bug or Intentional

Hi,

While reading through the ownership transfer code, I came across this SaveOwnerPSK function.

This was generating a Symmetric pair wise key. The ownerid of the credential is set NULL, meaning that rowneruuid is all zeros. Is this intentional or a bug?

802 static OCStackResult SaveOwnerPSK(OCProvisionDev_t *selectedDeviceInfo)

803 {

804     OIC_LOG(DEBUG, TAG, "IN SaveOwnerPSK");

805

806     OCStackResult res = OC_STACK_ERROR;

807

808     CAEndpoint_t endpoint;

809     CopyDevAddrToEndpoint(&selectedDeviceInfo->endpoint, &endpoint);

810     endpoint.port = getSecurePort(selectedDeviceInfo);

811

812     OicUuid_t ownerDeviceID = {.id={0}};

813     if (OC_STACK_OK != GetDoxmDeviceID(&ownerDeviceID))

814     {

815         OIC_LOG(ERROR, TAG, "Error while retrieving Owner's device ID");

816         return res;

817     }

818

819     OicSecKey_t ownerKey;

820     memset(&ownerKey, 0, sizeof(ownerKey));

821

822     uint8_t ownerPSK[OWNER_PSK_LENGTH_128] = { 0 };

823     ownerKey.data = ownerPSK;

824     ownerKey.len = OWNER_PSK_LENGTH_128;

825     ownerKey.encoding = OIC_ENCODING_RAW;

826

827     //Generating OwnerPSK

828     CAResult_t pskRet = CAGenerateOwnerPSK(&endpoint,

829             (uint8_t *)GetOxmString(selectedDeviceInfo->doxm->oxmSel),

830             strlen(GetOxmString(selectedDeviceInfo->doxm->oxmSel)),

831             ownerDeviceID.id, sizeof(ownerDeviceID.id),

832             selectedDeviceInfo->doxm->deviceID.id, sizeof(selectedDeviceInfo->doxm->deviceID.id),

833             ownerPSK, OWNER_PSK_LENGTH_128);

834

835     if (CA_STATUS_OK == pskRet)

836     {

837         OIC_LOG(DEBUG, TAG,"Owner PSK dump:\n");

838         OIC_LOG_BUFFER(DEBUG, TAG,ownerPSK, OWNER_PSK_LENGTH_128);

839         //Generating new credential for provisioning tool

840         OicSecCred_t *cred = GenerateCredential(&selectedDeviceInfo->doxm->deviceID,

841                                   SYMMETRIC_PAIR_WISE_KEY, NULL,

842                                   &ownerKey, NULL);

-Ravee
_______________________________________________
iotivity-dev mailing list
iotivity-dev@lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev

_______________________________________________
iotivity-dev mailing list
iotivity-dev@lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev

Re: [dev] SaveOwnerPSK - Bug or Intentional

Reply via email to