ETSI GS NFV-SEC 022 V2.6.1 (2019-08)

Network Functions Virtualisation (NFV) Release 2; Security; Access Token Specification for API Access

DGS/NFV-SEC022

General Information

• Status: Published
• Publication Date: 05-Aug-2019
• Technical Committee: NFV SEC - Security
• Current Stage: 12 - Completion
• Due Date: 19-Aug-2019
• Completion Date: 06-Aug-2019

Standards Content (Sample)

GROUP SPECIFICATION
Network Functions Virtualisation (NFV) Release 2;
Security;
Access Token Specification for API Access
Disclaimer
The present document has been produced and approved by the Network Functions Virtualisation (NFV) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GS NFV-SEC 022 V2.6.1 (2019-08)

Reference
DGS/NFV-SEC022
Keywords
API, authentication, authorization, NFV, security

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2019.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI GS NFV-SEC 022 V2.6.1 (2019-08)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 8
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Security requirements for API access tokens . 9
4.1 Authorization for API access using OAuth2.0 defined in ETSI GS NFV-SOL 013 . 9
4.1.0 Authorization for API access using OAuth2.0 . 9
4.1.1 Mapping roles for Authorization for API access using OAuth2.0 . 9
4.1.2 Authorization grant for Authorization for API access using OAuth2.0 . 9
4.1.3 High level procedures for API access and notifications using OAuth2.0 . 9
4.1.4 Access token for API access and notifications using OAuth2.0 . 10
4.2 Threat Analysis . 11
4.2.0 Access token defined in ETSI GS NFV-SOL 013 . 11
4.2.1 Risk analysis and assessment . 11
4.3 Security requirements . 16
5 NFV Access Token Definition . 19
5.1 Authorization Server discovery . 19
5.1.1 Authorization Server discovery description . 19
5.1.2 Manual Authorization Server Identifier discovery . 20
5.1.3 Dynamic Authorization Server Identifier discovery . 20
5.1.4 Authorization Server Configuration discovery . 21
5.2 Registration process . 23
5.2.1 Disposition . 23
5.2.2 Registration process description . 24
5.2.3 Client metadata . 24
5.3 Token Request . 26
5.4 NFV Access Token Format . 27
5.5 NFV access token associated Metadata . 28
6 Token Verification Process . 30
Annex A (informative): Analysis of existing Access Token specifications . 31 ®
A.1 OpenStack Keystone . 31
A.1.0 Introduction. 31
A.1.1 Authorization scopes. 31
A.1.2 Token binding . 31
A.1.3 Fernet token . 31
A.1.4 Fernet keys . 32
A.1.5 Advantage of Fernet tokens . 32 ®
A.2 OpenID Connect ID-Token . 32
A.2.0 Introduction. 32
A.2.1 ID Token . 33
A.2.2 Advantage of ID Token . 33
A.3 IETF TLS-Based AccessToken Binding . 34
A.3.0 Introduction. 34
A.3.1 OAuth 2.0 Token Binding . 34
ETSI
4 ETSI GS NFV-SEC 022 V2.6.1 (2019-08)
A.3.1.1 Token Binding ID . 34
A.3.1.2 Token Binding for ID Token . 34
A.3.1.3 Advantage of Token Binding . 35
A.3.1.4 Security considerations . 35
A.3.1.4.1 Security Token Replay . 35
A.3.1.4.2 Downgrade attacks . 35
A.3.2 OAuth 2.0 Certificate Bound Access Tokens . 35
A.3.2.0 Basic principle . 35
A.3.2.1 Certificate bound access token using JWT . 35
A.3.3 OAuth 2.0 Token Binding and OAuth2.0 Certificate Token binding comparison . 36
A.4 3GPP authorization framework . 36
A.4.0 OAuth 2.0 authorization in 3GPP . 36
A.4.1 Authentication between Network Functions . 36
A.4.2 Access Token Request . 37
A.4.3 3GPP Access Token. 37
A.4.4 Service access request . 37
Annex B (informative): Synthesis on existing Access Token . 38
Annex C (informative): IANA Registry Considerations . 46
C.1 "Well-Known URIs" Registry . 46
C.1.1 Introduction . 46
C.1.2 Registry contents . 46
C.2 JSON Web Token Claims registry . 46
C.2.1 Introduction . 46
C.2.2 Registry contents . 46
C.3 OAuth Parameters registry . 46
C.3.1 Introduction . 46
C.3.2 Registry contents . 47
C.4 OAuth Dynamic Client Registration Metadata registry . 47
C.4.1 Introduction . 47
C.4.2 Registry contents . 47
C.5 OAuth Authorization Server Metadata registry . 48
C.5.1 Introduction . 48
C.5.2 Registry contents . 48
Annex D (informative): Authors & contributors . 49
Annex E (informative): Change History . 50
History . 51

