Linda, thanks for your opinion. I must submit, that I have wrongly interpreted SHOULD keyword as OPTIONAL, but this is not the true. I 100% agree with you. In such case, rephrased requirements:

• xNF SHOULD support client certificate authentication when supporting the event-driven bulk transfer of monitoring data
• If the xNF does not support Certificate Authentication, then the xNF MUST support Basic Authentication when supporting the event-driven bulk transfer of monitoring data

BTW: requirement mentioned by you is already defined - https://docs.onap.org/en/dublin/submodules/vnfrqts/requirements.git/docs/Chapter7/Monitoring-And-Management.html#R-440220. Above requirements are consistent with R-440220.  

Just my opinion, but I would prefer to only support certificate authentication with FTPES.  If you have a xNF that can’t support certificates, then it could use SFTP with username and password.  Then the requirement could be that a xNF MUST support either FTPES or SFTP (or both) for bulk file transfer.

If we do allow basic auth with FTPES, at least it should be an option for the xNF to only support certificate auth.  As an xNF vendor, we do not want to be forced to support usernames and passwords.

The same is true for NETCONF.  xNF MUST support either SSH or TLS (or both) and if the xNF chooses to only support TLS then it doesn’t need to support usernames and passwords.

Hi,

following our yesterday discussion about VNFREQs for mTLS I have checked and FTPes, according to RFC 4217, can support two authentication methods:

1.       Basic authentication -  https://tools.ietf.org/html/rfc4217#page-17

2.       Client certificate authentication - https://tools.ietf.org/html/rfc4217#page-18

Cause we already have client certificate authentication in opposite direction, I think SECCOM should define that:

• xNF MUST support client certificate authentication when supporting the event-driven bulk transfer of monitoring data
• xNF SHOULD support basic authentication when supporting the event-driven bulk transfer of monitoring data

Also, even if not explicitly mentioned, VNFREQ for mTLS in NetConf over TLS is covered by VNF requirement 997907 cause RFC 7589 chapter 7 enforces that server MUST verify the identity of the client with certificate-based authentication according to local policy to ensure that the incoming client request is legitimate before any configuration or state data is sent to or received from the client.

@Samuli and @Linda: what do you think?

Regards

Pawel Baniewski

____________________________________________

Nokia Mobile Networks  BTSOAM Serviceability ARCH Security Architect

mobile: +48 728 361 386

Just my opinion, but I would prefer to only support certificate authentication with FTPES.  If you have a xNF that can’t support certificates, then it could use SFTP with username and password.  Then the requirement could be that a xNF MUST support either FTPES or SFTP (or both) for bulk file transfer.

If we do allow basic auth with FTPES, at least it should be an option for the xNF to only support certificate auth.  As an xNF vendor, we do not want to be forced to support usernames and passwords.

The same is true for NETCONF.  xNF MUST support either SSH or TLS (or both) and if the xNF chooses to only support TLS then it doesn’t need to support usernames and passwords.

Hi,

following our yesterday discussion about VNFREQs for mTLS I have checked and FTPes, according to RFC 4217, can support two authentication methods:

1.       Basic authentication -  https://tools.ietf.org/html/rfc4217#page-17

2.       Client certificate authentication - https://tools.ietf.org/html/rfc4217#page-18

Cause we already have client certificate authentication in opposite direction, I think SECCOM should define that:

• xNF MUST support client certificate authentication when supporting the event-driven bulk transfer of monitoring data
• xNF SHOULD support basic authentication when supporting the event-driven bulk transfer of monitoring data

Also, even if not explicitly mentioned, VNFREQ for mTLS in NetConf over TLS is covered by VNF requirement 997907 cause RFC 7589 chapter 7 enforces that server MUST verify the identity of the client with certificate-based authentication according to local policy to ensure that the incoming client request is legitimate before any configuration or state data is sent to or received from the client.

@Samuli and @Linda: what do you think?

Regards

Pawel Baniewski

____________________________________________

Nokia Mobile Networks  BTSOAM Serviceability ARCH Security Architect

mobile: +48 728 361 386

Hi,

