Security Overview ONF OIMT Core 20 th Feb

Agenda Premise Three “As” Mechanisms Encryption • Components & Concepts • Securing data at

Premise Limiting operations to authorized entities • Operation: anything • Establishing a connection to a system • Receiving a PING (or any) packet • SCRUD on an object • Receiving any packet • RPC • Executing code • Entity: any interaction • Man/Machine • System components • Machine/Machine • Software source • Authorized: • Requires knowing identity of requesting entity • Shared authorization information has been used, but not operationally desirable • Identity needs to be validated – is it authentic? “Authentication” • Authorization determines if identified entity is allowed to perform the requested operation Note: Also includes unintended operations • E. g. Accidental Read operation on data not authorized to receive (i. e. due to a bug) © 2020 Infinera 3

The three “As” Is the identity presented to me authentic? (Authentication) • Three types of authentication factors • Something entity knows: Shared Secret, Password • Something entity has: Cryptographic key • Something entity is: Biometrics • Multi-factor authentication Is the identity presented allowed to perform the operation? (Authorization) • Policy with many inputs • Identity presented, operation, object instance • Time of Day, Behaviors (e. g. Frequency, sequence) Did something happen that was not “right”? (Auditing) • Debugging, Forensic • On-line vs Post-event analysis © 2020 Infinera 4

A bit more on Authorization Security Principle: Least Privilege • The privileges granted to a entity is limited to the minimum required to perform the organization mission/business function assigned to the entity • Prevents entities from accidentally or maliciously performing operations Example: • An operator may have a role that configure authentication processes (e. g. X. 509 trust relationships) • An operator may have a role that enable access for an entity (e. g. SSH login) • An operator may have a role that define operations an entity is allowed to perform on an object class (e. g. assignment of role performed by entity) • An operator may have a role that defines object instances an entity may be able to operate on (e. g. assignment of resources to a network slice) • These functions are all orthogonal • While they all appear to be “security related”, different actors may perform these roles. © 2020 Infinera 5

A bit more on Authorization (part 2) Inputs to Authorization Process • Validated Identity – • Examples: common name, login name, X. 509 subject • Operation being performed • Object being operated on • Situational parameters • Time of Day, Frequency, Sequence, IP Address of request • Authorization Policy • Code-driven authorization policy provides ‘fixed’ authorization of Identity/Operation/Object class • Data-driven authorization policy enables changeable authorization without needing to change code • Policy may utilize groups to associate a role with a set of identities. Group membership is also data-driven • Note: system will ships with a default policy. Mirroring existing Code-driven policy provides backward compatibility. © 2020 Infinera 6

A bit more on Authorization (part 3) Data-driven authorization policy • Specification of group • Group of identities Groups are used to specify roles (Sec. Admin, Net. Admin, Prov, Test. Turnup) • Group of groups • Specification of permitted operations by a group on an object class or instance • Could be an object model specific to access policy • E. g. Unix password database providing authorization of a user to access system • Could be attribute information within the object instance • E. g. Unix filesystem attributes • Should have support for situational parameters IETF NACM Slicing: specification of policy on sets of object instances © 2020 Infinera 7

Mechanisms Most security methods utilize encryption • Authentication • Eavesdropping protection • Non-repudiation Encryption is “Security through obscurity” • There is a key that will provide authentication, unlock an obscured message stream, etc. • Strength is dependent on how easy the key can be determined © 2020 Infinera 8

Concepts Brute-force Attack • Attempt to decrypt data using all key values Encryption Strength • How long does it take a Brute-force Attack with current CPU, attack methods? • Stronger as the amount of time increases: E. g. life of known universe Non-repudiation • Ability to prove an event, log, packet, etc. is authentic Data-in-motion • Data being carried over a network Data-at-rest • Data stored in memory (transient, permanent) © 2020 Infinera 9

Component types Random Number Generator: Used to create encryption Keys • Need sufficient entropy Symmetric Encryption: Secure data exchange using a shared key • Typically CPU efficient (i. e. fast) Asymmetric Encryption: Secure data exchange using a private/public key pair • Data encrypted using one key (e. g. private key) is only decrypted using other key (e. g. public key) • Typically not CPU efficient (i. e. slow) Diffie-Hellman Exchange: Secure exchange of a shared secret between two parties • Solves problem of key exchange across an untrusted environment Hashing: One-way mechanism to “fingerprint” data • Collision rate important © 2020 Infinera 10

Securing Data At Rest Eavesdropping protection • Persisted data • Sensitive data (CSP) are encrypted • E. g. Authentication keys • Need to be zeroized on system threat • Master Key generated when NE is first provisioned • Key is system specific © 2020 Infinera 11