ETSI
5 ETSI GS NFV-SEC 022 V2.6.1 (2019-08)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Network Functions
Virtualisation (NFV).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
The common aspects for RESTful NFV MANO APIs have been defined in ETSI GS NFV-SOL 013 [22].
The ETSI NFV-MANO APIs are only allowed to be accessed by authorized consumers.
The Authorization of API Request and Authorization of notifications sending has been defined in SOL group. One
solution for authorizing access is the use of OAuth with access token.
The aim of the present document is to define the Access Token for this access Authorization and associated procedure
for the verification of the Access Token, ensuring security and interoperability. The present document results in a NFV
profile of the OAuth2.0 for the NFV-MANO API Request and notification sending Authorization.

ETSI
6 ETSI GS NFV-SEC 022 V2.6.1 (2019-08)
1 Scope
The present document defines the access tokens and related metadata for RESTful protocols and data model for ETSI
NFV management and orchestration (MANO) interfaces. It defines also the process for the token verification by the
API Producer.
For this aim, the present document:
• Analyses the security threat arising from the misuse of the access token and defines the security requirements
associated to access token.
• Analyses existing specifications related to access token for API access and their compliancy with the
requirements defined.
• Defines the token request and generation profile, the token format and associated metadata considering the
result of existing access token specifications analysis.
• Defines the token verification procedures for the API Producer.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI GS NFV 003: "Network Functions Virtualisation (NFV); Terminology for Main Concepts in
NFV".
[2] ETSI GS NFV-SEC 002: "Network Functions Virtualisation (NFV); NFV Security; Cataloguing
security features in management software".
[3] ETSI GS NFV-IFA 007: "Network Functions Virtualisation (NFV) Release 2; Management and
Orchestration; Or-Vnfm reference point - Interface and Information Model Specification".
[4] ETSI GS NFV-IFA 013: "Network Functions Virtualisation (NFV) Release 2; Management and
Orchestration; Os-Ma-Nfvo reference point - Interface and Information Model Specification".
[5] ETSI GS NFV-IFA 008: "Network Functions Virtualisation (NFV) Release 2; Management and
Orchestration; Ve-Vnfm reference point - Interface and Information Model Specification".
[6] IETF RFC 6749: "The OAuth 2.0 Authorization Framework".
NOTE: Available at https://tools.ietf.org/html/rfc6749.
[7] IETF RFC 6750: "The OAuth 2.0 Authorization Framework: Bearer Token Usage".
NOTE: Available at https://tools.ietf.org/html/rfc6750.
[8] IETF RFC 7519: "JSON Web Token (JWT)".
NOTE: Available at https://tools.ietf.org/html/rfc7519.
ETSI
7 ETSI GS NFV-SEC 022 V2.6.1 (2019-08)
[9] IETF RFC 3339: "Date and Time on the Internet: Timestamps".
NOTE: Available at https://tools.ietf.org/html/rfc3339.
[10] IETF RFC 7515: "JSON Web Signature (JWS)".
NOTE: Available at https://tools.ietf.org/html/rfc7515.
[11] IETF RFC 7516: "JSON Web Encryption (JWE)".
NOTE: Available at https://tools.ietf.org/html/rfc7516.
[12] NIST Special Publication 800-90B: "Recommendation for the Entropy Sources Used for Random
Bit Generation". January 2018.
NOTE: Available at https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-90b.pdf.
[13] IETF RFC 8414: "OAuth 2.0 Authorization Server Metadata".
NOTE: Available at https://tools.ietf.org/html/rfc8414.
[14] IETF RFC 7033: "WebFinger".
NOTE: Available at https://tools.ietf.org/html/rfc7033.
[15] ETSI GS NFV-IFA 011: "Network Functions Virtualisation (NFV) Release 2; Management and
Orchestration; VNF Descriptor and Packaging Specification".
[16] IETF RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax".
NOTE: Available at https://tools.ietf.org/html/rfc3986.
[17] IETF RFC 5785: "Defining Well-Known Uniform Resource Identifiers (URIs)".
NOTE: Available at https://tools.ietf.org/html/rfc5785.
[18] IETF RFC 7591: "OAuth 2.0 Dynamic Client Registration Protocol".
NOTE: Available at https://tools.ietf.org/html/rfc7591.
[19] IETF RFC 7517: "JSON Web Key (JWK)".
NOTE: Available at https://tools.ietf.org/html/rfc7517.
[20] IETF RFC 7518: "JSON Web Algorithms (JWA)".
NOTE: Available at https://tools.ietf.org/html/rfc7518.
[21] IETF RFC 7662: "OAuth 2.0 Token Introspection".
NOTE: Available at https://tools.ietf.org/html/rfc7662.
[22] ETSI GS NFV-SOL 013: "Network Functions Virtualisation (NFV) Release 2; Protocols and Data
Models; Specification of common aspects for RESTful NFV MANO APIs".
[23] draft-ietf-oauth-mtls-14: "OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound
Access Tokens". Work in progress.
NOTE: Available at https://tools.ietf.org/wg/oauth/draft-ietf-oauth-mtls/.
[24] ETSI GS NFV-IFA 005: "Network Functions Virtualisation (NFV) Release 2; Management and
Orchestration; Or-Vi reference point - Interface and Information Model Specification".
[25] ETSI GS NFV-IFA 006: "Network Functions Virtualisation (NFV) Release 2; Management and
Orchestration; Vi-Vnfm reference point - Interface and Information Model Specification".
ETSI
8 ETSI GS NFV-SEC 022 V2.6.1 (2019-08)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] https://docs.openstack.org/keystone/latest/admin/tokens.html.
[i.2] https://openid.net/specs/openid-connect-core-1_0.html#IDToken.
[i.3] IETF RFC 8471: "The Token Binding Protocol Version 1.0".
NOTE: Available at https://tools.ietf.org/html/rfc8471.
[i.4] IETF RFC 6819: "OAuth 2.0 Threat Model and Security Considerations".
NOTE: Available at https://tools.ietf.org/html/rfc6819.
[i.5] ETSI GS NFV-SEC 006: "Network Functions Virtualisation (NFV); Security Guide; Report on
Security Aspects and Regulatory Concerns".
[i.6] ETSI TS 133 501: "5G; Security architecture and procedures for 5G System (3GPP TS 33.501)".
[i.7] draft-ietf-oauth-token-binding-08: "OAuth 2.0 Token Binding". Work in progress.
NOTE: Available at https://tools.ietf.org/pdf/draft-ietf-oauth-token-binding-08.pdf.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS NFV 003 [1] apply.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS NFV 003 [1] and the following apply:
rd
3GPP 3 Generation Partnership Project
HSM Hardware Security Module
JRD JSON Resource Descriptor
JSON JavaScript Object Notation
JWE JSON Web Encryption
JWS JSON Web Signature
JWT JSON Web Token
MAC Message Authentication Code
MTLS Mutual TLS
NRF Network Resource Function
OTP One-Time Password
PKI Public Key Infrastructure
ETSI
9 ETSI GS NFV-SEC 022 V2.6.1 (2019-08)
REST REpresentational State Transfer
SAML Security Assertion Markup Language
TLS Transport Layer Security
URI Uniform Resource Identifier
URL Uniform Resource Locator
4 Security requirements for API access tokens
4.1 Authorization for API access using OAuth2.0 defined in
ETSI GS NFV-SOL 013
4.1.0 Authorization for API access using OAuth2.0
The requirements on interfaces supported by the reference point of MANO's entities have been defined in
ETSI GS NFV-IFA 005 [24], ETSI GS NFV-IFA 006 [25], ETSI GS NFV-IFA 007 [3], ETSI GS NFV-IFA 0013 [4]
and ETSI GS NFV-IFA 008 [5].
One of these requirements concerns authentication and authorization of the API consumer for all operations on
interfaces supported by the reference point.
To fulfil this requirement for the NFV-MANO reference points, authorization of API requests and notifications has
been defined in ETSI GS NFV-SOL 013 [22] specification.
One solution defined to handle these authorizations for API request and notification is the use of OAuth 2.0 protocol as
defined by IETF RFC 6749 [6].
4.1.1 Mapping roles for Authorization for API access using OAuth2.0
For API calls, the producer functional block of an API in NFV terms corresponds to the "resource server", and the
consumer functional block of an API corresponds to the "client" as defined by IETF RFC 6749 [6]. For sending a
notification, these roles are reversed: The producer (notification sender) corresponds to the "client", and the consumer
(notification receiver) corresponds to the "resource server".
Before invoking an HTTP method on a REST resource provided by a resource server, a consumer functional block
(referred to as "client" from now on) first obtains authorization from another functional block fulfilling the role of the
"authorization server".
4.1.2 Authorization grant for Authorization for API access using OAuth2.0
Authorization grant, which is a credential representing the resource owner's authorization to access the API resources is
used by the client to obtain an access token from the authorization server as defined by IETF RFC 6749 [6]. OAuth 2.0
defined 4 types of authorization grant (authorization code, implicit, resource owner password credentials, and client
credentials).
For the reference points listed in clause 4.1, access to API is performed by a machine which is a non-interactive Client,
acting on its own behalf and being the Resource owner. Example of such client is the EM requesting the creation of an
instance of its related VNF to the corresponding VNFM; this EM is the resource owner for the management resource of
the VNF. The authorization grant suitable to this case is the client credentials authorization grant. This is the
authorization grant type that has been selected for the NFV-MANO interfaces and defined in ETSI
GS NFV-SOL 013 [22].
4.1.3 High level procedures for API access and notifications using
OAuth2.0
The roles and exchanges are shown in figure 4.1.3-1 in case of API calls and in figure 4.1.3-2 for sending a notification.
ETSI
10 ETSI GS NFV-SEC 022 V2.6.1 (2019-08)
API consumer Authorization
(Client) Server
API Producer
(Resource
Server)
Figure 4.1.3-1: OAuth 2.0 roles in case of API calls
Notification Authorization
sender (Client) Server
Notification
receiver
(Resource
Server)
Figure 4.1.3-2: OAuth 2.0 roles in case of sending notifications
NOTE: The numbered steps below correspond to the steps of figure 4.1.3-1.
The procedure for API access is as follows:
Step 1. Before invoking the RESTful HTTP based API on the API producer, the API consumer
authenticates with an Authorization Server by presenting its credentials consisting of its Client Id
and Client Secret. It is assumed that authorization-related configuration parameters such as the
client credentials are pre-populated in the API consumer together with other information such as
the address of the token endpoint exposed by the authorization server.
Step 2. The Authorization server after authentication and validation of the API consumer returns an access
token.
Step 3. The API consumer uses the access token in the API Request.
Same procedure is used for the notifications case shown in figure 4.1.3-2.
4.1.4 Access token for API access and notifications using OAuth2.0
An access token represents a particular access right (defining the particular set of protected resources to access in a
particular manner) with a defined duration. The access token is usually used as a Bearer credential and transmitted in an
HTTP Authorization header to the API. The token may denote an identifier used to retrieve the authorization
information or may self-contain the authorization information in a verifiable manner (i.e. a token string consisting of
some data and a signature). Access tokens can have different formats, structures, and methods of utilization (e.g.
cryptographic properties) based on the resource server security requirements.
IETF has defined two aspects of access token use:
1) Bearer token as defined by IETF RFC 6750 [7] focuses on the transmission of the access token as an opaque
string and makes no assumption about the structure of the token.
2) JSON Web Token (JWT) as defined by IETF RFC 7519 [8] focuses on the structure of the token, and allows it
to be encrypted (JWE) or signed (JWS).
ETSI GS NFV-SOL 013 [22] specifies the transmission aspects of the token as a bearer token, according to the
definitions by IETF RFC 6750 [7].
The present document analyses the different access token used by different standardization and open source
organizations and the security threats around this access token.
ETSI
11 ETSI GS NFV-SEC 022 V2.6.1 (2019-08)
4.2 Threat Analysis
4.2.0 Access token defined in ETSI GS NFV-SOL 013
The access token defined by ETSI GS NFV-SOL 013 [22] to authorize access to the API of NFV MANO interfaces is
the bearer token as defined in IETF RFC 6750 [7].
The bearer token is defined in IETF RFC 6750 [7] as follows:
Bearer Token: A security token with the property that any party in possession of the token (a "bearer") can use the
token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove
possession of cryptographic key material (proof-of-possession).
The Authorization grant type defined by ETSI GS NFV-SOL 013 [22] is the client credentials type as defined in IETF
RFC 6749 [6].
4.2.1 Risk analysis and assessment
This threat analysis takes as basis the OAuth 2.0 Threat Model as presented in IETF RFC 6819 [i.4]. This risk analysis
in table 4.2.1-1 uses the format found in the annex A of ETSI GS NFV-SEC 006 [i.5].
Table 4.2.1-1: Risk analysis and assessment
A Security Environment
a.1 Assumptions
a.1.1 It is assumed that the attacker has access to the communication between the
client (API consumer) and the authorization server, and between the client
(API consumer) and the resource server (API producer)
a.1.2 An attacker has unlimited resources to mount an attack
a.1.3 Two of the three parties involved in the OAuth protocol may collude to mount
rd
an attack against the 3 party
a.2 Assets
a.2.1 Access token
a.2.2 Refresh Token
a.2.3 Protected Resources
a.2.4 Client id, client credentials

