2.1.5, split up password and certificate based authentication about iot-security-verification-standard-isvs HOT 6 CLOSED

Thanks for clarifying. 2.1.5 could then simply be: Use certificate based authentication instead of password based authentication. The term “prefer” makes the requirement a bit ambiguous. On the other points, I agree that a certain level of detail needs to be chosen for the entire set of requirements. On you last point, I didn’t mean certificates to be used for client side authentication but rather server certificates with a CN and SAN of the vendors corporation. I would add that it is not just about protecting the certificate but simply not using a publicly signed certificate which is trusted for one of your corporate domains. What I am looking for is a requirement that prevents this: https://gist.github.com/nstarke/a611a19aab433555e91c656fe1f030a9 Again, this might be to granular for this set of requirements. From: Cédric Bassem <[email protected]> Sent: donderdag 14 januari 2021 18:25 To: OWASP/IoT-Security-Verification-Standard-ISVS <[email protected]> Cc: Roel Storms <[email protected]>; Author <[email protected]> Subject: Re: [OWASP/IoT-Security-Verification-Standard-ISVS] 2.1.5, split up password and certificate based authentication (#35) Hi Roel, thank you for your feedback! This is much appreciated. Please find my feedback below. * Concerning the use of passwords/certificates. If we split up 2.1.5, then we would hint towards using passwords, which is something we would like to avoid. Use of strong passwords is covered in 2.1.3 and 2.1.6. Perhaps we should add the requirement that passwords should be "strong" to 2.1.6. I notice that this one is perhaps not covered explicitly enough. * Concerning certificate based authentication. 2.4.1 discusses that cryptographic secrets should be unique per device. Are there other recommendations concerning certificate based authentication that you're thinking about? * How are these certificates best generated and installed on the device? I feel like there is not "one" true way on how to tackle this. This can be done both during manufacturing or during registration/enrolment of the device, you can even have the user upload the client certificate themselves. Some general things that I think of are: the certificate should be generated securely, transferred securely and stored securely. How this is done, feels implementation specific and perhaps too much detail for the ISVS. * Concerning certificate renewal, this is tackled to a certain extend in the Software Updates section in V3. * Concerning certificates being retrieved, I feel this is covered by the data protection section in V2 and by 2.4.4 in Cryptography. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#35 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALBNN6QP64OBYKQLU3AXIDSZ4SFPANCNFSM4WAOLVYQ> . <https://github.com/notifications/beacon/AALBNN5EV2T6TY5GW3TVJ7DSZ4SFPA5CNFSM4WAOLVY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFVI6O6Q.gif>

Indeed, I mixed two different applications of certificates. But your consideration makes sense. From: Aaron G <[email protected]> Sent: vrijdag 22 januari 2021 17:22 To: OWASP/IoT-Security-Verification-Standard-ISVS <[email protected]> Cc: Roel Storms <[email protected]>; Author <[email protected]> Subject: Re: [OWASP/IoT-Security-Verification-Standard-ISVS] 2.1.5, split up password and certificate based authentication (#35) Maybe we should differentiate user authentication and M2M in terms of certificates and passwords? Users will often opt for UN/PW while M2M implementation are different in terms of managing credential lifecycles. We will keep thinking about this one and suggested revisions. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#35 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALBNNYSSSWHD2NDYRTPOBLS3GQ3BANCNFSM4WAOLVYQ> .