Securing Data In Motion Multi-layered approach • Securing of dataplane communication • Symmetric Encryption w/ Periodic rekeying • Key changeover synchronization CA • Hashing – Non-repudiation • Random Number Generator: Generate dataplane key • Exchanging of Keys • Separate communication • Diffie-Hellman to exchange session key • Uses additional random numbers • Symmetric Encryption, Hashing, Rekeying DB • Authentication • Strongest – Pub/Priv Keys • Asymmetric Encryption • PKI - Certificate trust model Auth Key Mgmt RNG • Certificate Authority “In the Clear” Sym Enc • Clear-text information w/ Dig Signatures data • Encrypted hash - More Random Numbers DB RNG IP Fwd Sym Enc “In the Clear” data • Authorization based on configuration • Uses Certificate identity information © 2020 Infinera 12

References Common Criteria (ISO 15408) • https: //www. commoncriteriaportal. org/files/ppfiles/CPP_ND_V 2. 1. pdf NIAP: • https: //www. niap-ccevs. org/ FIPS: • FIPS 140 -2 (sunset 6/2020) • https: //csrc. nist. gov/publications/detail/itl-bulletin/2014/12/cryptographic-module-validation-program-cmvp/final • https: //csrc. nist. gov/publications/detail/fips/140/2/final • https: //csrc. nist. gov/csrc/media/projects/cryptographic-module-validation-program/documents/fips 140 -2/fips 1402 ig. pdf • FIPS 140 -3 (based on ISO 19790, ISO 24759) • https: //csrc. nist. gov/publications/detail/fips/140/3/final • https: //csrc. nist. gov/publications/detail/sp/800 -140/draft IETF • RFC 5280, “Internet X. 509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile” • https: //tools. ietf. org/html/rfc 5280 • RFC 8341, “Network Configuration Access Control Model” • https: //tools. ietf. org/html/rfc 8341 © 2020 Infinera 13

Net. Conf Access Control Module (RFC 8341) Defines a data-driven authorization policy - Two major branches • Groups • Collection of users that will have the same authority • Rule Lists • Statements that permit/deny individuals or groups to perform operations on sets of object Sets of Objects are defined by • YANG module • XPATHs • Can reference a container or a specific data element © 2020 Infinera 15

Example – Groups <nacm xmlns="urn: ietf: params: xml: ns: yang: ietf-netconf-acm"> <groups> <group> <name>admin</name> <user-name>admin</user-name> <user-name>andy</user-name> </group> <name>limited</name> <user-name>wilma</user-name> <user-name>bam-bam</user-name> </group> <name>guest</name> <user-name>guest</user-name> <user-name>guest@example. com</user-name> </groups> </nacm> © 2020 Infinera 16

Example – Module Access Control <nacm xmlns="urn: ietf: params: xml: ns: yang: ietf-netconf-acm"> <rule-list> <name>guest-limited-acl</name> <group>limited</group> <group>guest</group> <rule> <name>deny-kill-session</name> <module-name>ietf-netconf</module-name> <rpc-name>kill-session</rpc-name> <access-operations>exec</access-operations> <action>deny</action> <comment> Do not allow the 'limited' group or the 'guest' group to kill another session. </comment> </rule> <name>deny-delete-config</name> <module-name>ietf-netconf</module-name> <rpc-name>delete-config</rpc-name> <access-operations>exec</access-operations> <action>deny</action> <comment> Do not allow the 'limited' group or the 'guest' group to delete any configurations. </comment> </rule-list> © 2020 Infinera 17

Example – PATHs Access Control <nacm xmlns="urn: ietf: params: xml: ns: yang: ietf-netconf-acm"> <rule-list> <name>guest-acl</name> <group>guest</group> <rule-list> <name>limited-acl</name> <group>limited</group> <rule> <name>deny-nacm</name> <path xmlns: n="urn: ietf: params: xml: ns: yang: ietf-netconf-acm"> /n: nacm </path> <access-operations>*</access-operations> <action>deny</action> <comment> Deny the 'guest' group any access to the /nacm data. </comment> </rule-list> <rule> <name>permit-acme-config</name> <path xmlns: acme="http: //example. com/ns/netconf"> /acme: acme-netconf/acme: config-parameters </path> <access-operations> read create update delete</access-operations> <action>permit</action> <comment> Allow the 'limited' group complete access to the acme NETCONF configuration parameters. </comment> </rule-list> . © 2020 Infinera 18

Some shortcomings A lot of policy statements will be required • Multiple groups could have varying rights for operations on the same object set • E. g. Group 1: RO, Group 2: RW, Group 3: RWX • Access control may be performed on a subset of object instances in a container Does not include “modifiers” for situational parameters • E. g. Sequence of operation, frequency of operation These could be addressed by “extensions” to the NACM model © 2020 Infinera 19