Date   

Communication matrix

natacha.mach@...
 

Hello,

As discussed during the SECCOM of last week, i am sharing with you a proposal regarding the YAML file for the communication matrix work item.

Please share your comments, and then we can propose it to the PTLs.

Many thanks and best regards
Natacha
_________________________________________________________________________________________________________________________

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.


Re: next steps with CII -- focus on crypto_credential_agility

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@...]
Envoyé : jeudi 20 juin 2019 14:27
À : MACH Natacha TGI/OLS; GATHMAN, JONATHAN C; onap-seccom@...
Cc : PAWLAK Pawel O-PL; ZWARICO, AMY; CLOSE, PIERRE
Objet : Re: [Onap-seccom] next steps with CII -- focus on crypto_credential_agility

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@...>
Date: Thursday, June 20, 2019 at 5:41 AM
To: "HANSEN, TONY L" <tony@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>, "onap-seccom@..." <onap-seccom@...>
Cc: PAWLAK Pawel O-PL <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: RE:[Onap-seccom] next steps with CII -- focus on crypto_credential_agility

 

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.

  • Click [Unmet]
  • FILE A JIRA against your project
  • In the description, explain what you don’t do
  • Include the current date at the end of your explanation, as in [2019/06/24]
  • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
  • Include the JIRA ticket number(s) in your answer.

 

==> 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@...]
Envoyé : jeudi 20 juin 2019 05:34
À : GATHMAN, JONATHAN C; onap-seccom@...
Cc : PAWLAK Pawel O-PL; ZWARICO, AMY; CLOSE, PIERRE
Objet : Re: [Onap-seccom] next steps with CII -- focus on crypto_credential_agility

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.

 

  1. Correct, no hard coding of passwords within the source code.
  2. Good questions on containers. I’m not sure what the answers are.
    1. Kubernetes secrets would probably satisfy the requirement.
  1. It seems that AAF would be a perfectly reasonable way to satisfy this requirement.

 

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@...>
Date: Wednesday, June 19, 2019 at 6:45 AM
To: "HANSEN, TONY L" <tony@...>, "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: Re: next steps with CII

 

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@...>
Date: Tuesday, June 18, 2019 at 11:49 AM
To: "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Subject: next steps with CII

 

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.

 

  • This week’s CII issue is

[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).

  • Visit your project page, and login. (If necessary, go to bestpractices.coreinfrastructure.org and do a search.)
  • Click on the silver button near the top where it says “You can also view your [silver] or [gold] level criteria.”
  • Click the [Edit] button at the top.
  • Scroll to the bottom and click on the v Security banner. Search for “The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS”
  • This question is about places in your software where you invoke external APIs, such as HTTP REST calls or database queries or LDAP.
    • If your project software does not make any external API calls, then select “not applicable”
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes its architecture.
    • If your project software does NOT use TLS for ANY of your external API calls, then select “not applicable”.
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • If your project software uses TLS, and its default mode is to do certification verification against a locally maintained list of Certificate Authority certificates.
      • Click [Met]
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • 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.
      • Click [Unmet]
      • FILE A JIRA against your project
      • In the description, explain what you don’t do
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
      • Include the JIRA ticket number(s) in your answer.
    • If some of your software meets the above but other parts do not:
      • Select [Unmet]
      • Include an explanation in the description for each part, following the above instructions.
    • If some of your software meets the above, but other parts do not use TLS,
      • Select [Met]
      • Include an explanation in the description for each part, following the aboe instructions.
  • VERY IMPORTANT: Click one of the green buttons that say [Save (and exit)] or [Save (and continue)]

_________________________________________________________________________________________________________________________
 
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.


Re: next steps with CII -- focus on crypto_credential_agility

Tony Hansen
 

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@...>
Date: Thursday, June 20, 2019 at 5:41 AM
To: "HANSEN, TONY L" <tony@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>, "onap-seccom@..." <onap-seccom@...>
Cc: PAWLAK Pawel O-PL <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: RE:[Onap-seccom] next steps with CII -- focus on crypto_credential_agility

 

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.

  • Click [Unmet]
  • FILE A JIRA against your project
  • In the description, explain what you don’t do
  • Include the current date at the end of your explanation, as in [2019/06/24]
  • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
  • Include the JIRA ticket number(s) in your answer.

 

==> 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@...]
Envoyé : jeudi 20 juin 2019 05:34
À : GATHMAN, JONATHAN C; onap-seccom@...
Cc : PAWLAK Pawel O-PL; ZWARICO, AMY; CLOSE, PIERRE
Objet : Re: [Onap-seccom] next steps with CII -- focus on crypto_credential_agility

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.

 

  1. Correct, no hard coding of passwords within the source code.
  2. Good questions on containers. I’m not sure what the answers are.
    1. Kubernetes secrets would probably satisfy the requirement.
  1. It seems that AAF would be a perfectly reasonable way to satisfy this requirement.

 

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@...>
Date: Wednesday, June 19, 2019 at 6:45 AM
To: "HANSEN, TONY L" <tony@...>, "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: Re: next steps with CII

 

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@...>
Date: Tuesday, June 18, 2019 at 11:49 AM
To: "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Subject: next steps with CII

 

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.

 

  • This week’s CII issue is

[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).

  • Visit your project page, and login. (If necessary, go to bestpractices.coreinfrastructure.org and do a search.)
  • Click on the silver button near the top where it says “You can also view your [silver] or [gold] level criteria.”
  • Click the [Edit] button at the top.
  • Scroll to the bottom and click on the v Security banner. Search for “The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS”
  • This question is about places in your software where you invoke external APIs, such as HTTP REST calls or database queries or LDAP.
    • If your project software does not make any external API calls, then select “not applicable”
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes its architecture.
    • If your project software does NOT use TLS for ANY of your external API calls, then select “not applicable”.
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • If your project software uses TLS, and its default mode is to do certification verification against a locally maintained list of Certificate Authority certificates.
      • Click [Met]
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • 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.
      • Click [Unmet]
      • FILE A JIRA against your project
      • In the description, explain what you don’t do
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
      • Include the JIRA ticket number(s) in your answer.
    • If some of your software meets the above but other parts do not:
      • Select [Unmet]
      • Include an explanation in the description for each part, following the above instructions.
    • If some of your software meets the above, but other parts do not use TLS,
      • Select [Met]
      • Include an explanation in the description for each part, following the aboe instructions.
  • VERY IMPORTANT: Click one of the green buttons that say [Save (and exit)] or [Save (and continue)]

_________________________________________________________________________________________________________________________
 
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.


Re: next steps with CII -- focus on crypto_credential_agility

Jonathan Gathman <jonathan.gathman@...>
 