a.3 Threat agents
a.3.1 Malicious authorization server: this malicious authorization server delivers Threats:
bogus token and get access to client credentials or refresh token (and then a.4.2.2.
obtains access token with the refresh token by counterfeiting the client) a.4.2.3
a.4.2.4
a.4.3.3
a.4.3.6
a.3.2 Malicious client: this malicious client may modify the content of the token Threats:
a.4.1.2
ETSI
12 ETSI GS NFV-SEC 022 V2.6.1 (2019-08)
a.3.3 Attacker of client: This attack could be through malicious software within the Threats:
client itself a.4.1.7
a.4.1.8
a.4.1.2
a.4.1.3
a.4.1.4
a.4.1.5
a.4.1.9
a.4.2.1
a.4.2.3
a.4.2.4
a.4.3.1
a.4.3.2
a.4.4.3
a.3.4 Malicious resource server: this malicious resource server gain access to the Threats:
access token sent by the client by counterfeiting the resource server a.4.1.11
a.4.1.2
a.4.1.3
a.4.1.4
a.4.1.5
a.4.1.9
a.4.4.3
a.4.4.4
a.3.5 Malicious entity acting as a Man in the Middle on the communication between Threats:
Authorization server and client a.4.1.1
a.4.1.2
a.4.1.3
a.4.1.4
a.4.1.5
a.4.1.9
a.4.3.4
a.4.3.6
a.4.4.1
a.4.4.3
a.3.6 Malicious entity acting as a Man in the Middle on the communication between Threats:
the Client and the resource server a.1.4.10
a.4.1.2
a.4.1.3
a.4.1.4
a.4.1.5
a.4.1.9
a.4.4.1
a.4.4.2
a.4.4.3
a.3.7 Attacker of the Authorization server: This attack could be through malicious Threats:
software within the Authorization server itself a.4.1.6
a.4.1.2
a.4.1.3
a.4.1.4
a.4.1.5
a.4.1.9
a.4.3.5
a.4.4.3
a.4 Threats
a.4.1 Threats on access token
a.4.1.1 Token Interception or token eavesdropping in transit from authorization server Mitigation by:
and client b.1.3
b.1.4
ETSI
13 ETSI GS NFV-SEC 022 V2.6.1 (2019-08)
a.4.1.2 Token Manipulation Mitigation by:
b.1.1
b.1.18
b.1.22
a.4.1.3 Token disclosure - misuse Mitigation by:
b.1.2
b.1.3
b.1.4
b.1.10
b.1.12
b.1.13
b.1.14
b.1.21
b.1.24
a.4.1.4 Token redirect b.1.3
b.1.4
b.1.10
b.1.12
b.1.13
b.1.14
b.1.21
b.1.24
a.4.1.5 Token replay b.1.3
b.1.4
b.1.10
b.1.12
b.1.13
b.1.14
b.1.21
b.1.24
a.4.1.6 Obtaining Access tokens from authorization server database b.1.4
b.1.10
b.1.12
b.1.13
b.1.14
b.1.21
b.1.24
a.4.1.7 Attacker of client obtains access tokens from the storage device b.1.25
b.1.9
b.1.10
b.1.12
b.1.14
a.4.1.8 Redirection on client to malicious server: Attacker of client takes the control of b.1.25
the client and get access to token and authorization code b.1.7
b.1.9
b.1.10
b.1.12
b.1.14
a.4.1.9 Guessing the access token b.1.4
b.1.10
b.1.12
b.1.13
b.1.14
b.1.17
b.1.21
b.1.24
ETSI
14 ETSI GS NFV-SEC 022 V2.6.1 (2019-08)
a.4.1.10 Token Interception or token eavesdropping in the request sent from client to b.1.4
resource server b.1.25
b.1.10
b.1.12
b.1.13
b.1.14
b.1.16
b.1.21
b.1.24
a.4.1.11 A malicious resource server gain access to a valid access token sent by a b.1.4
legitimate client b.1.25
b.1.10
b.1.11
b.1.12
b.1.13
b.1.16
b.1.19
b.1.20
b.1.21
b.1.23
b.1.24
a.4.2. Threats on refresh token
a.4.2.1 Attacker of client obtains refresh token stored in client b.1.6
b.1.7
b.1.9
a.4.2.2 Refresh token phishing by counterfeiting the authorization server b.1.4
b.1.5
b.1.6
b.1.8
a.4.2.3 Refresh token replay b.1.4
b.1.5
b.1.6
b.1.8
a.4.2.4 Guessing the refresh token b.1.26

