ETSI TS 103 962 V1.1.1 (2023-12)

CYBER; Optical Network and Device Security; Security provisions in Optical Access Network Devices

DTS/CYBER-0092

General Information

• Status: Not Published
• Technical Committee: CYBER - Cyber Security
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Due Date: 25-Dec-2023
• Completion Date: 14-Dec-2023

Standards Content (Sample)

TECHNICAL SPECIFICATION
CYBER;
Optical Network and Device Security;
Security provisions in Optical Access Network Devices

2 ETSI TS 103 962 V1.1.1 (2023-12)

Reference
DTS/CYBER-0092
Keywords
cybersecurity, optical access network,
security requirements
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
https://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
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
ntation or warranty is made of merchantability or fitness
and/or governmental rule and/or regulation and further, no represe
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
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 2023.
All rights reserved.
ETSI
3 ETSI TS 103 962 V1.1.1 (2023-12)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Definition of terms, symbols and abbreviations . 9
3.1 Terms . 9
3.2 Symbols . 9
3.3 Abbreviations . 9
4 Overview of security of functions for optical access network devices . 10
4.1 Optical access network device functional model . 10
4.2 Trust architecture in Optical access network devices . 10
4.3 Generalized functional model for an Optical access network device . 11
4.4 Guidance on cryptographic processes . 13
4.5 Security error and misuse reporting. 13
5 Identification and authentication of Optical access network devices . 13
5.1 Common provisions . 13
5.2 Identification and authentication . 15
5.2.1 Symmetric keyed systems . 15
5.2.1.1 Symmetric key distribution . 15
5.2.1.2 MAC based systems . 15
5.2.1.3 Challenge response based systems . 15
5.2.2 Asymmetric keyed systems (digital signature) . 16
5.2.2.1 Self attestation of identity . 16
rd
5.2.2.2 3 party attestation of identity . 16
5.2.2.3 Self attestation of capability . 16
rd
5.2.2.4 3 party attestation of capability . 17
6 Confidentiality and integrity protection of data transfer between Optical access network devices . 17
6.1 General provisions - integrity . 17
6.2 General provisions - confidentiality . 18
7 Secure data storage on Optical access network devices . 19
7.1 General provisions . 19
7.2 Access control in OAN devices . 19
7.3 Access Control rules for OAN devices. 20
7.4 Access control policy in OAN devices . 21
Annex A (normative): Simplified ICS Proforma for OAN Device security . 22
Annex B (normative): Mapping to common requirements from ETSI TS 103 924 . 30
Annex C (normative): Environmental, deployment, and development constraints . 33
Annex D (informative): Requirements for placing ON access equipment on the market . 36
Annex E (informative): Deployment scenarios for ON access equipment . 37
Annex F (informative): Bibliography . 39
F.1 Secure network protocols for OLT . 39
ETSI
4 ETSI TS 103 962 V1.1.1 (2023-12)
F.2 ETSI work in development at time of writing . 39
History . 40

ETSI
5 ETSI TS 103 962 V1.1.1 (2023-12)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are 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 Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
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.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 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.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Cyber Security (CYBER).
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 Optical Network Device Security (ONDS) suite of documents is developed as an interlinked collection, shown in
figure 1.
ETSI
6 ETSI TS 103 962 V1.1.1 (2023-12)

Figure 1: Document structure for Optical Network Device Security
Each of ETSI TS 103 962 (the present document), ETSI TS 103 963 [i.17] and ETSI TS 103 961 [3] expand upon the
requirements identified in the common catalogue of ETSI TS 103 924 [1]. In the definition of detailed provisions. The
present document acts as the master document with each of ETSI TS 103 963 [i.17] and ETSI TS 103 961 [3]
identifying further specializations.
To drive the evaluation and test of the ONDS suite a common Test Suite Structure and Test Purposes definition is given
in ETSI TS 103 993 [i.18] and from that is derived a specification of the evaluation assessments to be applied, this
document, ETSI TS 103 996 [i.19], is given in the form of a partial protection profile.
NOTE: All of the documents identified in the figure 1 act together to fully define the requirements, test and
evaluation for placing an ODNS device on the market.