I have thought about this over the years doing “AAF/CADI”.  Hopefully, the solution that exists with AAF/CADI may help frame the thoughts.

 

AXIOM: All decryption must start from initializing information

COROLLARY 1: This initializing information must take the form of Something You Have, or Something You Know

COROLLARY 2: It is impractical to query a person each and every time a Process in a system needs to start.

COROLLARY 3: Since a Computer doesn’t “have” anything but access to storage, ultimately, you must put some sort of key on disk/chip *

 

Given this Axiom and these Corollaries, AAF/CADI solves this in this way. 

 

For any given Namespace (Application) configuration, we can generate a “keyfile”.

 

Ex: org.onap.aai.keyfile

 

This contains a AES-256 level key which is, of course Symmetrical.  Immediately upon creation, is set to “400” for Unix Systems, which denies access to any User on a UNIX based system except the User himself and root (O/S level Access Control)

 

This keyfile is used to encrypt/decrypt passwords contained in Property Files

 

These can be put in manually, or can be generated, as we do with AAF Certman Generation

 

Ex: When AAF Agent generates Certs, typical scenario is to encase the Private key and Trust Chain into a PKCS12 file (.p12)

 

Therefore, Agent (real time) for aai

 

  1. Gets Cert and Private Key from Certman Process
  2. Generates a Password
  3. Creates the org.onap.aai.p12 file using Password
  4. Adds Private Key and Certs (Trust Chain)
  5. Writes to disk
  6. Encrypts the Password using org.onap.aai.keyfile
  7. Saves the Encrypted password into org.onap.aai.cred.props in the form “key_password=enc:<encrypted key>”

 

What exists, therefore, is a set of files on the disk, in a well known configuration directory (In ONAP K8S, I have standardized on “/opt/app/osaaf/etc”)

If you watched one of the demos, these are what were created.

400   org.onap.aai.keyfile

640   org.onap.aai.p12

640   org.onap.aai.cred.props

 

(more generated, but these are the only ones outlined)

 

*NOTE: There are some efforts to expand the list of “Something a Computer Has”.

  • Intel has provided ONAP with Chip level storage based on PKCS11.  I personally do not know how this can be applied to Kubernetes, whose main function is to remove Services from any direct access to hardware or dependency on it.
  • Intel has provide the SMS service to ONAP.  However, in order to securely access, the App still needs to be able to get an initial key from disk, so it solves some issues, but still requires something like the above to get the APP’s Credentials.

 

 

 

-- 

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@...>
Date: Wednesday, June 19, 2019 at 10:34 PM
To: "GATHMAN, JONATHAN C" <jonathan.gathman@...>, "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: Re: next steps with CII -- focus on crypto_credential_agility

 

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.

 

  1. Correct, no hard coding of passwords within the source code.
  2. Good questions on containers. I’m not sure what the answers are.
    1. Kubernetes secrets would probably satisfy the requirement.
  3. It seems that AAF would be a perfectly reasonable way to satisfy this requirement.

 

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@...>
Date: Wednesday, June 19, 2019 at 6:45 AM
To: "HANSEN, TONY L" <tony@...>, "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: Re: next steps with CII

 

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.

    1. 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@...>
Date: Tuesday, June 18, 2019 at 11:49 AM
To: "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Subject: next steps with CII

 

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.

 

  • This week’s CII issue is

[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).

  • Visit your project page, and login. (If necessary, go to bestpractices.coreinfrastructure.org and do a search.)
  • Click on the silver button near the top where it says “You can also view your [silver] or [gold] level criteria.”
  • Click the [Edit] button at the top.
  • Scroll to the bottom and click on the v Security banner. Search for “The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS”
  • This question is about places in your software where you invoke external APIs, such as HTTP REST calls or database queries or LDAP.
    • If your project software does not make any external API calls, then select “not applicable”
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes its architecture.
    • If your project software does NOT use TLS for ANY of your external API calls, then select “not applicable”.
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • If your project software uses TLS, and its default mode is to do certification verification against a locally maintained list of Certificate Authority certificates.
      • Click [Met]
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • 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.
      • Click [Unmet]
      • FILE A JIRA against your project
      • In the description, explain what you don’t do
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
      • Include the JIRA ticket number(s) in your answer.
    • If some of your software meets the above but other parts do not:
      • Select [Unmet]
      • Include an explanation in the description for each part, following the above instructions.
    • If some of your software meets the above, but other parts do not use TLS,
      • Select [Met]
      • Include an explanation in the description for each part, following the aboe instructions.
  • VERY IMPORTANT: Click one of the green buttons that say [Save (and exit)] or [Save (and continue)]


Re: next steps with CII -- focus on crypto_credential_agility

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.
  • Click [Unmet]
  • FILE A JIRA against your project
  • In the description, explain what you don’t do
  • Include the current date at the end of your explanation, as in [2019/06/24]
  • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
  • Include the JIRA ticket number(s) in your answer.

==> 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@...]
Envoyé : jeudi 20 juin 2019 05:34
À : GATHMAN, JONATHAN C; onap-seccom@...
Cc : PAWLAK Pawel O-PL; ZWARICO, AMY; CLOSE, PIERRE
Objet : Re: [Onap-seccom] next steps with CII -- focus on crypto_credential_agility

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.

 

  1. Correct, no hard coding of passwords within the source code.
  2. Good questions on containers. I’m not sure what the answers are.
    1. Kubernetes secrets would probably satisfy the requirement.
  3. It seems that AAF would be a perfectly reasonable way to satisfy this requirement.

 

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@...>
Date: Wednesday, June 19, 2019 at 6:45 AM
To: "HANSEN, TONY L" <tony@...>, "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: Re: next steps with CII

 

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.

    1. 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@...>
Date: Tuesday, June 18, 2019 at 11:49 AM
To: "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Subject: next steps with CII

 

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.

 

  • This week’s CII issue is

[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).

  • Visit your project page, and login. (If necessary, go to bestpractices.coreinfrastructure.org and do a search.)
  • Click on the silver button near the top where it says “You can also view your [silver] or [gold] level criteria.”
  • Click the [Edit] button at the top.
  • Scroll to the bottom and click on the v Security banner. Search for “The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS”
  • This question is about places in your software where you invoke external APIs, such as HTTP REST calls or database queries or LDAP.
    • If your project software does not make any external API calls, then select “not applicable”
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes its architecture.
    • If your project software does NOT use TLS for ANY of your external API calls, then select “not applicable”.
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • If your project software uses TLS, and its default mode is to do certification verification against a locally maintained list of Certificate Authority certificates.
      • Click [Met]
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • 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.
      • Click [Unmet]
      • FILE A JIRA against your project
      • In the description, explain what you don’t do
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
      • Include the JIRA ticket number(s) in your answer.
    • If some of your software meets the above but other parts do not:
      • Select [Unmet]
      • Include an explanation in the description for each part, following the above instructions.
    • If some of your software meets the above, but other parts do not use TLS,
      • Select [Met]
      • Include an explanation in the description for each part, following the aboe instructions.
  • VERY IMPORTANT: Click one of the green buttons that say [Save (and exit)] or [Save (and continue)]