a.4.3. Threats on client credentials
a.4.3.1 Attacker obtains client secrets from source code b.1.9
a.4.3.2 Attacker obtains client secrets from a client installation b.1.9
a.4.3.3 malicious authorization server get access to client credentials b.1.15
a.4.3.4 Disclosure of client credentials during client authentication process or token b.1.27
requests b.1.28
a.4.3.5 Obtaining client secrets from authorization server database b.1.29
a.4.3.6 Guessing the client credentials b.1.30

a.4.4. Threats on protected resources
a.4.4.1 An attacker eavesdrops Access tokens on transport and gain access to the b.1.13
protected resources b.1.21
a.4.4.2 Replay of authorized resource server requests b.1.16
a.4.4.3 Gain access to the protected resources by guessing the access tokens b.1.17
a.4.4.4 Malicious resource server gain access to a valid access token and uses it to b.1.19
gain access to protected resources b.1.13
b.1.21
b.1.23
ETSI
15 ETSI GS NFV-SEC 022 V2.6.1 (2019-08)
B Security Objectives
b.1 Security objectives for the asset
b.1.1 Integrity protection of the token using digital signature or Message
Authentication Code (MAC)
b.1.2 Confidentiality protection
b.1.3 Access tokens should not be sent in clear over insecure channel. Use Secure
transmission as TLS
b.1.4 Binding of the token to ID of authorized party
b.1.5 The authorization server should validate the client id associated with the
refresh token
b.1.6 Revocation of refresh tokens
b.1.7 Revocation of client secrets
b.1.8 Refresh token rotation
b.1.9 Store secrets in secure storage
b.1.10 Limit token scope
b.1.11 Limit the token to a resource server
b.1.12 Limit lifetime of the access token, short access token duration
b.1.13 Binding of access token to client id, and client prove legitimate ownership of
the token to the resource server
b.1.14 Allow one-time access token usage
b.1.15 Verification of authorization server's authenticity
b.1.16 Resource server uses transport security measures to avoid replay attacks
(TLS) or uses signed requests with nonces and timestamps
b.1.17 Access token should have a reasonable level of entropy making the guessing
of the token infeasible
b.1.18 Assertion token should be protected by a digital signature
b.1.19 Authentication of the resource server by the client
b.1.20 Bind the access token to the endpoint URL of the legitimate resource server
b.1.21 Binding of the access token with the client and authenticate the client with
resource server requests (signature)
b.1.22 The token contents should be protected by a digital signature
b.1.23 The client should authenticate the resource server before sending the access
token
b.1.24 Authenticate the client with the resource server requests, and verification with
the binding of the access token with the client id
b.1.25 Revocation of access token
b.1.26 Refresh token should have a reasonable level of entropy
b.1.27 The client credentials and client ID shall not be sent in clear during
authentication process
b.1.28 The client credentials and client ID shall not be sent in clear in the token
request
b.1.29 The authorization server database shall be a tamper resistant storage such as
a HSM
b.1.30 The client credentials should have a reasonable level of entropy making the
guessing of these credentials infeasible