ETSI
7 ETSI TS 103 962 V1.1.1 (2023-12)
1 Scope
The present document provides the baseline requirements specific to Optical Access Network (OAN) and devices which
provides network access service to network service subscribers.
The present document extends the provisions identified in the Catalogue of Requirements for Optical Network (ON)
and Device Security from ETSI TS 103 924 [1] addressing the security of Access Network (AN) and the Optical Line
Terminal (OLT) as the core network equipment in Access Network.
The present document gathers the requirements in the form of an Implementation Conformance Statement in Annex A.
NOTE: A primacy distinction between OANs and OTNs (see ETSI TS 103 963 [i.17]) is in the lower layer
protocols supported by the devices, OANs use GEM or GPON [2], [7] and [8] protocols to deliver client
data, whereas OTNs device encode client data which come from an OLT device into an OTN frame
transparently. However the optical transmission aspects are not addressed by the present document other
than in the required security mechanisms needed to support them.
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 TS 103 924: "Optical Network and Device Security; Catalogue of Requirements".
[2] Recommendation ITU-T G.9804.1: "Higher speed passive optical networks - Requirements".
[3] ETSI TS 103 961: "CYBER; Optical Network and Device Security; Security provision for the
management of Optical Network devices and services".
[4] ETSI TS 103 848 (V1.1.1): "Cyber Security for Home Gateways; Security Requirements as
vertical from Consumer Internet of Things".
[5] ETSI EN 303 645: "CYBER; Cyber Security for Consumer Internet of Things: Baseline
Requirements".
[6] Recommendation ITU-T G.9807.1: "10-Gigabit-capable symmetric passive optical network
(XGS-PON)".
[7] Recommendation ITU-T G.987.3: "10-Gigabit-capable passive optical networks (XG-PON):
Transmission convergence (TC) layer specification".
[8] ETSI TS 102 165-2: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Methods and protocols; Part 2: Protocol Framework Definition;
Security Counter Measures".
NOTE: An update to the work item above is in development but the latest draft is publicly available.
[9] FIPS 140-2: "Security Requirements for Cryptographic Modules".
[10] NIST SP 800-90B: " Recommendation for the Entropy Sources Used for Random Bit Generation".
ETSI
8 ETSI TS 103 962 V1.1.1 (2023-12)
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] Global Platform Security Task Force: "Root of Trust Definitions and Requirements,
Version 1.0.1".
[i.2] NIST SP 800-164: "Guidelines on Hardware-Rooted Security in Mobile Devices (Draft)".
[i.3] ETSI TR 103 838: "Cyber Security; Guide to Coordinated Vulnerability Disclosure".
[i.4] ETSI GR ETI 002: "Encrypted Traffic Integration (ETI); Requirements definition and analysis".
[i.5] NIST SP 800-160 Vol.1 Rev.1: " Engineering Trustworthy Secure Systems".
[i.6] ISO/IEC 27002 (2022): "Information security, cybersecurity and privacy protection - Information
security controls".
[i.7] Recommendation ITU-T G.984.3: "Gigabit-capable passive optical networks (G-PON):
Transmission convergence layer specification".
[i.8] ETSI EG 203 310: "CYBER; Quantum Computing Impact on security of ICT Systems;
Recommendations on Business Continuity and Algorithm Selection".
[i.9] ETSI GR QSC 004: "Quantum-Safe Cryptography; Quantum-Safe threat assessment".
[i.10] ETSI TR 103 619: "CYBER; Migration strategies and recommendations to Quantum Safe
schemes".
[i.11] ETSI TS 133 501: "5G; Security architecture and procedures for 5G System (3GPP TS 33.501)".
[i.12] Recommendation ITU-T X.509: "Information technology - Open Systems Interconnection - The
Directory: Public-key and attribute certificate frameworks".
[i.13] IEEE 1609.2™: "IEEE Standard for Wireless Access in Vehicular Environments--Security
Services for Application and Management Messages".
[i.14] Proposal for a Regulation on cybersecurity requirements for products with digital elements - Cyber
resilience (CRA).
[i.15] US Cybersecurity Framework.
[i.16] Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the
protection of natural persons with regard to the processing of personal data and on the free
movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation).
[i.17] ETSI TS 103 963: "CYBER; Optical Network and Device Security; Security provisions in
transport network devices".
[i.18] ETSI TS 103 993: "Cyber Security (CYBER); ONDS Test Suite Structure and Test Purposes".
[i.19] ETSI TS 103 996: "Cyber Security (CYBER); ONDS Protection profile - Test cases".
ETSI
9 ETSI TS 103 962 V1.1.1 (2023-12)
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
canonical identifier: structured identifier that is globally unique
EXAMPLE: An IMSI is an example of a canonical identifier.
crypto-agile: able to utilize crypto-agility
crypto-agility: property that permits changing or upgrading cryptographic algorithms or parameters
root identity: canonical identifier of the device that is attested to in the root identity certificate of the device
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AAT Attribute Authority Tree
AEAD Authenticated Encryption with Associated Data
AES-GCM Advanced Encryption Scheme - Galois Counter Mode
CIA Confidentiality Integrity Availability
C-MAC Cipher based Message Authentication Code
ECDSA Elliptical Curve Digital Signature Algorithm
FTTB Fibre To The Building
FTTCab Fibre To The Cabinet
FTTH Fibre To The Home
IMSI International Mobile Subscriber Identity
MAC Message Authentication Code
NT Network Termination
OAN Optical Access Network
OLT Optical Line Termination
ON Optical Network
ONDS-M Optical Network Device Security Manage
ONT Optical Network Termination
ONU Optical Network Unit
OTN Optical Transport Network
PCB Printed Circuit Board
PON Passive Optical Network
RtS Root of trust for Storage
SNI Service Node Interface
SNMP Simple Network Management Protocol
TCG Trusted Computing Group
TLS Transport Layer Security
TPM Trusted Platform Manager
UNI User Network Interface
XGS 10-Gigabit-capable symmetric passive optical network
ETSI
10 ETSI TS 103 962 V1.1.1 (2023-12)
4 Overview of security of functions for optical access
network devices
4.1 Optical access network device functional model
The general provisions stated in ETSI TS 103 924 [1] apply to Optical Network (ON) devices operating in the access
network with the additional specializations given in the present document. The access network is defined as the set of
access links sharing the same network-side interfaces and supported by an optical access transmission system (see
Recommendation ITU-T G 9804.1 [2]). The Optical Access Network (OAN) may include a number of Optical Network
Units (ONUs) connected to the same Optical Line Termination (OLT). The OAN architecture is indicated in Figure 2.
An access device shall distinguish and separate the user and network domains in the device.

