@Nathan Thanks a lot for the detailed explanation. One final gap that I still have is the following: what would be then the common attribute among the different client certificates. I assume that each will have its own private key not all clients need to have the same certificate private key. Another question is about the roles: how can you associate a role with a client certificate and then be able to fine tune the ACL based on roletypes.
@Max: I think the model here is different from the public web where browsers verify the certificates of the server. In most cases in the web, this is just used for establishing a secure TLS connection for https not for further access control on the server resources. Best regards, Khaled On Thu, Nov 29, 2018 at 8:41 AM Max Kholmyansky <max...@gmail.com> wrote: > 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> 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] *On Behalf Of *Khaled Elsayed >> *Sent:* Wednesday, November 28, 2018 6:10 AM >> *To:* khaledieee <khaledi...@gmail.com> >> *Cc:* max...@gmail.com; iotivity-dev <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 >> <khaledieee=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> 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 (#10039): https://lists.iotivity.org/g/iotivity-dev/message/10039 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] -=-=-=-=-=-=-=-=-=-=-=-
