Hi Nathan, I think I see where our misunderstanding is now so let me try to clear it up.
You are correct that the Client side should be setting /pstat.dos to RFPRO, updating the cred, and then setting /pstat.dos back to RFNOP. In everything I have observed that is all working correctly. The server side is not doing anything to alter /pstat.dos, as far as I know, so we should be good. 😊 The question I raised revolves around this statement. Specifically this part about ProvisioningClient app. When you refer to ProvisioningClient app do you mean all of ProvisioningClient (the code in provisioningclient.c as well as the client IoTivity stack) or do you specifically mean the application level code for ProvisioningClient (the code in provisioningclient.c). I took ProvisioningClient app to mean just the code in provisioningclient.c should be updated to set /pstat.dos to RFPRO using SetDos, provision the credential with OCProvisionCertificate, and then set /pstat.dos to RFNOP using SetDos. This differs from provisioning credentials with OCProvisionPairwiseDevices where the code in provisioningclient.c just calls OCProvisionPairwiseDevices and the underlying client IoTivity stack will set /pstat.dos to RFPRO on the server, provision the pairwise credential, and set /pstat.dos back to RFNOP. My intention was just to clarify which layer was responsible for setting /pstat.dos to the appropriate state before and after provisioning a credential for the other ticket I opened. Thanks, Alex From: Heldt-Sheller, Nathan [mailto:[email protected]] Sent: Thursday, August 10, 2017 4:58 PM To: Alex Kelley <[email protected]>; [email protected] Subject: RE: Regression in certificate provisioning Hi Alex, We discussed this yesterday in the Weds a.m. OSWG Security TG call. Jong-Min (Samsung) and I agreed that the correct behavior should be that the Client sets /pstat.dos to RFPRO, then updates /cred, then again Client sets /pstat.dos back to RFNOP. I asked if anyone was familiar with the description you gave below, but it appears that the two devs who worked on this aspect have recently left Samsung, so we were a bit stumped as to why the Server-side stack might be updating /pstat.dos internally. I took the AR to create a descriptive JIRA ticket, and assign to Aleksey Volkov to prepare a fix. However, I have to admit I took a quick look at the code and it wasn’t clear to me exactly what the control flow is that you were referring to... from my reading, the Client is indeed setting the Server’s /pstat.dos via the setDOS call. I’ve created the JIRA ticket but I’d like your help in better describing the issue you observed. Can you please go to IOT-2607<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira.iotivity.org%2Fbrowse%2FIOT-2607&data=02%7C01%7Calexke%40microsoft.com%7C0e5d5a7a2b81418f1d5308d4e04bb056%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636380063071656190&sdata=%2FIL58JaVbBqcmq2JEh9%2F5z6U2eQy%2BYQvA2JMTDknizY%3D&reserved=0> and continue discussion there? If it turns out that the Client/Server division of labor is correct, but we need to have the Client update /pstat.dos prior to updating /cred, that’s fine, we can just modify the IOT-2607 issue title, before assigning to Aleksey. Thanks, Nathan From: Alex Kelley [mailto:[email protected]] Sent: Thursday, August 10, 2017 12:24 PM To: Heldt-Sheller, Nathan <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE: Regression in certificate provisioning Hey Nathan, Just wanted to bring this back to the top of your inbox. If you have any other questions please let me know. Thanks, Alex From: Alex Kelley Sent: Monday, August 7, 2017 5:29 PM To: 'Heldt-Sheller, Nathan' <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE: Regression in certificate provisioning 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:[email protected]] Sent: Monday, August 7, 2017 4:56 PM To: Alex Kelley <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 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:[email protected]] Sent: Monday, August 7, 2017 4:51 PM To: Heldt-Sheller, Nathan <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 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:[email protected]] Sent: Monday, August 7, 2017 4:21 PM To: Alex Kelley <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 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:[email protected]] Sent: Monday, August 7, 2017 2:39 PM To: [email protected]<mailto:[email protected]>; Heldt-Sheller, Nathan <[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Alex Kelley via iotivity-dev Sent: Wednesday, August 2, 2017 5:32 PM To: [email protected]<mailto:[email protected]> 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> * 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 [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