_________________________________________________________________________________________________________________________

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.


Re: next steps with CII -- focus on crypto_credential_agility

Tony Hansen
 

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.

 

  1. Correct, no hard coding of passwords within the source code.
  2. Good questions on containers. I’m not sure what the answers are.
    1. Kubernetes secrets would probably satisfy the requirement.
  3. It seems that AAF would be a perfectly reasonable way to satisfy this requirement.

 

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@...>
Date: Wednesday, June 19, 2019 at 6:45 AM
To: "HANSEN, TONY L" <tony@...>, "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: Re: next steps with CII

 

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.

    1. 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@...>
Date: Tuesday, June 18, 2019 at 11:49 AM
To: "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Subject: next steps with CII

 

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.

 

  • This week’s CII issue is

[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).

  • Visit your project page, and login. (If necessary, go to bestpractices.coreinfrastructure.org and do a search.)
  • Click on the silver button near the top where it says “You can also view your [silver] or [gold] level criteria.”
  • Click the [Edit] button at the top.
  • Scroll to the bottom and click on the v Security banner. Search for “The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS”
  • This question is about places in your software where you invoke external APIs, such as HTTP REST calls or database queries or LDAP.
    • If your project software does not make any external API calls, then select “not applicable”
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes its architecture.
    • If your project software does NOT use TLS for ANY of your external API calls, then select “not applicable”.
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • If your project software uses TLS, and its default mode is to do certification verification against a locally maintained list of Certificate Authority certificates.
      • Click [Met]
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • 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.
      • Click [Unmet]
      • FILE A JIRA against your project
      • In the description, explain what you don’t do
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
      • Include the JIRA ticket number(s) in your answer.
    • If some of your software meets the above but other parts do not:
      • Select [Unmet]
      • Include an explanation in the description for each part, following the above instructions.
    • If some of your software meets the above, but other parts do not use TLS,
      • Select [Met]
      • Include an explanation in the description for each part, following the aboe instructions.
  • VERY IMPORTANT: Click one of the green buttons that say [Save (and exit)] or [Save (and continue)]


Re: next steps with CII -- focus on crypto_certificate_verification

Tony Hansen
 

Great summary, Jonathan. I like it. :)

 

I realized that this statement hadn’t been explicitly listed before:

 

If the remote API has both non-TLS and TLS endpoints/options available, make certain that the TLS endpoint is being used. For example, if the remote API can be invoked either with HTTP or HTTPS, make certain that HTTPS is being used.

 

Thanks again for the discussion on this CII issue. It will make the conversation with the PTLs easier.

 

Tony

 

From: "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Date: Wednesday, June 19, 2019 at 8:50 AM
To: "HANSEN, TONY L" <tony@...>, "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: Re: next steps with CII -- focus on crypto_certificate_verification

 

Great Answers, Tony,

  If I could summarize, it is about validating that TLS is 1) used where possible 2) is not disabled (since it is easy in some mechanisms.

 

Appreciate it

 

-- 

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@...>
Date: Wednesday, June 19, 2019 at 7:46 AM
To: "GATHMAN, JONATHAN C" <jonathan.gathman@...>, "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: Re: next steps with CII -- focus on crypto_certificate_verification

 

Thank you all for your responses.

 

Jonathan, the answer to most of these questions SHOULD lie in the realm of no brainers / standard use. But let’s look at [crypto_certificate_verification] for a moment.

 

  • This is about machine-to-machine calls to remote services from within the project’s code to an external service, and not about calls INTO a project’s code (either machine-to-machine or user-to-machine).

 

  • Trust chain (aka CA Server Certificate Chain):
    • If the server on the other end is using a cert from a public trusted CA, then you need a trust chain for that CA.
    • If the server on the other end is using a cert from another CA, then you need a trust chain for that CA.
    • The key is that you need the right trust chain for whatever language you’re dealing with to reach the servers you’re going to.
    • This one should seriously be in the no-brainer category.
    • But what if they turned off verification because they didn’t have access to the remote site’s trust chain? Or didn’t know how to add support for it in the language that they are using?

 

  • Language issues:
    • If Java makes it hard to avoid verification, that’s a good thing.
      • The PTL should check their code base to see if they did it the right way or not.
    • With curl, it is SO easy to just toss the -k into your scripts and forget that you did it.
      • The PTL should check their code base to see if they did it the right way or not.
    • With the python requests library (which most people use these days), you can similarly use a -k-equivalent or do it the right way.
      • The PTL should check their code base to see if they did it the right way or not.
    • The same thing goes for other languages.
      • The PTL should check their code base to see if they did it the right way or not.
    • The PTL can also delegate the code checking.

 

It would be useful for the PTLs to know what to look for in the code. For example, guidance like this would be useful:

If you know your code uses shell scripts and invokes curl or wget, make certain that curl does not use the -k or --insecure option and that wget does not use the --no-check-certificate option.

 

The end result is that if they are NOT doing the right thing with their trust chain OR avoiding verification for any of a myriad of reasons, they need to write JIRA tickets to fix their code.

 

Bottom line: our job is to get them to improve their code. Getting the silver star or gold star from the CII badge is truly secondary.

 

I’ll address the other CII issues separately.

 

                Tony

 

From: "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Date: Wednesday, June 19, 2019 at 6:45 AM
To: "HANSEN, TONY L" <tony@...>, "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: Re: next steps with CII

 

Question(s), Tony,

 

First, I’m curious as to context.  Are you specifically drawing our Person to App or App to App communications?  Or, given the nature of what ONAP addresses, are you trying to leave room for Communications are a more network level?  When I’m reading these, some of them seen either no-brainers or are standard use for out-of-the-box Client/Server solutions i.e. Java (HTTP/S) with TLS. 

 

Are we trying to codify  what might be stated more baldly “Use the security provided with valid CA structure and don’t disable it” and “Don’t hardcode credentials in Source, and realize that Containers ultimately compiled… you need to provide methods for changing creds”?

 

Here are more detailed questions that I’m hoping will draw out the intentions.

 

Verification

  1. When you are saying TLS verification, are you talking mostly about making sure TLS is running normally, default behavior?    What I mean is that

a.      In Java, for instance, the TLS connections validate all the Certificates in a Trust Chain against Trusted CAs in your Truststore.  You have to go to great pains to, for instance, turn off DNS checking, etc.

b.      In “curl” (do we use curl other than as a convenient Client?) you have to disable TLS Trust with “-k”…

  1. Are you talking about only using Certificates with a Trust Chain to an established CA (or public Trusted CAs)?

 

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.

    1. 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)

 