Figure 2: Optical Access Network device
The OAN and its associated devices consist of a single Optical Line Termination (OLT) facing the network side, one or
more Optical Network Units (ONUs) and one or more Network Terminations (NTs) facing the client as shown in
Figure 2.
NOTE: The ONU and the NT may be combined into a single unit and referred to as an Optical Network
Termination (ONT).
When deployed the OAN device supports a suite of services the specific configuration of which is out of scope of the
present document but examples of which are given in Annex E.
4.2 Trust architecture in Optical access network devices
As outlined in ETSI TS 103 924 [1] ON systems shall be designed to be secure by default and to support the
functionality required by the CIA paradigm (Confidentiality, Integrity, Availability). At initialization and at runtime all
links shall be established and security associations created within the trust and security policy established by the
operator of the equipment/network. Any link enabled during, and post-initialization, shall support periodic
re-establishment of the security association. The principles of least privilege and least persistence shall apply to all
security associations. In accordance with the least persistence principle security associations shall not be maintained for
longer than required. If any software verification fails (e.g. at power on test, at installation, at instantiation) that
software and any supporting elements shall not participate in any security association.
ETSI
11 ETSI TS 103 962 V1.1.1 (2023-12)
NOTE 1: The term "for longer than required" is somewhat vague but is intended to convey that open-ended
sessions with persistent security credentials are avoided, rather that a secured session with clear start and
end conditions is adopted by default, where the end condition can include a timeout, i.e. the session is
cleared after a set period.
All ON entities shall be able to report the form of CIA protections that are available and operational to authorized
entities.
NOTE 2: In order to be consistent with the model of transparency and explicability identified in ETSI
GR ETI 002 [i.4], in addition to the wider model of least privilege, all elements in the OAN-device and in
the connected chain of devices that form any security association related to the devices and the services it
supports it is expected that a management entity (local or remote) is able to interrogate the security status
of any part of the ON including OAN devices.
4.3 Generalized functional model for an Optical access network
device
An OAN device shall be integrated to the wider ON and telecommunications system of which it is a component and
shall itself be decomposed into a set of functional elements with respect to security functionality as follows: an OAN
device shall consist of at least 1 (one) execution environment which shall have 1 (one) initial root of trust (provisioned
by the platform manufacturer and initialized during the manufacturing process and that is the first to be executed within
the execution environment), and may have additional extended roots of trust (including those added by the operator).
The execution environment shall have at least one executable code block and may have 0 (zero) or more associated data
elements (including keys). In order to optimize separation of the client side, and network side, of the OAN device, there
should be a discrete execution environment for each side and discrete roots of trust for each side.
NOTE 1: As illustrated in the deployment scenarios in Annex E the client side of an OAN device is able to support
both single and multi-occupancy environments.
If an OAN device supports a multi-occupancy client environment (see Annex E) it shall provide confidentiality services
at the client side to ensure physical (e.g. by managed allocation of virtual channels in the optical bearer) and
cryptographic separation of distinct clients (i.e. if Client-A and Client-B are in a multi-occupancy termination of the
OAN device it should not be feasible for Client-A to have any access to the traffic of Client-B).
ETSI
12 ETSI TS 103 962 V1.1.1 (2023-12)

