Hi Max, The authentication mechanism depends on how the Server is configured at onboarding time. If the Server is configured with a symmetric /cred entry for this Client Device ID (e.g. via JustWorks OTM), then the TLS session is established using the “Symmetric pair-wise key” /cred entry on the Server, that corresponds to the connecting Client’s Device ID (/doxm.deviceuuid, which is the same value as /d.di), and similarly, the /cred entry on the Client corresponding to the Server’s Device ID (i.e. your “option 1” below).
If the Server is configured with asymmetric certificate credentials (e.g. via Mfr Certificate OTM), then the Client’s certificate chain is validated against the Root Cert installed on the Server (a Server /cred entry of type “Asymmetric signing key with certificate” and cred usage “mfgtrustca”). See the OCF Security Specification Section 10 “Device Authentication” for further details if you’re curious. Thanks, Nathan From: iotivity-dev@lists.iotivity.org [mailto:iotivity-dev@lists.iotivity.org] On Behalf Of Max Sent: Thursday, December 6, 2018 3:43 AM To: Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com>; iotivity <iotivity-dev@lists.iotivity.org> Cc: Khaled Elsayed <khaledi...@gmail.com> Subject: Re: [dev] Server to communicate via DTLS session with any client? Nathan Hi, For the sake of clarity for the developers, may I kindly ask you to provide the exact logical statement on what is required by the IoTivity library in order to establish a DTLS connection between a client and a server, from the authentication perspective? (I understand that there is also a requirement for the ACL to allow the access) My current picture: Option 1 Match of a "shared secret" configured in the security configuration file: "server di" in the client matches "client di" in the server. (This is based on the samples code) Option 2 Server to present a certificate being successfully validated by the client [AND? OR? What's true?] Client to present a certificate being successfully validated by the server Any other options? Do the developers have a control over this mechanism? (i.e. may a server or a client developer to decide which mechanisms to choose) Thanks and best regards Max On Thu, Dec 6, 2018 at 2:45 AM Nathan Heldt-Sheller <nathan.heldt-shel...@intel.com<mailto:nathan.heldt-shel...@intel.com>> wrote: Thanks Max, Yes you’re right; my typo on that one thanks for catching ☺ And yes, Certificate-based TLS handshake can require authentication by one or both parties (that is, one or both present a Cert or Cert Chain to be validated by the other). Thanks, Nathan From: Max Kholmyansky [mailto:max...@gmail.com<mailto:max...@gmail.com>] Sent: Wednesday, November 28, 2018 10:41 PM To: Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com<mailto:nathan.heldt-shel...@intel.com>> Cc: khaledi...@gmail.com<mailto:khaledi...@gmail.com>; iotivity <iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>> Subject: Re: [dev] Server to communicate via DTLS session with any client? Hi Nathan Thanks for educating us. One point to clarify: when you say "the reason the Client trusts the Server" - you actually meant that the server is making a decision to trust the client, based on the technical explanation you provided? I understand that technically, same private key and sam certificate may be reused between multiple clients connecting to the server, and all what the server cares - is that each client can present the certificate and proof the private key possession. Also, can you please clarify of TLS can work "in the reverse way", i.e. requiring the server to present its certificate, and the client to verify its validity. This is "inspired" by what I know about the public Internet services: each organization running a secure web site has to obtain a certificate, and web browsers (in client role) validate the certificates presented by the server they connect to, but there is no requirement for a browser (client) to carry any certificate. Can you please explain whether this way is supported by IoTivity, and what are the considerations. Nathan, thanks again for your valuable feedback, and best regards. Max. On Wed, Nov 28, 2018 at 6:07 PM Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com<mailto:nathan.heldt-shel...@intel.com>> wrote: Thanks Khaled, Max, Khaled is correct: the way to avoid needing a /cred entry for each Client is to use asymmetric crypto (Certs in the IoTivity case). A thorough explanation of asymmetric crypto is a bit much for an email but I think this Q&A is pretty decent: https://crypto.stackexchange.com/questions/32304/how-exactly-does-certificate-based-authentication-work. There’s a lot more on the web if you search for “certificate based handshake”. The (very) simplified version is that the Client presents a public Identity certificate (also called End Entity Certificate) to the Server. That EE Certificate contains a public key which corresponds to the private key held by the Client, so that the Client can prove that it is the rightful owner of the EE Cert, via asymmetric crypto operations. The Client’s EE Certificate is also signed by an entity called a “Certificate Authority” or “CA”. The Server has a pre-installed certificate called a “Root Certificate”. This is what allows the Server to verify EE Certs issued by that CA. Using the public key in the Root Certificate, the Client can verify the veracity of the EE Cert. So in the end, the reason the Client trusts the Server is that a) the Client’s EE cert can be verified to have been issued by the CA, to the owner of the corresponding private keys, and b) the Client can demonstrate that it is the owner of those private keys. This doesn’t require a /cred entry for each Client, because the same Root Certificate can be used to verify the veracity of many different Client certificates. But the Server does need to have a the Root Cert installed for the CA(s) that issued the Client cert. We call that Root Cert the “Trust Anchor” because it is the last point in the dotted line of items that form a logical chain of trustworthiness. Hope that helps, Thanks, Nathan From: iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> [mailto:iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>] On Behalf Of Khaled Elsayed Sent: Wednesday, November 28, 2018 6:10 AM To: khaledieee <khaledi...@gmail.com<mailto:khaledi...@gmail.com>> Cc: max...@gmail.com<mailto:max...@gmail.com>; iotivity-dev <iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>> Subject: Re: [dev] Server to communicate via DTLS session with any client? Also, if you can clearly identify what is happening, please share your findings. I had a look but still not totally clear about the exact procedure. On Wed, Nov 28, 2018 at 4:07 PM Khaled Elsayed via Lists.Iotivity.Org<http://Lists.Iotivity.Org> <khaledieee=gmail....@lists.iotivity.org<mailto:gmail....@lists.iotivity.org>> wrote: This can be done via certificates. You can find the example for the provisionclient. I am still trying to figure out myself as it is not very well documented. Quoting Nathan reply on my question sent last week or so. There is indeed an example of Certificate-based Client/Server authentication in the IoTivity example “sampleserver_mfg”, which is in the resource/csdk/securitiy/provisioning/sample folder. On Wed, Nov 28, 2018 at 2:56 PM Max <max...@gmail.com<mailto:max...@gmail.com>> wrote: Hi, I am looking for a technical advice on how a secure UDP endpoint ("coaps") exposed by IoTivity-powered server - may be accessed from any IoTivity-powered client, without prior coordination between the client and the server. This is similar to the idea that any browser in the world can access a web site via SSL, while the server isn't blocking any particular browser from the access. [Note: this is a technology POC, not related to the OCF specification. So the question is in the context of IoTivity library capabilities, not in the context of the OCF security and compliance] I would appreciate some advice from the people who understand how the DTLS "handshake" in IoTivity works. Looking at the sample code... The "simpleclient" and "simpleserver" sample solve the issue, via placing a shared "credential" into the security configuration file. Below is the server configuration file. However, this isn't good for me, since the server needs a section per specific "di" of the connecting client, while my goal is to allow DTLS (secure) session for any client. I would appreciate ideas on how it can be done. Thanks in advance, Max. "cred": { "creds": [ { "credid": 1, "subjectuuid": "32323232-3232-3232-3232-323232323232", "credtype": 1, "period": "20150630T060000/20990920T220000", "privatedata": { "data": "AAAAAAAAAAAAAAAA", "encoding": "oic.sec.encoding.raw" } }, { "credid": 2, "subjectuuid": "31393139-3139-3139-3139-313931393139", "credtype": 1, "period": "20150630T060000/20990920T220000", "privatedata": { "data": "BBBBBBBBBBBBBBBB", "encoding": "oic.sec.encoding.raw" } } ], "rowneruuid": "32323232-3232-3232-3232-323232323232" } -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10071): https://lists.iotivity.org/g/iotivity-dev/message/10071 Mute This Topic: https://lists.iotivity.org/mt/28430313/21656 Group Owner: iotivity-dev+ow...@lists.iotivity.org Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