Verification

  1. This seems to be back to TLS focus, specifically Client.

a.      Are you saying that Client Software needs to first determine if the underyling connection (typically invisible to the top-level client code) is TLS? 

b.      Clients can only Communicate in the manner that the Service Side dictates.

c.       Given this is done at (to quote OSI Level), at a lower communication Layer, what is the practical way for an App to ensure this.

d.      Example: Is it enough to reject any URLs as a client that start with “http:” but not “https”?

 

 

 

     

 

-- 

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@...>
Date: Tuesday, June 18, 2019 at 11:49 AM
To: "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Subject: next steps with CII

 

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.

 

  • This week’s CII issue is

[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).

  • Visit your project page, and login. (If necessary, go to bestpractices.coreinfrastructure.org and do a search.)
  • Click on the silver button near the top where it says “You can also view your [silver] or [gold] level criteria.”
  • Click the [Edit] button at the top.
  • Scroll to the bottom and click on the v Security banner. Search for “The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS”
  • This question is about places in your software where you invoke external APIs, such as HTTP REST calls or database queries or LDAP.
    • If your project software does not make any external API calls, then select “not applicable”
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes its architecture.
    • If your project software does NOT use TLS for ANY of your external API calls, then select “not applicable”.
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • If your project software uses TLS, and its default mode is to do certification verification against a locally maintained list of Certificate Authority certificates.
      • Click [Met]
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • 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.
      • Click [Unmet]
      • FILE A JIRA against your project
      • In the description, explain what you don’t do
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
      • Include the JIRA ticket number(s) in your answer.
    • If some of your software meets the above but other parts do not:
      • Select [Unmet]
      • Include an explanation in the description for each part, following the above instructions.
    • If some of your software meets the above, but other parts do not use TLS,
      • Select [Met]
      • Include an explanation in the description for each part, following the aboe instructions.
  • VERY IMPORTANT: Click one of the green buttons that say [Save (and exit)] or [Save (and continue)]


Re: next steps with CII -- focus on crypto_certificate_verification

Jonathan Gathman <jonathan.gathman@...>
 

Great Answers, Tony,

  If I could summarize, it is about validating that TLS is 1) used where possible 2) is not disabled (since it is easy in some mechanisms.

 

Appreciate it

 

-- 

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@...>
Date: Wednesday, June 19, 2019 at 7:46 AM
To: "GATHMAN, JONATHAN C" <jonathan.gathman@...>, "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: Re: next steps with CII -- focus on crypto_certificate_verification

 

Thank you all for your responses.

 

Jonathan, the answer to most of these questions SHOULD lie in the realm of no brainers / standard use. But let’s look at [crypto_certificate_verification] for a moment.

 

  • This is about machine-to-machine calls to remote services from within the project’s code to an external service, and not about calls INTO a project’s code (either machine-to-machine or user-to-machine).

 

  • Trust chain (aka CA Server Certificate Chain):
    • If the server on the other end is using a cert from a public trusted CA, then you need a trust chain for that CA.
    • If the server on the other end is using a cert from another CA, then you need a trust chain for that CA.
    • The key is that you need the right trust chain for whatever language you’re dealing with to reach the servers you’re going to.
    • This one should seriously be in the no-brainer category.
    • But what if they turned off verification because they didn’t have access to the remote site’s trust chain? Or didn’t know how to add support for it in the language that they are using?

 

  • Language issues:
    • If Java makes it hard to avoid verification, that’s a good thing.
      • The PTL should check their code base to see if they did it the right way or not.
    • With curl, it is SO easy to just toss the -k into your scripts and forget that you did it.
      • The PTL should check their code base to see if they did it the right way or not.
    • With the python requests library (which most people use these days), you can similarly use a -k-equivalent or do it the right way.
      • The PTL should check their code base to see if they did it the right way or not.
    • The same thing goes for other languages.
      • The PTL should check their code base to see if they did it the right way or not.
    • The PTL can also delegate the code checking.

 

It would be useful for the PTLs to know what to look for in the code. For example, guidance like this would be useful:

If you know your code uses shell scripts and invokes curl or wget, make certain that curl does not use the -k or --insecure option and that wget does not use the --no-check-certificate option.

 

The end result is that if they are NOT doing the right thing with their trust chain OR avoiding verification for any of a myriad of reasons, they need to write JIRA tickets to fix their code.

 

Bottom line: our job is to get them to improve their code. Getting the silver star or gold star from the CII badge is truly secondary.

 

I’ll address the other CII issues separately.

 

                Tony

 

From: "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Date: Wednesday, June 19, 2019 at 6:45 AM
To: "HANSEN, TONY L" <tony@...>, "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: Re: next steps with CII

 

Question(s), Tony,

 

First, I’m curious as to context.  Are you specifically drawing our Person to App or App to App communications?  Or, given the nature of what ONAP addresses, are you trying to leave room for Communications are a more network level?  When I’m reading these, some of them seen either no-brainers or are standard use for out-of-the-box Client/Server solutions i.e. Java (HTTP/S) with TLS. 

 

Are we trying to codify  what might be stated more baldly “Use the security provided with valid CA structure and don’t disable it” and “Don’t hardcode credentials in Source, and realize that Containers ultimately compiled… you need to provide methods for changing creds”?

 

Here are more detailed questions that I’m hoping will draw out the intentions.

 

Verification

  1. When you are saying TLS verification, are you talking mostly about making sure TLS is running normally, default behavior?    What I mean is that

a.      In Java, for instance, the TLS connections validate all the Certificates in a Trust Chain against Trusted CAs in your Truststore.  You have to go to great pains to, for instance, turn off DNS checking, etc.

b.      In “curl” (do we use curl other than as a convenient Client?) you have to disable TLS Trust with “-k”…

  1. Are you talking about only using Certificates with a Trust Chain to an established CA (or public Trusted CAs)?

 

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.

    1. 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)

 

Verification

  1. This seems to be back to TLS focus, specifically Client.

a.      Are you saying that Client Software needs to first determine if the underyling connection (typically invisible to the top-level client code) is TLS? 

b.      Clients can only Communicate in the manner that the Service Side dictates.

c.       Given this is done at (to quote OSI Level), at a lower communication Layer, what is the practical way for an App to ensure this.

d.      Example: Is it enough to reject any URLs as a client that start with “http:” but not “https”?

 

 

 

     

 