ETSI
16 ETSI GS NFV-SEC 022 V2.6.1 (2019-08)
4.3 Security requirements
From the risk analysis and assessment of clause 4.2.1, the security requirements for authentication and protocols are
defined and listed in table 4.3-1.
Table 4.3-1: Requirements for authentication and protocols
Requirement Requirement Description Reference Remarks
Number Security threat
(see clause 4.2)
Authentication and protocols
Auth-Prot_001 The confidentiality and a.4.1.3; a.4.1.5;
data integrity of all a.4.2.3; a.4.3.4;
messages shall be a.4.4.1; a.4.4.2
ensured, e.g. by using a
transport-layer
mechanism, such as TLS,
on each interface.
Auth-Prot_002 The client and a.4.2.2; a.4.3.3;
authorization servers shall
mutually authenticate.
Auth-Prot_003 The client shall a.4.4.4
authenticate the resource
server.
Auth-Prot_004 Before accepting the token a.4.1.3; a.4.1.4;
as valid, the resource a.4.1.5; a.4.4.3;
server shall authenticate a.4.4.2; a.4.4.1
the originator of the
request as the legitimate
owner of the token.
Auth-Prot_005 The authorization server a.4.3.5
database used to
authenticate the client and
store associated client
credentials, access tokens
and refresh tokens shall
be stored in a tamper
resistant location (e.g.
HSM).
From the risk analysis and assessment of clause 4.2.1, the security requirements for client credentials are defined and
listed in table 4.3-2.
ETSI
17 ETSI GS NFV-SEC 022 V2.6.1 (2019-08)
Table 4.3-2: Requirements for client credentials
Requirement Requirement Description Reference Remarks
Number Security threat
(see clause 4.2)
Client Credentials
Client-Cred_001 The client credentials shall a.4.3.1
be stored in a secure and
tamper resistant location,
or stored encrypted with
the key protected in a
tamper resistant location.
Client-Cred_002 The client credentials shall a.4.3.6
be generated with a
minimum of 128 bits of
entropy, using best
practices for entropy
sources [12], in order to
mitigate the risk of
guessing attacks.
Client-Cred_003 The client credentials shall a.4.3.1
not be included in the
source code and software
packages.
Client-Cred_004 The client credentials shall a.4.3.2
be installed in the client in
a secure way, eliminating
any possibility of gaining
access to these
credentials during
installation.
Client-Cred_005 It shall be possible for the a.4.3.1; a.4.3.2;
authorization server to a.4.3.3; a.4.3.4;
revoke the client a.4.3.5; a.4.3.6
credentials.
From the risk analysis and assessment of clause 4.2.1, the security requirements for access token are defined and listed
in table 4.3-3.
Table 4.3-3: Requirements for access token
Requirement Requirement Description Reference Security Remarks
Number threat
(see clause 4.2)
Access token
Acc-Token_001 The access token shall be a.4.1.6; a.1.4.7
stored in a secure and
tamper resistant location
or stored encrypted with
the key protected in a
tamper resistant location.
Acc-Token_002 The access token shall be a.4.1.9; a.4.4.3
generated with a minimum
of 128 bits of entropy,
using best practices for
entropy sources [12], in
order to mitigate the risk of
guessing attacks.
Acc-Token_003 Access tokens shall have a.4.1.1; a.4.1.3;
policy-defined limited a.4.1.4; a.4.1.5;
scope. a.4.1.6; a.4.1.7;
a.4.1.8
ETSI
18 ETSI GS NFV-SEC 022 V2.6.1 (2019-08)
Requirement Requirement Description Reference
...