The sections below cover what is and is not working in this release of the SZTPD product.
Most everything listed as “not working” will be implemented before FCS.
This section describes what is working in SZTPD. All of the following has been tested1:
This section regards things that should work, but haven’t been tested yet.
IPv6: The default port binds to “127.0.0.1”, but this can be changed by setting the “SZTPD_DEFAULT_ADDR” environment variable. Other than this, there is no other IPv4-only code in the product as everything is handled by Python modules.
UTF-8: Python string types support both ASCII and unicode, like UTF-8. Presumably string handling is ambivalent, but this isn’t tested yet.
Windows: the software has been developed and tested exclusively in UNIX based systems. Python is very portable, and SZTPD has almost no interaction with the filesystem, so running on Windows might work, but this has not been tested.
The following features are sorted by the expected release they might show up in. Please let us know if there is something out of place or missing.
Increased max client message size to 32 MB (was 1MB).
RESTCONF entity-tag (ETag) Support. The HEAD and GET operations would return the “ETag” HTTP header field. The POST, PUT, and DELETE operations would inspect request headers for the “If-Match”, and “If-None-Match” fields. This enables concurrent clients to detect if changes are have been made since their using a HEAD or GET command. Support for Etag is a MUST in RFC 8040 only on the top-level datastore resource, and unspecified for inner-resources4
Implement the “ietf-restconf-monitoring” module per Section 9 of RFC 8040. This is needed to identify which capabilities (e.g., query params) and streams (e.g., the notifications) the SZTPD server supports.
Tenant view device-types and plugins. Currently, tenants can set ‘device-types’ and plugin-based ‘dynamic-callouts’ only if the values configured by the system administrator are provided out-of-band. For security and stability reasons, these values are only set at the “host” level, outside the tenant’s purview. A tenant’s clients should be able use either an RPC/action to get the supported device-types from the host, or have that information exposed as opstate (i.e., read-only “config false” values)5.
Authorization / access-control. It is planned to implement the admin-account “access” node, which sets an enumerated value being one of “unrestricted”, “typical”, and “minimal”.
Implicit change tracking. This is needed to support a few of the features listed below. It is also needed to detect when any part of the “transport” configuration changes, so that a SIGHUP can be issued. Currently SIGHUP is issued only when an “endpoint” is added or removed.
Bootstrapping event counter. SZTPD needs to maintain bootstrapping event counters.
Device record counters. It is planned to track when the device records are created, last modified, and the total number of modifications. Similarly, to track when the bootstrapping device first connected, last connected, and the total number of connections.
Reference tracking. It is desired to track references to objects in the system. In YANG terms, these are the ‘leafref’ statements that reference a ‘list’ statement’s ‘key’ node. Tracking includes the current number of references and the time of last reference.
Automated purging with notifications. It is desired to send notifications when unreferenced objects have been without a reference, for some configurable amount of time. A series of notifications with escalating urgency can be to sent to configurable notification receivers. A final notification is sent when the purging occurs.
Password expirations with notifications. This feature goes with the previously mentioned “automated purging with notifications” feature, but has its own “preferences” setting for the timeouts.
Email-based admin activations. It is intended that SZTPD will send email based notifications to newly created admins when their accounts are first created. It is important to validate the email address because the same email address may be emailed later when the password expiration date is approaching. This is why the email address is the primary key for the admin accounts.
Password minimum length constraints. Currently the “preference” setting for the admin account password’s minimum length constraint is ignored.
send notifications, as currently none are.
Remove support for mode ‘1’. This change would affect the NBI only (no impact on the device-facing ‘rfc8572’ SBI).
Reasons to remove mode ‘1’:
It may be important for non-production use environments (e.g., those used for evals and demos) to exactly mimic production environments.
Eliminates an artificial constraint for Mode ‘1’ deployments, in they can easily configure an additional “tenant” for whatever reason. It also eliminates need to ever have to migrate mode-1 deployments to a mode-x deployment, which would require a database migration..
The tenant-view provided by Mode ‘x’ quite nicely isolates system-level configuration enabling IT organizations to do the system-level install and then pass an “application” view that excludes the system-level install to another organization within the company.
Only supporting Mode-x could greatly simplify the YANG modules. This could be important to developers as they might need to look at the YANG modules in order to understand the data model exposed by the API. While the current YANG is navigable, it could be even more so if only supporting Mode-x.
Further simplify the YANG modules. Note that mode ‘0’ is already almost completely phased out, and yet the YANG modules have yet to be simplified…somewhat due to waiting to determine if also phasing out mode ‘1’.
Reasons to NOT remove mode ‘1’6:
Run the “verify-device-ownership” callouts at time of bootstrapping event (in addition to when the device record was first created). Seems like something that should be opt-ed into, and hence a feature that can be implemented later.
Webhook-based callouts dynamic callouts. Some webhooks were implemented before, but better to re-build them generically on top of plugin-based callbacks. Clients can use plugin-based callbacks for now as well.
Client certificate based auth to NBIs. Currently SZTPD implements client cert based auth to the SBI (i.e, ‘rfc8572-interface’). This is to extend that configuration into the NBIs also (i.e., ‘native’ and ‘tenant’). This would provide 2FA to the NBI.
RESTCONF “Last-Modified” support. The HEAD and GET operations would return the “Last-Modified” HTTP header field. The POST, PUT, and DELETE operations would inspect request headers for the “If-Modified-Since” and “If-Unmodified-Since” fields. Support for timestamps is a SHOULD in RFC 8040.
RESTCONF Filtering (depth + fields) query parameters. These query parameters are described by Section 4.8 of RFC 8040 to reduce the amount of data returned to the client. RFC 8040 does not require these query parameters to be supported. Workaround is for the client to discard the unwanted parts of the response itself.
RESTCONF: support the “content” query parameter. Required by RFC 8040, but very low value for SZTPD, because no “config true” values have interesting values in <operational> and most “config false” values should be queried directly…
The RESTCONF/HTTP “PATCH” method. Though a MUST in RFC 8040, it seems mostly like a nice-to-have in SZTPD…
Support a callout to retrieve an ownership voucher from an external system. This would implement the “supply-ownership-voucher” RPC defined in the “wn-sztpd-callbacks” module. The RPC is currently protected by a ‘feature’ statement called “supply-ownership-voucher”, thus programmatically signalling that it is not supported, though visible in the YANG.
Support signing conveyed information sent from SZTPD using the private key associated with a configured owner certificate.
Support encrypting conveyed information sent from SZTPD using the device’s public key from its identity certificate (e.g., IDevID).
Support stapling revocation responses to CMS objects returned to devices.
Private key encryption. It is desirable for SZTPD to have an ability to encrypt private keys via a “root” key. Note that this is above and beyond DB-level encryption; it purpose to to shield keys even from administrators having appropriate access. This root key would be protected by access control and/or an HSM.
Actions: None of the ‘action’ statements defined in the YANG modules are implemented yet. Primarily this effects the ability to create keys, and generate certificate signing requests. The workaround is to generate the keys and certs using an external PKI and then pass those values in as configuration.
Update the SBI’s “get-bootstrapping-data” response to strip-out the “ietf-sztp-conveyed-info:” prefix from the “hash-algorithm” value. Since the namespace is already “ietf-sztp-conveyed-info”, the value MAY be prefixed, and while it is considered clearer to always use prefixes, it may be considered cluttering in this instance…
Fully remove mode ‘0’ by 1) restructuring the YANG modules (no impact to API) and 2) in DAL, optimize code bits having mode ‘0’ handling. Mostly to simplify code, but might improve performance.
Factor out app-layer into its own modular package. –>
Due to issues with both Python (when SZTPD itself terminates TLS connections) and NGINX (when NGINX terminates TLS connections) limit client certificates to containing just the end-entity certificate (no intermediate certificates). That said, it is unusual for identity certificates (e.g., an IDevID or LDevID certificate) to include any intermediates certificates, so may not be an issue in practice. The Python issue is likely to be resolved in an upcoming Python release. It is unclear when the NGINX issue will be resolved.
Python (currently) is unable to staple OSCP Responses to the TLS Handshake. Workaround, if needed at all, is to front SZTPD with an external TLS Terminator, which is better for perfomance anyway.
As of 0.0.7, the wn-sztpd-1 module will NOT validate tenant-views having “device” entries. This is because the “device-type” leafref is now “require-instance true”, but the tenant-view is unable to access the “device-type” entries present only at the host-level. Until resolved, clients accessing the tenant-view SHOULD modify the leafref to have “require-instance false”, as described by Section 9.9.3 of RFC 7950.
Enabled TLS ports to use RSA-based keys (extended deep-inspection logic)
Enabled TLS server certs to be unordered inside the CMS structure when configured.
Logic now removes the <content-data> wrapper from XML-based conveyed-information responses.
Added support for the ‘relay-progress-report’ dyanmic-callout. Previously only the webhook was supported.
Rewrote the support for “ordered-by user” lists to be more scalable.
Added initial support for pagination query parameters (‘limit’, ‘offset’, and ‘direction’).
Added XML support for the SBI (now supports both JSON and XML). Strong HTTP header checking.
Added strong validation for known base64-encoded values (public keys, private keys, end-entity certificates, and trust anchor certificates) when being configured.
Changed “/transport/listen/endpoint/use-for” to be a “mandatory true” leaf; it was a “mandatory false” leaf-list, thus removing the ability for an endpoint to present more than one API, which was unnecessarily present before.
The “ordered-by user” query parameters (point + insert) now work, per Section 4.8 of RFC 8040[There are three “ordered-by user” lists in SZTPD: download-uris, bootstrap-servers, and matched-responses (the first two are leaf-lists).][Be advised that the “download-uri” leaf-list uses URL as keys; the client MUST percent-encode these URL-based keys.].
Modified the “wn-sztpd-1” YANG module to set the per-device device-type leafref to “require-instance true” (was false).
Implemented the “SZTPD_DEFAULT_ADDR” environment variable, as described in the Installation Guide.
There is more than twice the number of lines of test code than code in SZTPD itself.↩︎
An external TLS-terminator must be used when an SZTPD listening port is configured to NOT use HTTP.↩︎
Note that the top-level resource for the tenant-view is mounted to /tenants/tenant.↩︎
Current plan is to do the latter, but due to limitations in YANG, need to split the sztpd-1 schema into two: one for ‘native’ view and another for the ‘tenant’ view.↩︎
if decide to keep mode ‘1’, the YANG can still be simplified by removing support for mode ‘0’.↩︎