Thanks again. Will retry using 'oic.sec.cred.cert'. Was using "credusage": "oic.sec.cred.mfgcert" for the client own certificate and intermediate certificate and "credusage": "oic.sec.cred.mfgtrustca" for the peer certificate. I guess you meant oic.sec.cred.cert in place of the oic.sec.cred.mfgcert but the oic.sec.cred.mfgtrustca should remain the same as this is what is used to verify the peer certificate.
I attach the client and server .json files. For simplicity, I am assuming a
pre-provisioned server here. As mentioned earlier no problem in getting the
server provisioned via provisioningclient (of course the json file doxm
entry is different for that case).
I will retry and share the logs if that change still does not work.
Best regards,
Khaled
On Thu, Jan 3, 2019 at 11:26 AM Oleksiy Volkov <a.vol...@samsung.com> wrote:
>
>
> ...Also, credUsage type must be 'oic.sec.cred.cert'...
>
>
>
>
>
> *Best regards,*
>
> *Aleksey Volkov*
>
>
>
> --------- *Original Message* ---------
>
> *Sender* : Oleksiy Volkov <a.vol...@samsung.com> Staff Engineer/Security
> Certification Part /SRK/Samsung Electronics
>
> *Date* : 2019-01-03 11:16 (GMT+2)
>
> *Title* : Re: [dev] Certificate-based credential (DTLS fails to find
> cipher suite)
>
>
>
>
>
> Hi Khaled,
>
>
>
> InitManufacturerCipherSuiteList callback used at the one step of the mfg
> otm process. In all other cases (yours also) should be used
> InitCipherSuiteList as g_getCredentialTypesCallback (Please check
> SRMInitSecureResources function). According to your log,
> InitCipherSuiteList is called successfully, so it's normal behavior, and
> there are no other issues than the lack of credentials.
>
> Could you share full log from the beginning and dat file of yours 3rd
> client, please?
>
>
>
> *Best regards,*
>
> *Aleksey Volkov*
>
>
>
> --------- *Original Message* ---------
>
> *Sender* : Khaled Elsayed <khaledi...@gmail.com>
>
> *Date* : 2019-01-02 23:44 (GMT+2)
>
> *Title* : Re: Re: [dev] Certificate-based credential (DTLS fails to find
> cipher suite)
>
>
> Hi Aleksey,
>
> Thanks for taking a close look at the log. You are absolutely right about
> the observation that InitCiherSuite comes back empty handed. The
> credentials are perfect and have credtype=8 and I check that the .dat files
> are read correctly by both the client and server codes.
>
> *There is a bug in the code* either in the function SetupCipher or
> initialization of callbacks before invoking SetupCipher. It *will not
> work* currently as is. I will report this via jira. Here is why:
> In SetupCipher, I added some logs for g_caSslContext->cipherFlag[0]
> and g_caSslContext->cipherFlag[1] both are false after calling
> g_getCredentialTypesCallback(g_caSslContext->cipherFlag, deviceId);
> So, it will not be able to find any ciphersuite. There is a need to
> properly initialize the g_getCredentialTypesCallback to use the mfg_cert
> callback functions. Something like what is done in the
> function OTMSetOTCallback in ownershiptransfermanager.c where it calls
> PrepareMCertificateCallback
> to set the callbacks in case it identifies a certificate-based credential.
> There must be something like this before SetupCipher is called, otherwise
> no certificates will work. I tried to add some similar code to the function
> below but got all types of linking errors as I am not really into
> scons/sconscript :)
>
> OCStackResult PrepareMCertificateCallback(OTMContext_t *otmCtx)
> {
> OIC_LOG(INFO, TAG, "IN PrepareMCertificateCallback");
>
> if (!otmCtx || !otmCtx->selectedDeviceInfo)
> {
> return OC_STACK_INVALID_PARAM;
> }
>
> if (CA_STATUS_OK != CAregisterPkixInfoHandler(GetManufacturerPkixInfo))
> {
> OIC_LOG(ERROR, TAG, "Failed to register PkixInfohandler");
> return OC_STACK_ERROR;
> }
>
> if (CA_STATUS_OK != CAregisterIdentityHandler(NULL))
> {
> OIC_LOG(ERROR, TAG, "Failed to register IdentityHandler");
> return OC_STACK_ERROR;
> }
>
> if (CA_STATUS_OK !=
> CAregisterGetCredentialTypesHandler(InitManufacturerCipherSuiteList))
> {
> OIC_LOG(ERROR, TAG, "Failed to register CredentialTypesHandler");
> return OC_STACK_ERROR;
> }
>
> OIC_LOG(INFO, TAG, "OUT PrepareMCertificateCallback");
>
> return OC_STACK_OK;
> }
>
>
>
>
>
> On Wed, Jan 2, 2019 at 3:46 PM Oleksiy Volkov <a.vol...@samsung.com>
> wrote:
>
>> Hi Khaled,
>>
>>
>>
>> I noticed that in your log between the lines 'In
>> InitCipherSuiteListInternal' & 'Out InitCipherSuiteListInternal' there are
>> no any messages.
>>
>> This may indicate that there are no suitable credentials in the cred
>> resource, or they have the wrong type value.
>>
>> (As I understand it should be the SIGNED_ASYMMETRIC_KEY type credential
>> for your case). So, please check your dat file for necessary credential.
>> entries.
>>
>>
>>
>>
>>
>> *Best regards,*
>>
>> *Aleksey Volkov*
>>
>>
>>
>> --------- *Original Message* ---------
>>
>> *Sender* : Khaled Elsayed <kha...@ieee.org>
>>
>> *Date* : 2019-01-02 13:22 (GMT+2)
>>
>> *Title* : Re: [dev] Certificate-based credential (DTLS fails to find
>> cipher suite)
>>
>>
>> Thanks Aleksey. For sure I am using OC_CLIENT_SERVER mode. My code is
>> based on ~/iotivity/examples/OCFSecure which already took core of this in
>> the client.cpp code.
>>
>>
>> On Fri, Dec 28, 2018 at 1:40 PM Oleksiy Volkov <a.vol...@samsung.com>
>> wrote:
>>
>>> Hi Khaled,
>>>
>>>
>>>
>>> maybe you use 'client only' (OC_CLIENT) mode instead of 'client-server'
>>> (OC_CLIENT_SERVER) to initialize the Iotivity stack.
>>>
>>>
>>>
>>> *Best regards,*
>>>
>>> *Aleksey Volkov*
>>>
>>>
>>>
>>> --------- *Original Message* ---------
>>>
>>> *Sender* : Khaled Elsayed <kha...@ieee.org>
>>>
>>> *Date* : 2018-12-10 18:54 (GMT+2)
>>>
>>> *Title* : Re: [dev] Certificate-based credential (DTLS fails to find
>>> cipher suite)
>>>
>>>
>>> Hi Gregg,
>>>
>>> No unfortunately. I will have a second look today but If I could not, I
>>> will proceed using the non-certificate based shared key credential
>>> supporting a limited number of clients for the time being.
>>>
>>> On Sun, Dec 9, 2018 at 11:18 PM Gregg Reynolds <d...@mobileink.com>
>>> wrote:
>>>
>>>> Did you ever get this figured out?
>>>>
>>>> I've seen "*No ciphersuites configured**" but sadly don't remember how
>>>> I resolved it.*
>>>>
>>>> *G*
>>>>
>>>> On Wed, Dec 5, 2018, 9:34 AM Khaled Elsayed <khaledi...@gmail.com
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am trying to get certificate-based credential management to work
>>>>> between a provisioned server and a client. So, I worked a bit more with
>>>>> the
>>>>> provisionclient and sampleserver_mfg. I created new certificates via the
>>>>> crtgenerator application. I configured the json files with the new
>>>>> certificates and private keys for both application. The provisioning
>>>>> worked. This is the good news proving that these certificates and json
>>>>> files do work.
>>>>>
>>>>> The bad news is if I want to apply the certificate based
>>>>> authentication/credntial in other examples not including provisioning, it
>>>>> does not work. I use the sample client and server in the
>>>>> examples/OCFSecure
>>>>> folder. The client and server initiate properly and reads the
>>>>> cred/certificates correctly. However, when the client attempts to issues a
>>>>> GET request over coaps, it fails.
>>>>>
>>>>> Obviously there is something that needs to be invoked to associate the
>>>>> client and server so that they use the certificates to calculate the
>>>>> shared
>>>>> symmetric encryption key. This seems to occur when the provisioningclient
>>>>> starts to access the /doxm resource in the sampleserver_mfg. I could see
>>>>> that in the log but I cannot figure out how to make the OCFSecure
>>>>> client/server start the certificate exchange process.
>>>>>
>>>>> Here is the log. It complains *No ciphersuites configured* (see
>>>>> below) although they are to start DTLS handshake (InitiateTlsHandshake is
>>>>> being invoked). So, what procedure should be invoked to create a cipher
>>>>> between the two endpoints using the certificates before reaching to the
>>>>> point they exchange coaps payloads. Thanks for any pointers.
>>>>>
>>>>> 48:53.275 INFO: OIC_CA_MSG_HANDLE: CASendUnicastData type : 1
>>>>>
>>>>> 48:53.275 DEBUG: OIC_CA_INF_CTR: unicast message to adapter
>>>>>
>>>>> 48:53.275 DEBUG: OIC_UQUEUE: Queue Count : 1
>>>>>
>>>>> 48:53.275 INFO: OIC_CA_PRTCL_MSG: adapter value of CoAP/TCP is 1
>>>>>
>>>>> 48:53.275 DEBUG: OIC_CA_RETRANS: sent pdu, msgtype=1, msgid=60490
>>>>>
>>>>> 48:53.275 DEBUG: OIC_CA_RETRANS: not supported message type
>>>>>
>>>>> 48:53.275 DEBUG: OIC_CA_MSG_HANDLE: CADestroyData IN
>>>>>
>>>>> 48:53.275 DEBUG: OIC_CA_MSG_HANDLE: CADestroyData OUT
>>>>>
>>>>> 48:53.275 DEBUG: OIC_CA_QING: wait..
>>>>>
>>>>> 48:53.275 DEBUG: OIC_CA_QING: wake up..
>>>>>
>>>>> 48:53.275 DEBUG: OIC_CA_IP_ADAP: DTLS encrypt called
>>>>>
>>>>> 48:53.275 DEBUG: OIC_CA_NET_SSL: In CAencryptSsl
>>>>>
>>>>> 48:53.275 DEBUG: OIC_CA_NET_SSL: Port 39115
>>>>>
>>>>> 48:53.275 DEBUG: OIC_CA_NET_SSL: Data to be encrypted dataLen [30]
>>>>>
>>>>> 48:53.275 DEBUG: OIC_CA_NET_SSL: In GetSslPeer
>>>>>
>>>>> 48:53.275 DEBUG: OIC_CA_NET_SSL: Return NULL
>>>>>
>>>>> 48:53.275 DEBUG: OIC_CA_NET_SSL: Out GetSslPeer
>>>>>
>>>>> 48:53.279 DEBUG: OIC_CA_NET_SSL: In InitiateTlsHandshake
>>>>>
>>>>> 48:53.279 DEBUG: OIC_CA_NET_SSL: In NewSslEndPoint
>>>>>
>>>>> 48:53.279 DEBUG: MBED_TLS: set_timer to 0 ms
>>>>>
>>>>> 48:53.279 DEBUG: OIC_CA_NET_SSL: New [client role] endpoint added [
>>>>> 10.0.0.2:39115]
>>>>>
>>>>> 48:53.279 DEBUG: OIC_CA_NET_SSL: Out NewSslEndPoint
>>>>>
>>>>> 48:53.279 DEBUG: OIC_CA_NET_SSL: In SetupCipher
>>>>>
>>>>> 48:53.279 DEBUG: OIC_SRM_PKIX_INTERFACE: In InitCipherSuiteList
>>>>>
>>>>> 48:53.279 DEBUG: OIC_SRM_CREDL: In InitCipherSuiteListInternal
>>>>>
>>>>> 48:53.279 DEBUG: OIC_SRM_CREDL: Out InitCipherSuiteListInternal
>>>>>
>>>>> 48:53.279 DEBUG: OIC_SRM_PKIX_INTERFACE: Out InitCipherSuiteList
>>>>>
>>>>> 48:53.279 DEBUG: OIC_CA_NET_SSL: Supported ciphersuites:
>>>>>
>>>>> *48:53.279 ERROR: OIC_CA_NET_SSL: No ciphersuites configured, secure
>>>>> connections will fail*
>>>>>
>>>>> 48:53.279 DEBUG: OIC_CA_NET_SSL: Out SetupCipher
>>>>>
>>>>> 48:53.279 ERROR: OIC_CA_NET_SSL: Failed to set up cipher
>>>>>
>>>>> 48:53.279 DEBUG: OIC_CA_NET_SSL: In DeleteSslEndPoint
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Nov 27, 2018 at 9:16 AM Khaled Elsayed <khaledi...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Thanks Mats for the pointer. Very handy tool. Nicely done Rami.
>>>>>>
>>>>>> Khaled
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 26, 2018 at 5:21 PM Mats Wichmann <m...@wichmann.us>
>>>>>> wrote:
>>>>>>
>>>>>>> On 11/26/18 7:53 AM, Khaled Elsayed wrote:
>>>>>>> > Hi Nathan
>>>>>>> >
>>>>>>> > Just wanted to confirm that json2cbor from iotivity-2.0.0 and
>>>>>>> latest master
>>>>>>> > both fail when an ACE contains a roletype entry.
>>>>>>> >
>>>>>>> > For the provisioning client example, is there anyway to inspect
>>>>>>> the .dat
>>>>>>> > files that are modified after the provisioning is performed?
>>>>>>> Something like
>>>>>>> > a cbor2json if there is such a tool.
>>>>>>> >
>>>>>>> > Thanks
>>>>>>> >
>>>>>>> > Khaled
>>>>>>>
>>>>>>> https://github.com/alshafi/iotivity-tool
>>>>>>>
>>>>>>> should be able to do this - it converts in both directions.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10121):
https://lists.iotivity.org/g/iotivity-dev/message/10121
Mute This Topic: https://lists.iotivity.org/mt/28611921/21656
Group Owner: iotivity-dev+ow...@lists.iotivity.org
Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
201901031126336_BGFC2LL5
Description: Binary data
201901031126353_N3WZA6X7
Description: Binary data
client.cred.json
Description: application/json
server.cred.json
Description: application/json
