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://jira.iotivity.org/browse/IOT-2607> 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:ale...@microsoft.com]
Sent: Thursday, August 10, 2017 12:24 PM
To: Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com>; 
iotivity-dev@lists.iotivity.org
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' 
<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

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<mailto:ale...@microsoft.com>>; 
iotivity-dev@lists.iotivity.org<mailto: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

Reply via email to