Pfaff Et Al NETCONF Security 0321 v01
Pfaff Et Al NETCONF Security 0321 v01
Pfaff Et Al NETCONF Security 0321 v01
• Provide a deep-dive for NETCONF security (as-is) from the perspective of industrial automation
esp. IA devices/controllers
• Report the fitness of NETCONF security for industrial automation
• Use specification documents for this analysis (implementations are not considered herein)
• See the accompanying overview slide-deck for the abstractions/terms etc. considered herein
• Note: deep-dives (according the same scheme) will be made for all short-listed candidates
Siemens AG 2021
Page 2 2021-03-10 Siemens AG
Fitness of As-Is NETCONF Security for
Industrial Automation
Siemens AG 2021
Page 4 2021-03-10 Siemens AG
Action Items Possibly Beyond Profiling Include
• Security for shared resources:
• Message exchange protection: n.a.
• Resource access authorization: reconfirm authorization model DAC vs. MAC/ABAC/RBAC…
• Shared security means: n.a.
• Securing-the-security:
• Supply of own (private keys and) EE certificates to NETCONF servers
• SZTP bootstrapping/credentialing of network components without any initial credentials
• Supply credentials/trust anchors to NETCONF clients
• Push support for credential/trust anchor management
• Elaborate the assignment/management/identification of the NACM root-of-authority
• Cover equipment originality checks
• Enforce overall security configuration, e.g. allow only protected access
Siemens AG 2021
Page 5 2021-03-10 Siemens AG
NETCONF Security Mind-Map
Security for [NETCONF](https://tools.ietf.org/html/rfc6241)
# Security
- Communication pattern: client/server, over reliable transport (TCP)
- Components model: client, server
- Client incarnations: application-level component, usually part of a 'network manager' application, possibly operated by human user
- Server incarnations: application-level component, usually part of a 'network device'
- Note: client and server incarnations may be co-located in a system component
- Security: [mandatory i.e. there is no 'NETCONF-plain'](https://tools.ietf.org/html/rfc6241#section-2.2)
• Copy the markdown source from the grey text field on the
- Cipher suites: must support [TLS_RSA_WITH_AES_128_CBC_SHA](https://tools.ietf.org/html/rfc5246#section-9)
- TLS extensions: not explicitly addressed, implicitly addressed via [Secure Use Recommendations](https://tools.ietf.org/html/rfc7525)
#### Entity Authentication
- Mode: mutual authentication
- Means: asymmetric (key pairs) schemes
- Key&entity binding: 3rd-party objects certifying the binding of a public key and entity identification
- Form factor: ASN.1, [X.509 public key certificates](https://tools.ietf.org/html/rfc6187)
- Certificate validation: path validation or explicit acceptance of EE certificates
https://markmap.js.org/repl
- Mode: mutual authentication
- Means: asymmetric (key pairs) or symmetric (passwords) schemes
- Key&entity binding: 3rd-party objects certifying the binding of a public key and entity identification or raw public key/password with verifier-local mapping tables to system entities
- Form factor: ASN.1, [X.509 public key certificates](https://tools.ietf.org/html/rfc5280#section-4) or raw public key or plaintext password
- Certificate validation: [path validation](https://tools.ietf.org/html/rfc6187#section-2.1) or dedicated checks against verifier-local mapping table
- Certification path validation: [RFC 5280](https://tools.ietf.org/html/rfc5280#section-6)
- Server identification: [DNS name or IP address in subjectAltName](https://tools.ietf.org/html/rfc6187#section-4) in EE certificate or verifier-local mapping table
- Server identity check: client-side SSH engine matches ["actual vs. expected"](https://tools.ietf.org/html/rfc6187#section-4)
- Client identification: username
- Client identity check: server-side application checks ["actual vs. expected"](https://tools.ietf.org/html/rfc7589#section-7) based on a list of known NETCONF 'usernames'
#### Integrity
# Securing-the-Security
## Credential Management
- TLS: NETCONF clients and servers must be equipped with EE certificate/private key and CA certificate(s) aka trust anchors
- SSH: NETCONF clients and servers must be equipped with EE certificate/private key and CA certificate(s) aka trust anchors or raw public keys/passwords
### [SZTP](https://tools.ietf.org/html/rfc8572)
- Addresses the credentialing of 'network devices' i.e. NETCONF (or RESTCONF) servers
#### Functionality
- Prerequisite: a 'network device' has [initial credential/trust anchor info](https://tools.ietf.org/html/rfc8572#section-5.1)
- Event: the 'network device' is booting in factory-default state
- Task: provision information to this 'network device' during its boot from factory-default
- Forms of bootstrapping data: represented in YANG, expressed in JSON or XML
- Types of bootstrapping data: 'redirect' or 'onboarding' information, owner certificate, ownership voucher
- Redirect information: [host/port and trust anchor of another SZTP server](https://tools.ietf.org/html/rfc8572#section-2.1)
- Onboarding information: [boot image, configuration, scripting](https://tools.ietf.org/html/rfc8572#section-2.2)
- Owner certificate: 3rd party EE certification path, supersigned in a way that can be validated with the device's initial credential(s)
- Ownership voucher: owner info, local trust anchor, supersigned in a way that can be validated with the device's initial credential(s)
- Important: the own EE certificate (and private key) is not provisioned by SZTP
- Sources of bootstrapping data: SZTP bootstrapping server, DNS/DHCP server, removable storage
- SZTP bootstrapping server protocol: HTTP-over-TLS according RESTCONF
- Supply model: pull i.e. a to-be-provisioned 'network device' (usually a NETCONF server) acts as client of a SZTP bootstrap or DNS/DHCP server
#### Security
- Strategy: deprotect_with_initial_or_current (plain vanilla) or deprotect_with_subsequent (an indirection trick, uses voucher objects)
##### Message Exchange Protection
- The 'bootstrapping data' sent to the device is to-be-protected (may also be plain in some case)
- Protection is supposed to happen on application object-level: ‘bootstrapping data' is signed or first-signed-then-encrypted
- The protected 'bootstrapping data' is expressed in ASN.1, [CMS](https://tools.ietf.org/html/rfc5652). Note: this provokes media-breaks
- The protection must happen in a way so that the to-be-provisioned 'network device' can verify or decrypt-and-verify
- [To do this the 'network device' is assumed to have an initial equipment with credentials](https://tools.ietf.org/html/rfc8572#section-5.1)
- This may be an IDevID or LDevID credentials
- The use of [IDevID credentials](https://tools.ietf.org/html/rfc8572#section-9.2) is recommended
- The organization that equips network devices with initial credentials has to supply a 'call-home' infrastructure capable of supplying (device instance-specific) protected bootstrapping
data upon request
- Alternative: coin such information in advance and distribute it for supply via DNS/DHCP server or removable storage
##### Resource Access Authorization
- No granularity (accept all - if verification with IDevID was ok)
## System Configuration
### Credential Metadata
- [YANG Data Model for a Truststore](https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-14)
- [YANG Data Model for a Keystore](https://tools.ietf.org/html/draft-ietf-netconf-keystore-20)
### ['Users'](https://tools.ietf.org/html/rfc7317)
- Representation: arbitrary strings e.g. "brmpflzipf" representing an authenticated entity (caller)
- Mapping options: i. from client identification in TLS/SSH, ii. against remote repo's, iii. against local info
#### Functionality
- Mapping from TLS/SSH: no explicit CRUD operations for 'user' objects (happens implicitly)
- Mapping against remote repos: CRUD is subject to remote systems e.g. RADIUS
- Mapping against local info: skipped for this deep-dive
#### Security
- Mapping from TLS/SSH: subject to client credential management practices
- Mapping against remote repos: subject to remote systems e.g. RADIUS
- Mapping against local info: skipped for this deep-dive
### Authorization Data
- Strategy: authorization management and authorization controlled operations use the same (!) channel
#### Functionality
- See NACM section above
#### Security
Page 6 Siemens AG
### Others
2021-03-10
#### IA Device/Controller-Global Configuration e.g. 'PROTECTED-ONLY'
- Not elaborated
Next Steps
1. Kicking-off - Done
2. Establish goals and constraints, agree on use cases (automation and security-specific)
3. Perform deep-dives for the security technology candidates
i. NETCONF security – Largely done
ii. SNMP security
iii. DNS security
iv. 802.1AE/X/AR
v. 802.1AS security
vi. NN, decide about items from the longlist
4. Identify cross-relation/common interests with middleware/application-specific security
• Shortlist: security for IEC 61158 technologies, OPC-UA security, Web security…
5. Create the blueprint of an overarching security architecture (more details are tbd)
Siemens AG 2021
Page 7 2021-03-10 Siemens AG
Abbreviations*
ABAC Attribute-Based Access Control
DASA Delegated Authorized Signing Authority
MAC Mandatory Access Control
MASA Manufacturer Authorized Signing Authority
NACM NETCONF Access Control Model
RBAC Role-Based Access Control
SZTP Secure Zero Touch Provisioning
XACML eXtensible Access Control Markup Language
Siemens AG 2021
Page 8 2021-03-10 *: see the accompanying overview slide-deck for further abbreviations Siemens AG
References, Chronologically Ordered
1. IETF RFC 4741: Network Configuration Protocol, 2006
2. IETF RFC 4742: Using the NETCONF Protocol over Secure Shell (SSH), 2006
3. IETF RFC 5539: NETCONF over Transport Layer Security (TLS), 2009
4. IETF RFC 6187: X.509v3 Certificates for Secure Shell Authentication, 2011
5. IETF RFC 6241: Network Configuration Protocol (NETCONF), 2011
6. IETF RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH), 2011
7. IETF RFC 6536: Network Configuration Protocol (NETCONF) Access Control Model, 2012
8. IETF RFC 7589: Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509
Authentication, 2015
9. IETF RFC 8071: NETCONF Call Home and RESTCONF Call Home, 2017
10. IETF RFC 8341: Network Configuration Access Control Model, 2018
11. IETF RFC 8366: A Voucher Artifact for Bootstrapping Protocols, 2018
12. IETF RFC 8572: Secure Zero Touch Provisioning (SZTP), 2019
Siemens AG 2021
Page 9 2021-03-10 Siemens AG
Authors
Siemens AG 2021
Page 10 2021-03-10 Siemens AG
Security Fulfilment Disciplines Explained
Establish security associations Establish (authenticated) keys and Prepare the TLS record layer(s)
with endpoints on IA further security settings between for operation by doing a TLS
devices/controllers communicating partners handshake
MASA/DASA
1c (2c…) Voucher response (alternative:
1b (2b…) Voucher request pre-coined, nonceless vouchers)
SZTP bootstrap server
(known or redirected)
1d (2d…) Bootstrap response
1a (2a… ) Bootstrap request
{Redirection: server host/port/trust anchor OR
Bootstrap
Network host, port Onboarding: boot image, config, scripts} AND(opt.)
device {Owner certificate: signed EE certification path (3rd party) AND
Subsequent
Current Ownership voucher: signed owner info, trust anchor}
Siemens AG 2021
Page 13 2021-03-10 Siemens AG