Re: VNF Security Requirements Refresh for El Alto - 2019/9/5 Meeting Minutes
And there’s a general requirement that non-secure protocols (e.g. HTTP) MUST be disabled by default.
From: "Horn, Linda (Nokia - US/Murray Hill)" <linda.horn@...>
Yes, there is a separate requirement that the VNF and PNF MUST support HTTPS to DCAE. VNFRQTS-687
Cloud RAN Solution Definition and Architecture
Mobile Networks, Nokia
From: natacha.mach@... <natacha.mach@...>
Sent: Thursday, September 12, 2019 11:07 AM
To: Hampus Tjäder <hampus.tjader@...>; amy.zwarico@...; onap-seccom@...; LOVETT, TREVOR J <tl2972@...>; THORPE, HENRY E <ht1659@...>; Nowak, Damian (Nokia - PL/Wroclaw) <damian.nowak@...>; 'Krzysztof Opasiak' <k.opasiak@...>; HANSEN, TONY L <tony@...>; 'Harald.Fuchs@...' <Harald.Fuchs@...>; PAWLAK Pawel O-PL <pawel.pawlak3@...>; 'Parayil, Shiby' <sparayil@...>; 'Zygmunt Lozinski' <zygmunt_lozinski@...>; Samuli Kuusela <samuli.kuusela@...>; Baniewski, Pawel (Nokia - PL/Wroclaw) <pawel.baniewski@...>; MCCRAY, CHRISTOPHER <cm6826@...>; 'Jason Hunt' <djhunt@...>; Horn, Linda (Nokia - US/Murray Hill) <linda.horn@...>
Subject: RE:[Onap-seccom] VNF Security Requirements Refresh for El Alto - 2019/9/5 Meeting Minutes
As agreed i come back to you regarding the statements above.
Do you confirm that the basic authentication relies on HTTPS?
If confirmed, it is OK for us.
De : Hampus Tjäder [hampus.tjader@...]
After initial community feedback, we have decided to take a softer position on these three HTTPS requirements. This for faster reaching an alignment in the community. For not using too much time of the SECCOM meeting today, I will instead send this suggested updates over mail prior to the meeting.
o Proposed modification:
VNF or PNF MUST support
one of the following authentication methods for authenticating HTTPS connections to the DCAE VES Event Listener:
o Reason: In the current formulation of the HTTPS requirements it is not clear that certificate authentication is the primary solution. We are suggesting a clearer formulation that Basic Auth or Certificate Auth must be supported.
o Proposed modification:
§ If the VNF or PNF is using Certificate Authentication, the VNF or PNF MUST support mutual TLS authentication and the Subject Name in the end-entity certificate MUST be used according to RFC 5280.
o Reason: Removal of conditional related to DCAE VES Event Listener as it should also be the case for interacting with other ONAP components. New proposal is to keep that it does only apply if certificate auth. is used.
o Proposed modification
§ If VNF or PNF is using Basic Authentication, then the VNF or PNF MUST be in compliance with RFC 7617 for authenticating HTTPS connections to the DCAE VES Event Listener.
o Reason: Initial proposal was to remove this requirement. Removal seems not to be an option in the community. Suggestion is instead to modify this requirement as above, hence it does only apply if basic auth. is supported by the xNF. This is a similar formulation as in 693.
58330, Linköping, Sweden
Mobile: +46 107113292
On Behalf Of Amy Zwarico via Lists.Onap.Org
Linda Horn provided a status update for the VNF certificate requirements
1. The review period is over
3. The requirements allow both certificate and basic authentication
Ericsson position is that VNF MUST support certification authentication (currently a SHOULD)
Configuration and monitoring requirements
1. We completed a revision of the requirements for monitoring the configuration of a VNF
2. Review the Jiras attached to VNFRQTS-456 (parent jira) and provide comments and +/-1 by 13 Sept.
Scheduling a series of recurring meetings to refresh the VNF security requirements as part of the El Alto release. Please forward the invitation to others in your organization who should participate.
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.