The components are authenticated prior to establishing a connection
The connection is encrypted
State | Definition |
---|---|
Credential_Null | No credential currently exists. The only valid operation is to create a credential. (The mechanism for creating a credential is out of scope of ONAP.) |
Credential_Created | A credential has been created. The credential is not yet available within ONAP, and cannot be validated. |
Credential_Provisioned | The credential is provisioned into ONAP. The credential can be validated within ONAP. |
Credential_Expired | The credential has expired. Credential validation within ONAP will fail. The credential can be updated. |
Credential_Revoked | The credential has been revoked. Credential validation within ONAP will fail. The credential cannot be updated. |
Credential_Destroyed | Note: Credentials can be copied, and the copy can be presented for validation. Credentials can never be destroyed. |
Operation | Definition |
---|---|
CREATE | Creates a new credential. Credential creation is external to ONAP. |
| Credentials may not be deleted. (Design Note 1). |
PROVISION | Provisions an existing credential into ONAP. A credential must go through state Credential_Provisioned before it can be used within ONAP. |
UPDATE | Updates an existing credential within ONAP. UPDATE is used to update a credential in state Credential_Expired and return it to state Credential_Provisioned. UPDATE may also be used to update internal parts of a credential. |
VALIDATE | Validates an existing credential. VALIDATE is used to test that a presented credential gives permission for access to a resource within ONAP (e.g. to access an ONAP component, perform an ONAP operation, or access data). |
EXPIRE | Expires an existing credential. EXPIRE may be an implicit operation, as some credentials have a defined lifetime, and will expire automatically. EXPIRE may be an explicit operation, where a specific credential is expired. Credentials in state Credential_Expired may be updated. |
REVOKE | Revokes an existing credential. Once a credential is in state Credential_Revoked there are no valid operations. A new credential is required. |
The following report was generated by running Coverity against code from the Zephyr project.
https://wiki.onap.org/download/attachments/11928162/CoverityScanReportForZephyr.docx?api=v2
4/11 Update
Topic | Status | Comment |
7. Pluggable Security | In Review | Moved to own page for manageability |
Status: Draft
The scope of this item is verification of the integrity and authenticity of the
In general, the intention is to align with ETSI NFV specifications on this area, see the references in 8.5. The published version of [ETSI NFV SOL004] is the main specification to follow. Going forward, [ETSI NFV SEC021] shall also be considered (as of Feb 2018 the work has started).
Integrity of the VNF package needs to be verified prior to, or at the time of onboarding. The purpose is to ensure that the VNF package originates from the vendor, and that the content has not been tampered with. The verification is done against the signature provided by the vendor. Reference [ETSI NFV SOL004] contains the detailed specifications.
At instantiation, the integrity of VNF image and related files shall be verified. The options are:
A) Verify against the signature provided by the vendor. [ETSI NFV SOL004] specifies “The VNF provider may optionally digitally sign some artifacts individually”.
B) Verify against the signature created by the service provider. [ETSI NFV SOL004] specifies “If software images or other artifacts are not signed by the VNF provider, the service provider has the option, after having validated the VNF Package, to sign them before distributing the different package components to different function blocks or the NFVI”.
If the vendor did not sign artifacts (inside the VNF package) individually, service provider may want to sign those. Also, if the service provider needs to modify or add any artifacts, the service provider may want to sign those.
Tentatively, following projects are impacted:
AAF should not be impacted, because it already supports install of trusted certificates.
On the CA issuing the VNF package signing certificate, [ETSI NFV SOL004] specifies: “This solution, either option 1 or option 2, relies on the existence in the NFVO of a root certificate of a trusted CA that shall have been delivered via a trusted channel that preserves its integrity (separate from the VNF package) to the NFVO and be pre-installed in the NFVO before the on-boarding of the VNF package.
NOTE: The present document makes no assumption on who this trusted CA is. Furthermore, it does not exclude that the root certificate be issued by the VNF vendor or by the NFVI provider.”
If the signing certificate has been issued by vendor’s own CA, the related root CA has to be installed in ONAP AAF as trusted certificate.
[ETSI NFV SOL004]
ETSI GS NFV-SOL 004 V2.3.1 (2017-07): http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/004/02.03.01_60/gs_nfv-sol004v020301p.pdf
[ETSI NFV SEC021]
ETSI NFV SEC021 work item description: https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=53601
Status: Draft
Note: This will be removed when the feedback is sent back.
The full list of the needs can be found at: https://wiki.onap.org/plugins/servlet/mobile?contentId=1015829#content/view/15998867
Security:
Per project:
Note: When creating the CII project entry, it is recommended to use ONAP in the title to facilitate searching the onap projects.
Per Release:
5. Examples of secure communication between ONAP components
6. Examples of security communiation between ONAP and other components.
7. User provisioning, and relation to access to other systems.