-- 

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@...>
Date: Tuesday, June 18, 2019 at 11:49 AM
To: "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Subject: next steps with CII

 

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.

 

  • This week’s CII issue is

[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).

  • Visit your project page, and login. (If necessary, go to bestpractices.coreinfrastructure.org and do a search.)
  • Click on the silver button near the top where it says “You can also view your [silver] or [gold] level criteria.”
  • Click the [Edit] button at the top.
  • Scroll to the bottom and click on the v Security banner. Search for “The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS”
  • This question is about places in your software where you invoke external APIs, such as HTTP REST calls or database queries or LDAP.
    • If your project software does not make any external API calls, then select “not applicable”
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes its architecture.
    • If your project software does NOT use TLS for ANY of your external API calls, then select “not applicable”.
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • If your project software uses TLS, and its default mode is to do certification verification against a locally maintained list of Certificate Authority certificates.
      • Click [Met]
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • 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.
      • Click [Unmet]
      • FILE A JIRA against your project
      • In the description, explain what you don’t do
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
      • Include the JIRA ticket number(s) in your answer.
    • If some of your software meets the above but other parts do not:
      • Select [Unmet]
      • Include an explanation in the description for each part, following the above instructions.
    • If some of your software meets the above, but other parts do not use TLS,
      • Select [Met]
      • Include an explanation in the description for each part, following the aboe instructions.
  • VERY IMPORTANT: Click one of the green buttons that say [Save (and exit)] or [Save (and continue)]


Re: next steps with CII -- focus on crypto_certificate_verification

Tony Hansen
 

Thank you all for your responses.

 

Jonathan, the answer to most of these questions SHOULD lie in the realm of no brainers / standard use. But let’s look at [crypto_certificate_verification] for a moment.

 

  • This is about machine-to-machine calls to remote services from within the project’s code to an external service, and not about calls INTO a project’s code (either machine-to-machine or user-to-machine).

 

  • Trust chain (aka CA Server Certificate Chain):
    • If the server on the other end is using a cert from a public trusted CA, then you need a trust chain for that CA.
    • If the server on the other end is using a cert from another CA, then you need a trust chain for that CA.
    • The key is that you need the right trust chain for whatever language you’re dealing with to reach the servers you’re going to.
    • This one should seriously be in the no-brainer category.
    • But what if they turned off verification because they didn’t have access to the remote site’s trust chain? Or didn’t know how to add support for it in the language that they are using?

 

  • Language issues:
    • If Java makes it hard to avoid verification, that’s a good thing.
      • The PTL should check their code base to see if they did it the right way or not.
    • With curl, it is SO easy to just toss the -k into your scripts and forget that you did it.
      • The PTL should check their code base to see if they did it the right way or not.
    • With the python requests library (which most people use these days), you can similarly use a -k-equivalent or do it the right way.
      • The PTL should check their code base to see if they did it the right way or not.
    • The same thing goes for other languages.
      • The PTL should check their code base to see if they did it the right way or not.
    • The PTL can also delegate the code checking.

 

It would be useful for the PTLs to know what to look for in the code. For example, guidance like this would be useful:

If you know your code uses shell scripts and invokes curl or wget, make certain that curl does not use the -k or --insecure option and that wget does not use the --no-check-certificate option.

 

The end result is that if they are NOT doing the right thing with their trust chain OR avoiding verification for any of a myriad of reasons, they need to write JIRA tickets to fix their code.

 

Bottom line: our job is to get them to improve their code. Getting the silver star or gold star from the CII badge is truly secondary.

 

I’ll address the other CII issues separately.

 

                Tony

 

From: "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Date: Wednesday, June 19, 2019 at 6:45 AM
To: "HANSEN, TONY L" <tony@...>, "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: Re: next steps with CII

 

Question(s), Tony,

 

First, I’m curious as to context.  Are you specifically drawing our Person to App or App to App communications?  Or, given the nature of what ONAP addresses, are you trying to leave room for Communications are a more network level?  When I’m reading these, some of them seen either no-brainers or are standard use for out-of-the-box Client/Server solutions i.e. Java (HTTP/S) with TLS. 

 

Are we trying to codify  what might be stated more baldly “Use the security provided with valid CA structure and don’t disable it” and “Don’t hardcode credentials in Source, and realize that Containers ultimately compiled… you need to provide methods for changing creds”?

 

Here are more detailed questions that I’m hoping will draw out the intentions.

 

Verification

  1. When you are saying TLS verification, are you talking mostly about making sure TLS is running normally, default behavior?    What I mean is that

a.      In Java, for instance, the TLS connections validate all the Certificates in a Trust Chain against Trusted CAs in your Truststore.  You have to go to great pains to, for instance, turn off DNS checking, etc.

b.      In “curl” (do we use curl other than as a convenient Client?) you have to disable TLS Trust with “-k”…

  1. Are you talking about only using Certificates with a Trust Chain to an established CA (or public Trusted CAs)?

 

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.

    1. 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)

 

Verification

  1. This seems to be back to TLS focus, specifically Client.

a.      Are you saying that Client Software needs to first determine if the underyling connection (typically invisible to the top-level client code) is TLS? 

b.      Clients can only Communicate in the manner that the Service Side dictates.

c.       Given this is done at (to quote OSI Level), at a lower communication Layer, what is the practical way for an App to ensure this.

d.      Example: Is it enough to reject any URLs as a client that start with “http:” but not “https”?

 

 

 

     

 

-- 

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@...>
Date: Tuesday, June 18, 2019 at 11:49 AM
To: "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Subject: next steps with CII

 

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.

 

  • This week’s CII issue is

[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).

  • Visit your project page, and login. (If necessary, go to bestpractices.coreinfrastructure.org and do a search.)
  • Click on the silver button near the top where it says “You can also view your [silver] or [gold] level criteria.”
  • Click the [Edit] button at the top.
  • Scroll to the bottom and click on the v Security banner. Search for “The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS”
  • This question is about places in your software where you invoke external APIs, such as HTTP REST calls or database queries or LDAP.
    • If your project software does not make any external API calls, then select “not applicable”
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes its architecture.
    • If your project software does NOT use TLS for ANY of your external API calls, then select “not applicable”.
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • If your project software uses TLS, and its default mode is to do certification verification against a locally maintained list of Certificate Authority certificates.
      • Click [Met]
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • 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.
      • Click [Unmet]
      • FILE A JIRA against your project
      • In the description, explain what you don’t do
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
      • Include the JIRA ticket number(s) in your answer.
    • If some of your software meets the above but other parts do not:
      • Select [Unmet]
      • Include an explanation in the description for each part, following the above instructions.
    • If some of your software meets the above, but other parts do not use TLS,
      • Select [Met]
      • Include an explanation in the description for each part, following the aboe instructions.
  • VERY IMPORTANT: Click one of the green buttons that say [Save (and exit)] or [Save (and continue)]