Figure 3: OAN Device functional architecture with respect
to security and processing environments
As illustrated in Figure 3 the OAN Device shall have a root of trust used for initialization to enable secure boot
capabilities. The root of trusts in the OAN Device shall be further decomposed as described below. The OAN Device
shall implement a root of trust where the scope of functions enabled by the root of trust shall be defined in succeeding
clauses of the present document.
The guidelines given in NIST SP 800-164 [i.2] shall be followed in order to provide the following local (device
specific) trust services:
• Root of Trust for Storage (RTS) - this shall provide a protected repository and a protected interface to store
and manage keying material (i.e. Public Keys and Public Key Certificates, symmetric keys and their related
security association records).
• Root of Trust for Verification (RTV) - this shall provide a cryptographic accelerator to verify digital signatures
associated with software/firmware and create assertions based on the results.
• Policy Enforcement Engine - to enforce the capabilities described by the ON Device Configuration Record.
NOTE 2: The root of trust may be implemented in a number of ways including specific chipsets or by specific
combinations of software and chipsets.
NOTE 3: It is not considered possible to verify the existence of a hardware root of trust by a protocol query.
The manufacturer of the OAN Device shall attest to the provision of the root of trust by reference to the method applied
(e.g. a TCG conformant TPM) and shall publish that attestation in the technical specification of the OAN Device.
In addition, as identified in the definition for root of trust in NIST SP 800-164 [i.2], the presence of the hardware root of
trust shall be asserted by a platform specific attribute certificate.
ETSI
13 ETSI TS 103 962 V1.1.1 (2023-12)
4.4 Guidance on cryptographic processes
All cryptographic modules shall be designed to be crypto-agile.
The specific cryptographic algorithms for each security association shall be defined by the security policy.
Cryptographic algorithms should be sufficient to inhibit known cryptanalysis attacks and mechanisms (see also the
impact of Quantum Computing on cryptography in ETSI EG 203 310 [i.8], ETSI GR QSC 004 [i.9] and ETSI
TR 103 619 [i.10]).
NOTE: If during the period of use the installed cryptographic modules are found to be vulnerable (e.g. by new
cryptanalysis or advances in computing or mathematics) the crypto-agility requirement allows the
vulnerability to be managed by updating the cryptographic modules.
The broad assumption that the key is secure applies and therefore advice on exploits of key material should be made
available and key update mechanisms implemented to inhibit attacks using such exploited key material.
4.5 Security error and misuse reporting
The security processes shall be self-monitoring and report detected errors to the local security authority which may in
turn report errors to a remote, central, security authority.
EXAMPLE 1: Self-monitoring may use an Intrusion Detection System (IDS) to detect malicious activity.
EXAMPLE 2: If a device identifies a potential denial of service attack it reports it to the local device security
manager process which should pass this message to a centralized authority in order to determine if
the attack is local or distributed.
EXAMPLE 3: If an authentication failure is noted it should be locally reported, however if there are persistent
failed attempts to authenticate this may indicate a pattern that can only be verified by reporting to a
centralized authority.
5 Identification and authentication of Optical access
network devices
5.1 Common provisions
The general provisions of the ON management standard (ETSI TS 103 961 [3]) apply wherein all devices shall be
identified with a canonical/root identity and, optionally, additional semantic identifiers identifying their functional
nature. The management entity, for the purposes of the present document, is referred to as the Optical Network Device
Security Manager (ONDS-M). Where provided, the semantic identifier shall be used to indicate the functional nature of
rd
the entity and the attestation of function shall be verifiable by reference to a 3 party. This is defined to be consistent
with the Attribute Authority Tree (AAT) model described in ETSI TS 103 486 (see bibliography). As with the AAT
model, it is not necessary to reveal all attributes of the device, rather only those attributes relevant to the current security
association should be made visible in a manner consistent with the principle of least privilege (see also clause 7).
EXAMPLE: A device is delivered and uses its manufacturer defined serial number as its primary identity in
which case the serial number is the canonical identifier, any attribute associated with the device,
e.g. its functional class, is a semantic identifier and is bound to the canonical identifier which then
acts as the "root" for the identity management of the device.
NOTE 1: The term "security association" is used in the widest sense to refer to the nature of the relationship
between any instance of devices or products.
The authentication process shall verify the ON entity's identity (e.g. a globally unique device address) to a shared key
assignment, and the to be authenticated identity shall be an attribute of the authentication protocol. The identity shall
always be authenticated on first presentation and periodically thereafter. In order to be consistent with the principle of
least persistence an authenticated session shall expire after a set time. The length of an authentication session shall be
set by the Authentication-Session-Time-Limit variable that shall be established for each security association.
ETSI
14 ETSI TS 103 962 V1.1.1 (2023-12)
NOTE 2: The value assigned to the Authentication-Session-Time-Limit variable can be established by the
ONDS-M or be explicit in the protocol used to establish the security association.
NOTE 3: If confidentiality protection uses an algorithm in Authenticated Encryption with Associated Data
(AEAD mode), e.g. AES-GCM, the associated data may form an element for persistent authentication of
data (over and above any use of an encryption key derived during the authentication phase).
NOTE 4: As above if an Encryption key is derived during authentication and is cryptographically linked to the
authentication key then any exchange using such an encryption key is implicitly authenticated to the
identity.
NOTE 5: The device unique address is out of scope of the present document but can include the device's card level
network card address.
A device shall be identified in order to be admitted to the operator's trust domain. Within the trust domain the trust
domain manager shall verify the capability of each device. Details of the overall management of the trust domain for
secure devices in the ON are given in ETSI TS 103 961 [3] and devices in the scope of the present device shall comply
to the requirements and provisions of ETSI TS 103 961 [3]. The considerations in Figure 4 apply in which an OAN
device is attested by an authority to be an OAN device, and where access control, alongside the device class provides
some restriction of the behaviour that can be exhibited by the OAN device.
NOTE 6: In any device there may be multiple discrete security trust associations to different elements in the
operator's trust domain in which case the processes describe in the present document apply independently
to each association.
Figure 4: Management of device identifier and capability by attestation and access control
A device shall present an identifier to each of the client and the network side of the device. It should not be feasible to
determine/infer the identifier presented to one side from knowledge of the identifier presented to the other side. As
mandated above any identifier presented by the device shall be authenticated by the receiving device.
NOTE 7: The access control service shown in Figure 4 may include additional behavioural attributes to restrict the
behaviour, and control of that behaviour (see also clause 7 of the present document).
NOTE 8: The form of managed identifier is defined in ETSI TS 103 961 [3].
NOTE 9: The permutation model described in ETSI TS 103 486 (see bibliography) therefore applies when
identifying a device and its capability.
ETSI
15 ETSI TS 103 962 V1.1.1 (2023-12)
5.2 Identification and authentication
5.2.1 Symmetric keyed systems
5.2.1.1 Symmetric key distribution
The ONDS-M, defined in ETSI TS 103 961 [3], is responsible for ensuring that symmetric keys for each specific
security association are made available at the device.
A key shall be associated to an attribute or identifier of the OAN Device. The binding of key to the attribute or identifier
shall be maintained for each security association. In a fully symmetrically keyed system keys may be maintained in
key-hierarchy with attribute keys derived from a single root key.
A symmetric keyed security association shall identify the following elements:
• Associated identity or Associated capability
• Root key-id (if part of a key hierarchy)
• CIA purpose (one of authentication, encryption, integrity)
• Algorithm (appropriate to CIA purpose, e.g. AES for Encryption, SHA for integrity).
5.2.1.2 MAC based systems
A Message Authentication Code (MAC) method should be used in established security associations as an alternative to
simple integrity check functions where the integrity, MAC, key is pre-defined or established as a session specific key
(based on the mechanisms used in clause 6.2 of ETSI TS 133 501 [i.11]). If used the provisions in the present document
apply.
The MAC approach to authentication as outlined in ETSI TS 102 165-2 [8] shall apply with the following
restrictions/specializations.
Random challenges used in any MAC based authentication (for anti-replay and other protocol specific measures) shall
be generated using a true source of randomness. The random challenge shall be generated from a source of appropriate
entropy, in particular software only functions shall not be used to generate such challenges (see also clause 4.3 of the
present document). As stated in ETSI TS 103 924 [1] (see annex B) any random challenges required in the
authentication protocol shall be generated using a method as described in Annex C of FIPS 140-2 [9] and using the
model of non-determinism from NIST SP 800-90B [10] or equivalent endorsed or mandated in specific markets.
NOTE: Where the OAN Device is an XGS-PON the mechanisms defined in Recommendation
ITU-T G.9807.1 [6] apply using the ONU Management and Control Interface (OMCI) message exchange
as per Annex C of Recommendation ITU-T G.987.3 [7].
5.2.1.3 Challenge response based systems
A challenge-response method should be used at initialization and for key establishment, key refresh, events. If used the
provisions in the present document apply. Only cryptographically relevant challenge response schemes shall be used
(i.e. the present document does not support challenge response based on non-cryptographic schemes (e.g. simple
password comparisons)).
The challenge response approach to authentication as outlined in ETSI TS 102 165-2 [8] shall apply with the following
restrictions/specializations.
Random challenges used in any challenge-response protocol shall be generated using a true source of randomness. In
particular software only functions shall not be used to generate such challenges.
EXAMPLE 1: Encryption based approach: The challenger generates a random number N and encrypt it using the
shared secret key and pre-defined algorithm and send this as the challenge. The recipient decrypts
the challenge to recover N and sends the response N+1 encrypted with the shared secret key.
(Challenge = N, expected response = N+1). The recipient is only able to send the correct expected
response if both parties have access to the same shared secret.
ETSI
16 ETSI TS 103 962 V1.1.1 (2023-12)
EXAMPLE 2: Hash based approach: The challenger generates a Random Challenge (RC) and send the RC to the
recipient. The recipient shall calculate the hash of the RC+shared-secret as Shared Response (SR)
and send SR to the challenger. The challenger similarly calculates SR and verifies it is the same as
that received. If the two values are the same it shows that both parties have access to the same
shared secret.
NOTE 1: Where the OAN Device is an XGS-PON the mechanisms defined in Recommendation
ITU-T G.9807.1 [6] apply using the X.802.1 methods as per Annex D of Recommendation
ITU-T G.987.3 [7].
NOTE 2: It is recognized that it is not possible to verify using black box testing that the source of randomness is a
hardware element and that an assertion by the manufacturer is required.
5.2.2 Asymmetric keyed systems (digital signature)
5.2.2.1 Self attestation of identity
A device should only be able to perform a self-attestation of its identity at initialization. The self-attestation shall be
provided in the form of a digital signature and include a signed public key.
EXAMPLE: Digital self-attestation is done by creating a document, hashing it and encrypting the hash with the
self-generated private key and distributing it with the public key. A recipient of the document
determines the hash of the document and compares that hash with the decrypted hash (using the
public key), if the hashes match the public key is provably associated to the private key and
therefore the document (e.g. the identity) is self-attested.
In order to perform self-attestation of identity the OAN device shall be able to securely generate cryptographic keys
associated with identifiers, and to securely store the private cryptographic material. Consequential requirements from
supporting self-attestation of identity are:
• The OAN device shall have a source of true randomness with entropy at least equal to the required security
strength of the cryptographic operations that rely upon this randomness.
• The OAN device shall have a root of trust for storage to store private cryptographic material (private key).
(See also clause 4.3 of the present document).
rd
5.2.2.2 3 party attestation of identity
The identity (canonical) and identifying attributes (see clauses 5.2.2.3 and 5.2.2.4) of a device should be attested to by
rd
an appropriate independent 3 party.
NOTE: This is consistent with the Attribute Authority Tree framework described in ETSI TS 103 486 (see
bibliography).
Proofs of identity shall be made available to corresponding parties using identity based public key certificates that
clearly identify the attesting authority and that are able to resolve to the Root Authority for the trust domain.
EXAMPLE: An X.509 [i.12] identity certificate may be used to prove attestations of the canonical identifier of
a device.
5.2.2.3 Self attestation of capability
A device should only be able to perform a self-attestation of its capability at initialization. The self-attestation shall be
provided in the form of a digital signature and include a self-signed public key.
NOTE 1: In ETSI TS 103 486 each capability is identified as an attribute that is nominally independent of the
root/canonical identity but is bound to it on creating an identified security association.
NOTE 2: In ETSI TS 103 486 each leaf attribute is also referred to as a semantic or contextual identifier.
ETSI
17 ETSI TS 103 962 V1.1.1 (2023-12)
rd
5.2.2.4 3 party attestation of capability
rd
Identifying attributes of a device should be attested to by an independent 3 party. The public key of the relevant
attribute authority should be installed locally to the device.
NOTE: This is consistent with the Attribute Authority Tree framework described in ETSI TS 103 486 (see
bibliography).
Proofs of identity shall be made available to corresponding parties using an attribute based public key certificate that
clearly identify the attesting authority and that are able to resolve to the Root Authority for the trust domain.
EXAMPLE 1: An IEEE 1609.2 [i.13] certificate with appropriate labelling of the permissions field may be used
to prove attestations of an attribute of a device.
EXAMPLE 2: An X.509 [i.12] attribute extension to an X.509 identity certificate may be used to prove
attestations of an attribute of a device.
6 Confidentiality and integrity protection of data
transfer between Optical access network devices
6.1 General provisions - integrity
The general principle is that all exchanged discrete messages shall have their integrity verified on reception at the
device. The integrity check function shall be cryptographically strong and may be included in a MAC for symmetric
keyed associations, or in a digital signature for asymmetric keyed associations. Any message that fails the inte
...