Great. This is logical but not documented anywhere. I owe you a drink :) Now it passes the stage of not finding ciphersuite!! Just getting some handshake error. But at least they are trying to start the DTLS encrypted link. Will re-check the certificate chain.
Talk to you soon.
On Thu, Jan 3, 2019 at 4:40 PM Oleksiy Volkov <a.vol...@samsung.com> wrote:
> Khaled,
>
>
>
> Important addition: for the root certificate you need to use
> "oic.sec.cred.trustca" value credUsage field instead of
> "oic.sec.cred.mfgtrustca", since cipher suite list formed by trustca
> certificates.
>
> "oic.sec.cred.mfgcert" and "oic.sec.cred.mfgtrustca" types used only at
> the otm process, and will never used then for authentication by default.
>
>
>
>
>
> *Best regards,*
>
> *Aleksey Volkov*
>
>
>
> --------- *Original Message* ---------
>
> *Sender* : Khaled Elsayed <khaledi...@gmail.com>
>
> *Date* : 2019-01-03 12:13 (GMT+2)
>
> *Title* : Re: Re: [dev] Certificate-based credential (DTLS fails to find
> cipher suite)
>
>
> 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 (#10125):
https://lists.iotivity.org/g/iotivity-dev/message/10125
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]
-=-=-=-=-=-=-=-=-=-=-=-
201901031640285_LCGFY2AH
Description: Binary data
201901031640301_X1FI5HHV
Description: Binary data
201901031640318_2XYNX48N
Description: Binary data