Re: next steps with CII

Jonathan Gathman <jonathan.gathman@...>
 

Question(s), Tony,

 

First, I’m curious as to context.  Are you specifically drawing our Person to App or App to App communications?  Or, given the nature of what ONAP addresses, are you trying to leave room for Communications are a more network level?  When I’m reading these, some of them seen either no-brainers or are standard use for out-of-the-box Client/Server solutions i.e. Java (HTTP/S) with TLS. 

 

Are we trying to codify  what might be stated more baldly “Use the security provided with valid CA structure and don’t disable it” and “Don’t hardcode credentials in Source, and realize that Containers ultimately compiled… you need to provide methods for changing creds”?

 

Here are more detailed questions that I’m hoping will draw out the intentions.

 

Verification

  1. When you are saying TLS verification, are you talking mostly about making sure TLS is running normally, default behavior?    What I mean is that
    1. In Java, for instance, the TLS connections validate all the Certificates in a Trust Chain against Trusted CAs in your Truststore.  You have to go to great pains to, for instance, turn off DNS checking, etc.
    2. In “curl” (do we use curl other than as a convenient Client?) you have to disable TLS Trust with “-k”…
  2. Are you talking about only using Certificates with a Trust Chain to an established CA (or public Trusted CAs)?

 

Agility

  1. Are you talking about storing Credentials, etc, of the App itself, or Clients
    1. By “Compile” are you talking about not Hard Coding Passwords in Source (i.e. .js, java, .c, .cpp, whatever) files.
    2. 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.

    1. 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)

 

Verification

  1. This seems to be back to TLS focus, specifically Client.
    1. Are you saying that Client Software needs to first determine if the underyling connection (typically invisible to the top-level client code) is TLS? 
    2. Clients can only Communicate in the manner that the Service Side dictates.
    3. Given this is done at (to quote OSI Level), at a lower communication Layer, what is the practical way for an App to ensure this.
    4. Example: Is it enough to reject any URLs as a client that start with “http:” but not “https”?

 

 

 

     

 

-- 

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@...>
Date: Tuesday, June 18, 2019 at 11:49 AM
To: "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Subject: next steps with CII

 

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.

 

  • This week’s CII issue is

[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).

  • Visit your project page, and login. (If necessary, go to bestpractices.coreinfrastructure.org and do a search.)
  • Click on the silver button near the top where it says “You can also view your [silver] or [gold] level criteria.”
  • Click the [Edit] button at the top.
  • Scroll to the bottom and click on the v Security banner. Search for “The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS”
  • This question is about places in your software where you invoke external APIs, such as HTTP REST calls or database queries or LDAP.
    • If your project software does not make any external API calls, then select “not applicable”
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes its architecture.
    • If your project software does NOT use TLS for ANY of your external API calls, then select “not applicable”.
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • If your project software uses TLS, and its default mode is to do certification verification against a locally maintained list of Certificate Authority certificates.
      • Click [Met]
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • 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.
      • Click [Unmet]
      • FILE A JIRA against your project
      • In the description, explain what you don’t do
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
      • Include the JIRA ticket number(s) in your answer.
    • If some of your software meets the above but other parts do not:
      • Select [Unmet]
      • Include an explanation in the description for each part, following the above instructions.
    • If some of your software meets the above, but other parts do not use TLS,
      • Select [Met]
      • Include an explanation in the description for each part, following the aboe instructions.
  • VERY IMPORTANT: Click one of the green buttons that say [Save (and exit)] or [Save (and continue)]


Re: next steps with CII

Pawel Pawlak
 

+1  

@Tony, great proposal, guideline and an action plan!

 

Best regards

 

Paweł Pawlak

 

ONAP SECCOM Chair

Leader in IT & Network Convergent Operations
FT/TGI/OLN/QOP/OST

 

Orange Polska S.A.

Corporate Services Agency

Obrzeżna 7, 02-691 Warszawa
tel. +48 22 699 52 17
fax +48 22 857 99 86
tel. mob. +48 501 501 030

P   Czy musisz drukować tę wiadomość? Pomyśl o środowisku.
__________________________________________________________________
Treść tej wiadomości jest własnością Orange Polska i zawiera informacje stanowiące tajemnicę przedsiębiorstwa Orange Polska. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę, prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. Orange Polska Spółka Akcyjna z siedzibą i adresem w Warszawie (02-326) przy Al. Jerozolimskich 160, wpisana do Rejestru Przedsiębiorców prowadzonego przez Sąd Rejonowy dla m.st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 0000010681; REGON 012100784, NIP 526-02-50-995; z pokrytym w całości kapitałem zakładowym wynoszącym 3.937.072.437 złotych.

 

From: ZWARICO, AMY [mailto:az9121@...]
Sent: Wednesday, June 19, 2019 12:01 AM
To: HANSEN, TONY L; onap-seccom@...
Cc: Pawlak Paweł 3 - Korpo; CLOSE, PIERRE; GATHMAN, JONATHAN C
Subject: RE: next steps with CII

 

+1

 

From: HANSEN, TONY L
Sent: Tuesday, June 18, 2019 11:49 AM
To: onap-seccom@...
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>; ZWARICO, AMY <az9121@...>; CLOSE, PIERRE <pierre.close@...>; GATHMAN, JONATHAN C <jonathan.gathman@...>
Subject: next steps with CII

 

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.

 

  • This week’s CII issue is

[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).

  • Visit your project page, and login. (If necessary, go to bestpractices.coreinfrastructure.org and do a search.)
  • Click on the silver button near the top where it says “You can also view your [silver] or [gold] level criteria.”
  • Click the [Edit] button at the top.
  • Scroll to the bottom and click on the v Security banner. Search for “The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS”
  • This question is about places in your software where you invoke external APIs, such as HTTP REST calls or database queries or LDAP.
    • If your project software does not make any external API calls, then select “not applicable”
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes its architecture.
    • If your project software does NOT use TLS for ANY of your external API calls, then select “not applicable”.
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • If your project software uses TLS, and its default mode is to do certification verification against a locally maintained list of Certificate Authority certificates.
      • Click [Met]
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • 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.
      • Click [Unmet]
      • FILE A JIRA against your project
      • In the description, explain what you don’t do
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
      • Include the JIRA ticket number(s) in your answer.

o   If some of your software meets the above but other parts do not:

§  Select [Unmet]

§  Include an explanation in the description for each part, following the above instructions.

