Hi Nathan, Sorry for the misunderstanding. In this case I am talking about who actually handles changing the DOS state. I do not see any place in ProvisioningClient that changes DOS or calls SetDos directly. Instead it looks like the SRP* APIs in secureresourceprovider.c are responsible for handling that. For example when ProvisioningClient wants to provision pairwise devices it calls OCProvisionPairwiseDevices which internally calls SRPProvisionCredentialsDos. SRPProvisionCredentialsDos calls SetDos which handles provisioning different credentials after setting DOS to RF_PRO.
In the case of certificates though SRPProvisionCredentials is still called (ProvisioningClient --> OCProvisionCertificate --> SRPProvisionCredentials) instead of SRPProvisionCredentialsDos. My understanding of your recommendation below was that ProvisioningClient would be the one to change DOS to RF_PRO for certificate provisioning (please correct me if I have misunderstood). This would seem to conflict with the design already in place that is used for OCProvisionPairwiseDevices since the stack sets DOS for OCProvisionPairwiseDevices. Thanks, Alex From: Heldt-Sheller, Nathan [mailto:nathan.heldt-shel...@intel.com] Sent: Monday, August 7, 2017 4:56 PM To: Alex Kelley <ale...@microsoft.com>; iotivity-dev@lists.iotivity.org Subject: RE: Regression in certificate provisioning Hi Alex, I'm not sure I understand your question... the DOS-aware versions should be used with OCF 1.0 Servers, as the Client (OBT) must change the /pstat.dos.s to a state that allows modification of the SVR Properties being Updated. The non-DOS aware versions would be for OIC 1.1 Servers. If the non-DOS-aware version of a function is being used with an OCF 1.0 Server, that's probably a version-handling bug in the provisioningclient, but I'll let whoever takes the JIRA ticket dig into where the change needs to be made (your suggestion that the existing DOS-aware function be updated makes sense, but again I haven't looked closely at the issue). Thanks, Nathan From: Alex Kelley [mailto:ale...@microsoft.com] Sent: Monday, August 7, 2017 4:51 PM To: Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com<mailto:nathan.heldt-shel...@intel.com>>; iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> Subject: RE: Regression in certificate provisioning Thanks for taking a look Nathan. I have updated the ticket with the information from this thread and tagged Randeep. I am a little confused on why changing DOS would be done in ProvisioningClient though. For PSK the APIs call into SRPProvisionCredentialsDos which sets DOS and handles SYMMETRIC_PAIR_WISE_KEY just like the non-DOS version (SRPProvisionCredentials). Wouldn't it be more appropriate to update SRPProvisionCredentialsDos to also handle certificates? I suppose either way is fine however it will be odd if the application is responsible for changing DOS for some APIs and not others. Thanks, Alex From: Heldt-Sheller, Nathan [mailto:nathan.heldt-shel...@intel.com] Sent: Monday, August 7, 2017 4:21 PM To: Alex Kelley <ale...@microsoft.com<mailto:ale...@microsoft.com>>; iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> Subject: RE: Regression in certificate provisioning Alex thank you for looking into this further. Yes, the provisioningclient should be changing the /pstat.dos.s to RFPRO (or optionally SRESET) before attempting to modify /cred, per the OCF 1.0 Security Spec. This is new in OCF 1.0 (in OIC 1.1 the /cred Resource could be updated at unsafe points like during normal Server operation). It sounds like the provisioningclient app needs to be updated to reflect this change, when working with OCF 1.0 Servers. Can you please update IOT-2561 with your findings, and tag Randeep asking him to assign the issue to Oleksandr Dmytrenko or Dmitriy Zhuravlev, depending on availability (the last two to work on the provisioningclient app, I think). Thanks, Nathan From: Alex Kelley [mailto:ale...@microsoft.com] Sent: Monday, August 7, 2017 2:39 PM To: iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>; Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com<mailto:nathan.heldt-shel...@intel.com>> Subject: RE: Regression in certificate provisioning Hi All, I've done some more digging into IOT-2561<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira.iotivity.org%2Fbrowse%2FIOT-2561&data=02%7C01%7Calexke%40microsoft.com%7Cd6980baed8494d05873f08d4ddeafc45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636377448715007564&sdata=zkHkcgvCkQu%2BbFbOWeaAaCF%2FzLrAUv3rS%2Bp7AwJFJD0%3D&reserved=0> and it appears that certificate provisioning is working in CTT (see attached results for case 1.7.4.4) so we should be able to provision certificates. In the CTT test case output I can see that the DOS state is switched to RF_PRO before attempting to provision the device with a certificate and everything succeeds without issue. However if I walk the code for OCProvisionCertificate (OCProvisionCertficiate --> SRPProvisionCredentials) from ProvisioningClient I do not see the state get changed before attempting to provision the credential. This aligns with the warning I noted in IOT-2561: 54:26.515 WARNING: OIC_SRM_CREDL: HandlePostRequest /cred resource is read-only in RESET and RFNOP. This seems to be the correct layer to make the change to DOS' state since there is a similar function below called SRPProvisionCredentialsDos that does change the state. @Nathan - Does this look like an issue with DOS being in the wrong state or do you see something else that would prevent the certificate from being provisioned? Thanks, Alex From: iotivity-dev-boun...@lists.iotivity.org<mailto:iotivity-dev-boun...@lists.iotivity.org> [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Alex Kelley via iotivity-dev Sent: Wednesday, August 2, 2017 5:32 PM To: iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> Subject: [dev] Regression in certificate provisioning Hi All, It appears that we have hit a regression in functionality related to certificate provisioning in IoTivity. Shortly after PKI support was merged into IoTivity it was tested with provisioningTest.py and all test cases were passing. I tried running provisioningTest.py yesterday (after correcting IOT-2555 locally) and found that some of the test cases were failing due to timing out while trying to provision a certificate to the device. After doing some more digging I found that I could repro the same issue with just ProvisioningClient and SampleServer_JustWorks however IOT-2560 (linked below) was masking the failure in ProvisioningClient. I have opened the following JIRA tickets to track the issues I observed: · IOT-2560: ProvisioningClient does not return an error code on timeout<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira.iotivity.org%2Fbrowse%2FIOT-2560&data=04%7C01%7Calexke%40microsoft.com%7Cb4dabdaffbaa465adf0b08d4da071e57%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636373171526521413%7CUnknown%7CVW5rbm93bnx7IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT3RoZXIifQ%3D%3D%7C-1&sdata=lL9rNiMggkEGa6t48Y4oqrBYp6IB%2BASa5MhW%2FYuCzak%3D&reserved=0> o I have a fix for this in Gerrit already. · IOT-2561: Cannot provision a certificate to an IoTivity device<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira.iotivity.org%2Fbrowse%2FIOT-2561&data=04%7C01%7Calexke%40microsoft.com%7Cb4dabdaffbaa465adf0b08d4da071e57%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636373171526521413%7CUnknown%7CVW5rbm93bnx7IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT3RoZXIifQ%3D%3D%7C-1&sdata=qxNlloE2m97Lzx3GXnzbS%2B%2BHg8bhFyHFAxaxDJf1E08%3D&reserved=0> · IOT-2562: OCProvisionCertificate continuously tries to send certificate credential even on failure<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira.iotivity.org%2Fbrowse%2FIOT-2562&data=04%7C01%7Calexke%40microsoft.com%7Cb4dabdaffbaa465adf0b08d4da071e57%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636373171526521413%7CUnknown%7CVW5rbm93bnx7IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT3RoZXIifQ%3D%3D%7C-1&sdata=UedGApN7ZKJg%2FZ5AQG2e5Sp12f97bwktCzLhJUE4nZQ%3D&reserved=0> Thanks, Alex
_______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
