Re: next steps with CII -- back to [crypto_certificate_verification]:
Very nice deck. I suggest adding the following checks which are part of certificate validation: 1. Check that the cert is still within its validity period. 2. Perform the cryptography to ensure that the sender of the cert possesses the private key For extra credit, the cert should be checked against a Certificate Revocation List (CRL).
From: HANSEN, TONY L
Sent: Friday, June 28, 2019 3:57 PM To: natacha.mach@...; onap-seccom@... Cc: PAWLAK Pawel O-PL <pawel.pawlak3@...>; ZWARICO, AMY <az9121@...>; CLOSE, PIERRE <pierre.close@...>; GATHMAN, JONATHAN C <jonathan.gathman@...> Subject: Re: [Onap-seccom] next steps with CII -- back to [crypto_certificate_verification]:
Here are updated slides from what Pawel showed on Tuesday. These are intended to be shared on the PTL meeting next Monday. If you have any comments, PLEASE share them.
Thank you.
Tony
From: "HANSEN, TONY L" <tony@...>
Thank you, Natacha, for your comments. I also listened to the conversation on this week’s SECCOM meeting, which I unfortunately had to miss.
To summarize the concerns brought up:
I definitely can see how the question COULD be read that way, so agree that it is ambiguous.
The fun thing is that, when there are ambiguities, WE (the SECCOM) get to decide how to interpret it. So my proposal is:
(I’ve also filed a github ticket on the CII code about the ambiguity.)
Now I know that some of you are probably asking yourselves, but what about the other concern?
There are two aspects to the concern, though.
crypto_tls12 The software produced by the project SHOULD/MUST, if it supports or uses TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL. If the software does not use TLS, select 'not applicable' (N/A).
crypto_used_network The software produced by the project SHOULD/MUST support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 SHOULD be disabled by default, and only enabled if the user specifically configures it. If the software produced by the project does not support network comunications, select 'not applicable' (N/A).
Both of these are SHOULD questions at the Silver level, and MUST questions at the Gold level.
Do we think that these are worth focusing on next? Since they keep coming up, I think this should be the order of the next 6 weeks’ worth of focus topics.
CII Badging Focus Topics order 1) crypto_certificate_verification The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A). 2) crypto_used_network The software produced by the project SHOULD support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 SHOULD be disabled by default, and only enabled if the user specifically configures it. If the software produced by the project does not support network comunications, select 'not applicable' (N/A). 3) crypto_tls12 The software produced by the project MUST, if it supports or uses TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL. If the software does not use TLS, select 'not applicable' (N/A). 4) crypto_credential_agility The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replacement them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select 'not applicable' (N/A). 5) crypto_verification_private The software produced by the project MUST, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies). If the software does not use TLS, select 'not applicable' (N/A).
I’ll post updated slides shortly with the ambiguity dealt with.
Tony
From: "natacha.mach@..." <natacha.mach@...>
Hello,
Many thanks for your answer.
Regarding the following statement: "The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A)."
==> the "not applicable", in my understanding / opinion should not be possible. TLS should be mandatory, with no other option. If TLS is not possible then the solution is not comptible and the statement unmet.
What do you think?
best regards Natacha
De : HANSEN, TONY L [tony@...] Thank you for your email, Natacha.
These are both very important considerations, and they are covered under other CII topics:
The comment about hashing passwords is covered under the CII topic [crypto_password_storage]:
If the software produced by the project causes the storing of passwords for authentication of external users, the passwords MUST be stored as iterated hashes with a per-user salt by using a key stretching (iterated) algorithm (e.g., PBKDF2, Bcrypt or Scrypt).
The comment about TLS certification verification is covered under the CII topic [crypto_certificate_verification]:
The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).
There is another thread on the [onap-seccom] mailing list that is focusing on the [crypto_certificate_verification] CII topic. Please take a look there and make sure that your concerns regarding certification verification are being sufficiently addressed.
Thank you again for your email, Natacha.
Tony
From: "natacha.mach@..." <natacha.mach@...>
Hello
Thanks for these informations.
i have 2 comments / questions: - The storage of password must be hashed. - regarding the following statement: If your project software uses TLS, but its default mode is NOT to do certificate verification against a locally maintained list of Certificate Authority certificates.
==> is TLS is available, the certificate verification should be mandatory.
What do you think?
Regards Natacha
De :
onap-seccom@... [onap-seccom@...] de la part de Tony Hansen [tony@...] This message focuses on [crypto_credential_agility].
Reminder about the CII text:
[crypto_credential_agility] The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replacement them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select 'not applicable' (N/A).
My take is that this one covers both the credentials needed to access remote services by the application AND the credentials used for authentication of others connecting to the application.
One aspect is that if you have passwords (or hashes of the passwords, etc), should be saved in the a different file from where other configuration values are stored.
Additional discussion is welcome.
Tony
From: "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Question(s), Tony,
. . .
Agility 1. Are you talking about storing Credentials, etc, of the App itself, or Clients a. By “Compile” are you talking about not Hard Coding Passwords in Source (i.e. .js, java, .c, .cpp, whatever) files. b. Or are we realizing that Containers essentially Freeze what used to be dynamic configs, so you have to plan for updates. i. Does “Use docker/kubectl Container Copy instructions” meet this goal? ii. The constant Top priority of “Start from Scratch” makes this difficult, of course. c. If Client Creds, it should be pointed out that Apps can use Externalization of Client Creds, which is, of course, the point of AAF (sorry for the plug)
. . .
-- Jonathan Gathman Principled-System Architect ATO Tech Dev/SEAT/Platform Architecture and Technology Management
AT&T Services, Inc. m 314-550-3312 | jonathan.gathman@...
From: "HANSEN, TONY L" <tony@...>
Here are the next few items that I think we need to work on with respect to moving forward with CII badging. These three have lots of projects marked [?] under the Silver level.
[crypto_certificate_verification] The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).
[crypto_credential_agility] The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replacement them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select 'not applicable' (N/A).
[crypto_verification_private] The software produced by the project MUST, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies). If the software does not use TLS, select 'not applicable' (N/A).
As discussed at DDF, the idea is that we would
Week 1 Introduce a topic at the PTL meeting with instructions. We give stats on how many projects that have answered this question already. Week 2 One week later, we check to see what progress there is. Give kudos to those who have made progress. We file JIRA tickets on those projects that have not given any answer. Introduce the next topic, etc Week 3 We bump up the priority on those tickets.
So, for next week’s meeting, here are instructions for [crypto certificate verification]. Comments are welcome.
[crypto_certificate_verification] The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
|
|