o   If some of your software meets the above, but other parts do not use TLS,

§  Select [Met]

§  Include an explanation in the description for each part, following the aboe instructions.

·         VERY IMPORTANT: Click one of the green buttons that say [Save (and exit)] or [Save (and continue)]


Re: next steps with CII

ZWARICO, AMY <az9121@...>
 

+1

 

From: HANSEN, TONY L
Sent: Tuesday, June 18, 2019 11:49 AM
To: onap-seccom@...
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>; ZWARICO, AMY <az9121@...>; CLOSE, PIERRE <pierre.close@...>; GATHMAN, JONATHAN C <jonathan.gathman@...>
Subject: next steps with CII

 

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.

 

  • This week’s CII issue is

[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).

  • Visit your project page, and login. (If necessary, go to bestpractices.coreinfrastructure.org and do a search.)
  • Click on the silver button near the top where it says “You can also view your [silver] or [gold] level criteria.”
  • Click the [Edit] button at the top.
  • Scroll to the bottom and click on the v Security banner. Search for “The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS”
  • This question is about places in your software where you invoke external APIs, such as HTTP REST calls or database queries or LDAP.
    • If your project software does not make any external API calls, then select “not applicable”
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes its architecture.
    • If your project software does NOT use TLS for ANY of your external API calls, then select “not applicable”.
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • If your project software uses TLS, and its default mode is to do certification verification against a locally maintained list of Certificate Authority certificates.
      • Click [Met]
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • 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.
      • Click [Unmet]
      • FILE A JIRA against your project
      • In the description, explain what you don’t do
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
      • Include the JIRA ticket number(s) in your answer.

o   If some of your software meets the above but other parts do not:

§  Select [Unmet]

§  Include an explanation in the description for each part, following the above instructions.

o   If some of your software meets the above, but other parts do not use TLS,

§  Select [Met]

§  Include an explanation in the description for each part, following the aboe instructions.

·         VERY IMPORTANT: Click one of the green buttons that say [Save (and exit)] or [Save (and continue)]


Re: AAF and Istio questions - for July Time frame

Kiran Kamineni
 

Thanks!

 

-- K i r a n

 

From: GATHMAN, JONATHAN C [mailto:jonathan.gathman@...]
Sent: Tuesday, June 18, 2019 2:15 PM
To: Kamineni, Kiran K <kiran.k.kamineni@...>; onap-seccom@...
Subject: Re: AAF and Istio questions - for July Time frame

 

I included some more notes in the PTL meeting area, but apparently not here.

 

The Helm chart for sample “aaf-hello” (NOT OOM Helm chart) is here:

https://gerrit.onap.org/r/gitweb?p=aaf/authz.git;a=blob_plain;f=auth/helm/aaf-hello/templates/aaf-hello.yaml;hb=HEAD

 

My expectations is the OOM Helm chart won’t be very different, but I can’t put my “Stamp of approval” on it until I’ve actually tried it… and that won’t happen until OOM locks down Dublin, and Resources open up in WindRiver.

 

 

-- 

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: "Kamineni, Kiran K" <kiran.k.kamineni@...>
Date: Tuesday, June 18, 2019 at 2:09 PM
To: "GATHMAN, JONATHAN C" <jonathan.gathman@...>, "onap-seccom@..." <onap-seccom@...>
Subject: RE: AAF and Istio questions - for July Time frame

 

Thanks for the summary!

Can you also send out a pointer to the documentation for “Helm process for AAF auto-generation of certificates”?

 

Thanks,

-- K i r a n

 

From: onap-seccom@... [mailto:onap-seccom@...] On Behalf Of Jonathan Gathman
Sent: Tuesday, June 18, 2019 6:46 AM
To: onap-seccom@...
Subject: [Onap-seccom] AAF and Istio questions - for July Time frame

 

To document the discussions at F2F and Jun 18 SECCOM, I’m writing the email.

 

I need to hold off on in depth discussions until

  • After June (big Deployment in my company)
  • I have OOM Helm process documented and get good path forward for PTLs/Services to utilize AAF Auto-generation of Certificates

 

I do see possibilities of interactions for Systems that want Istio:

 

  • If someone wants to make Istio CA THE CA, AAF is already setup to function as Registration Authority
    • Would need to have standard CA API
      • ONAP for Network is already pushing for CMPv2 support.  It would be best if ISTIO had this API setup for its CA.
  • Istio has, I understand, Interfaces to plug in Authorization, etc.
    • AAF has done many different Authorization Plugins, so having an AAF one available for ISTIO for those who want it seems both doable, and helpful.
  • From a practical standpoint, it would be helpful if Istio can be created/run locally within Minikube.
    • Is that feasible, or would one need a larger Environment to even start Istio?

 

 

-- 

Jonathan Gathman

Principled-System Architect

ATO Tech Dev/SEAT/Platform Architecture and Technology Management

 

AT&T Services, Inc.

m  314-550-3312  |  jonathan.gathman@...

 


Re: AAF and Istio questions - for July Time frame

Jonathan Gathman <jonathan.gathman@...>
 

I included some more notes in the PTL meeting area, but apparently not here.

 

The Helm chart for sample “aaf-hello” (NOT OOM Helm chart) is here:

https://gerrit.onap.org/r/gitweb?p=aaf/authz.git;a=blob_plain;f=auth/helm/aaf-hello/templates/aaf-hello.yaml;hb=HEAD

 

My expectations is the OOM Helm chart won’t be very different, but I can’t put my “Stamp of approval” on it until I’ve actually tried it… and that won’t happen until OOM locks down Dublin, and Resources open up in WindRiver.

 

 

-- 

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: "Kamineni, Kiran K" <kiran.k.kamineni@...>
Date: Tuesday, June 18, 2019 at 2:09 PM
To: "GATHMAN, JONATHAN C" <jonathan.gathman@...>, "onap-seccom@..." <onap-seccom@...>
Subject: RE: AAF and Istio questions - for July Time frame

 

Thanks for the summary!

Can you also send out a pointer to the documentation for “Helm process for AAF auto-generation of certificates”?

 

Thanks,

-- K i r a n

 

From: onap-seccom@... [mailto:onap-seccom@...] On Behalf Of Jonathan Gathman
Sent: Tuesday, June 18, 2019 6:46 AM
To: onap-seccom@...
Subject: [Onap-seccom] AAF and Istio questions - for July Time frame

 

To document the discussions at F2F and Jun 18 SECCOM, I’m writing the email.

 

I need to hold off on in depth discussions until

  • After June (big Deployment in my company)
  • I have OOM Helm process documented and get good path forward for PTLs/Services to utilize AAF Auto-generation of Certificates

 