following our yesterday discussion about VNFREQs for mTLS I have checked and FTPes, according to RFC 4217, can support two authentication methods:

1.       Basic authentication -  https://tools.ietf.org/html/rfc4217#page-17

2.       Client certificate authentication - https://tools.ietf.org/html/rfc4217#page-18

Cause we already have client certificate authentication in opposite direction, I think SECCOM should define that:

• xNF MUST support client certificate authentication when supporting the event-driven bulk transfer of monitoring data
• xNF SHOULD support basic authentication when supporting the event-driven bulk transfer of monitoring data

Also, even if not explicitly mentioned, VNFREQ for mTLS in NetConf over TLS is covered by VNF requirement 997907 cause RFC 7589 chapter 7 enforces that server MUST verify the identity of the client with certificate-based authentication according to local policy to ensure that the incoming client request is legitimate before any configuration or state data is sent to or received from the client.

@Samuli and @Linda: what do you think?

Regards

Pawel Baniewski

____________________________________________

Nokia Mobile Networks  BTSOAM Serviceability ARCH Security Architect

mobile: +48 728 361 386

Hello,

We would like to submit for review the attached YAML file.

The initial purpose was to be able to centralize relevant information regarding the communications established between components (and their sub components) of ONAP.

• The approach is proposed as collaborative, meaning that each project would be responsible for completing the file for its scope.
• There will be a presentation of the file (either during PTL meeting, or during F2F ONAP).

Best regards,

Natacha Mach

_________________________________________________________________________________________________________________________

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.

Here are updated slides from what Pawel showed on Tuesday. These are intended to be shared on the PTL meeting next Monday. If you have any comments, PLEASE share them.

Thank you.

                Tony

Thank you, Natacha, for your comments. I also listened to the conversation on this week’s SECCOM meeting, which I unfortunately had to miss.

To summarize the concerns brought up:

• The CII question is ambiguous and could be read as meaning that using SSL instead of TLS would lead to a N/A answer.
• We really need to be mandating that projects use TLS in place of SSL.

I definitely can see how the question COULD be read that way, so agree that it is ambiguous.

The fun thing is that, when there are ambiguities, WE (the SECCOM) get to decide how to interpret it. So my proposal is:

• If a remote site supports SSL, they are covered by this question.

(I’ve also filed a github ticket on the CII code about the ambiguity.)

Now I know that some of you are probably asking yourselves, but what about the other concern?

There are two aspects to the concern, though.

1. We do not control >>remote sites<< that ONAP connects to, so cannot mandate anything about them. We can guarantee that we do certificate verification even when the remote end only does SSL, and we can try to put pressure on them to upgrade. But we don’t control much more.

1. We CAN do things with our own software. For these, though, I think they are adequately covered by other CII issues. In particular:

crypto_tls12

The software produced by the project SHOULD/MUST, if it supports or uses TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL. If the software does not use TLS, select 'not applicable' (N/A).

crypto_used_network

The software produced by the project SHOULD/MUST support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 SHOULD be disabled by default, and only enabled if the user specifically configures it. If the software produced by the project does not support network comunications, select 'not applicable' (N/A).

Both of these are SHOULD questions at the Silver level, and MUST questions at the Gold level.

Do we think that these are worth focusing on next? Since they keep coming up, I think this should be the order of the next 6 weeks’ worth of focus topics.

CII Badging Focus Topics order

1)      crypto_certificate_verification

The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).

2)      crypto_used_network

The software produced by the project SHOULD support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 SHOULD be disabled by default, and only enabled if the user specifically configures it. If the software produced by the project does not support network comunications, select 'not applicable' (N/A).

3)      crypto_tls12

The software produced by the project MUST, if it supports or uses TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL. If the software does not use TLS, select 'not applicable' (N/A).

4)      crypto_credential_agility

The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replacement them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select 'not applicable' (N/A).

5)      crypto_verification_private

The software produced by the project MUST, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies). If the software does not use TLS, select 'not applicable' (N/A).

I’ll post updated slides shortly with the ambiguity dealt with.

                Tony

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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.