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.


From: Heldt-Sheller, Nathan [mailto:nathan.heldt-shel...@intel.com]
Sent: Thursday, August 10, 2017 4:58 PM
To: Alex Kelley <ale...@microsoft.com>; iotivity-dev@lists.iotivity.org
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 
 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.


From: Alex Kelley [mailto:ale...@microsoft.com]
Sent: Thursday, August 10, 2017 12:24 PM
To: Heldt-Sheller, Nathan 
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.


From: Alex Kelley
Sent: Monday, August 7, 2017 5:29 PM
To: 'Heldt-Sheller, Nathan' 
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 


From: Heldt-Sheller, Nathan [mailto:nathan.heldt-shel...@intel.com]
Sent: Monday, August 7, 2017 4:56 PM
To: Alex Kelley <ale...@microsoft.com<mailto:ale...@microsoft.com>>; 
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).


From: Alex Kelley [mailto:ale...@microsoft.com]
Sent: Monday, August 7, 2017 4:51 PM
To: Heldt-Sheller, Nathan 
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.


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>>; 
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).


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 
Subject: RE: Regression in certificate provisioning

Hi All,

I’ve done some more digging into 
 and it appears that certificate provisioning is working in CTT (see attached 
results for case 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 


 [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Alex Kelley via 
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 
     *   I have a fix for this in Gerrit already.
  *   IOT-2561: Cannot provision a certificate to an IoTivity 
  *   IOT-2562: OCProvisionCertificate continuously tries to send certificate 
credential even on 

iotivity-dev mailing list

Reply via email to