I do see possibilities of interactions for Systems that want Istio:

 

  • If someone wants to make Istio CA THE CA, AAF is already setup to function as Registration Authority
    • Would need to have standard CA API
      • ONAP for Network is already pushing for CMPv2 support.  It would be best if ISTIO had this API setup for its CA.
  • Istio has, I understand, Interfaces to plug in Authorization, etc.
    • AAF has done many different Authorization Plugins, so having an AAF one available for ISTIO for those who want it seems both doable, and helpful.
  • From a practical standpoint, it would be helpful if Istio can be created/run locally within Minikube.
    • Is that feasible, or would one need a larger Environment to even start Istio?

 

 

-- 

Jonathan Gathman

Principled-System Architect

ATO Tech Dev/SEAT/Platform Architecture and Technology Management

 

AT&T Services, Inc.

m  314-550-3312  |  jonathan.gathman@...

 


Re: AAF and Istio questions - for July Time frame

Kiran Kamineni
 

Thanks for the summary!

Can you also send out a pointer to the documentation for “Helm process for AAF auto-generation of certificates”?

 

Thanks,

-- K i r a n

 

From: onap-seccom@... [mailto:onap-seccom@...] On Behalf Of Jonathan Gathman
Sent: Tuesday, June 18, 2019 6:46 AM
To: onap-seccom@...
Subject: [Onap-seccom] AAF and Istio questions - for July Time frame

 

To document the discussions at F2F and Jun 18 SECCOM, I’m writing the email.

 

I need to hold off on in depth discussions until

  • After June (big Deployment in my company)
  • I have OOM Helm process documented and get good path forward for PTLs/Services to utilize AAF Auto-generation of Certificates

 

I do see possibilities of interactions for Systems that want Istio:

 

  • If someone wants to make Istio CA THE CA, AAF is already setup to function as Registration Authority
    • Would need to have standard CA API
      • ONAP for Network is already pushing for CMPv2 support.  It would be best if ISTIO had this API setup for its CA.
  • Istio has, I understand, Interfaces to plug in Authorization, etc.
    • AAF has done many different Authorization Plugins, so having an AAF one available for ISTIO for those who want it seems both doable, and helpful.
  • From a practical standpoint, it would be helpful if Istio can be created/run locally within Minikube.
    • Is that feasible, or would one need a larger Environment to even start Istio?

 

 

-- 

Jonathan Gathman

Principled-System Architect

ATO Tech Dev/SEAT/Platform Architecture and Technology Management

 

AT&T Services, Inc.

m  314-550-3312  |  jonathan.gathman@...

 


next steps with CII

Tony Hansen
 

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.

 

  • This week’s CII issue is

[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).

  • Visit your project page, and login. (If necessary, go to bestpractices.coreinfrastructure.org and do a search.)
  • Click on the silver button near the top where it says “You can also view your [silver] or [gold] level criteria.”
  • Click the [Edit] button at the top.
  • Scroll to the bottom and click on the v Security banner. Search for “The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS”
  • This question is about places in your software where you invoke external APIs, such as HTTP REST calls or database queries or LDAP.
    • If your project software does not make any external API calls, then select “not applicable”
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes its architecture.
    • If your project software does NOT use TLS for ANY of your external API calls, then select “not applicable”.
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • If your project software uses TLS, and its default mode is to do certification verification against a locally maintained list of Certificate Authority certificates.
      • Click [Met]
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • 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.
      • Click [Unmet]
      • FILE A JIRA against your project
      • In the description, explain what you don’t do
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
      • Include the JIRA ticket number(s) in your answer.

o   If some of your software meets the above but other parts do not:

§  Select [Unmet]

§  Include an explanation in the description for each part, following the above instructions.

o   If some of your software meets the above, but other parts do not use TLS,

§  Select [Met]

§  Include an explanation in the description for each part, following the aboe instructions.

·         VERY IMPORTANT: Click one of the green buttons that say [Save (and exit)] or [Save (and continue)]


AAF and Istio questions - for July Time frame

Jonathan Gathman <jonathan.gathman@...>
 

To document the discussions at F2F and Jun 18 SECCOM, I’m writing the email.

 

I need to hold off on in depth discussions until

  • After June (big Deployment in my company)
  • I have OOM Helm process documented and get good path forward for PTLs/Services to utilize AAF Auto-generation of Certificates

 

I do see possibilities of interactions for Systems that want Istio:

 

  • If someone wants to make Istio CA THE CA, AAF is already setup to function as Registration Authority
    • Would need to have standard CA API
      • ONAP for Network is already pushing for CMPv2 support.  It would be best if ISTIO had this API setup for its CA.
  • Istio has, I understand, Interfaces to plug in Authorization, etc.
    • AAF has done many different Authorization Plugins, so having an AAF one available for ISTIO for those who want it seems both doable, and helpful.
  • From a practical standpoint, it would be helpful if Istio can be created/run locally within Minikube.
    • Is that feasible, or would one need a larger Environment to even start Istio?

 

 

-- 

Jonathan Gathman

Principled-System Architect

ATO Tech Dev/SEAT/Platform Architecture and Technology Management

 

AT&T Services, Inc.

m  314-550-3312  |  jonathan.gathman@...

 


ONAP Known vulnerabilities - libraries to be updated in El Alto release

Pawel Pawlak
 

Dear All,
Please find an invitation for a dedicated meeting to agree with PTLs and ONAP community on libraries to be updated in El Alto release. List of potential libraries you will find in attached presentation.
Best regards
Pawel Pawlak
ONAP SECCOM Chair
 
ONAP Meeting 2 is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
 
One tap mobile
+16465588656,,408234692# US (New York)
+16699006833,,408234692# US (San Jose)
Dial by your location
+1 646 558 8656 US (New York)
+1 669 900 6833 US (San Jose)
855 880 1246 US Toll-free
877 369 0926 US Toll-free
Meeting ID: 408 234 692
Find your local number: https://zoom.us/u/aedFyNdWz8
 


VNF Security Requirements

ZWARICO, AMY <az9121@...>
 

I will be setting up a series of meetings to update the VNF Security Requirements as part of the El Alto release. Please let me know if you would like to participate.

 

​​​​​Amy Zwarico, LMTS

Chief Security Office / Emerging Services Security

AT&T Services

(205) 613-1667

 

"This e-mail and any files transmitted with it are the property of AT&T,  and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your electronic device. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited."

 


oparent dependency management

Pierre Close
 

Dear SECCOM members,

 

As discussed during last meeting, here are a few slides about current situation in oparent for dependency management, as well as a few highlights. I asked some CLAMP team colleagues for feedback.

 

Feedback is welcome!

 

Thanks and best regards,

Pierre