Network Working Group C. P. Liu Internet-Draft Huawei Intended status: Standards Track 6 July 2026 Expires: 7 January 2027 Cryptographic Asset Discovery and Inventory draft-liu-cadi-01 Abstract This document compiles existing Cryptographic Asset Discovery and Inventory (CADI) methods and analyze potential gaps. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Liu Expires 7 January 2027 [Page 1] Internet-Draft CADI July 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement and Challenges . . . . . . . . . . . . . . 3 4. Discovery and Identification . . . . . . . . . . . . . . . . 4 4.1. Active Identification . . . . . . . . . . . . . . . . . . 5 4.1.1. Cryptographic Bill of Materials (CBOM) and Auxiliary Methods . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Passive Identification . . . . . . . . . . . . . . . . . 7 4.2.1. Simulated Handshakes . . . . . . . . . . . . . . . . 7 4.2.2. Traffic Pattern Analysis . . . . . . . . . . . . . . 9 4.2.3. Process Identification . . . . . . . . . . . . . . . 9 4.2.4. Configuration Extraction . . . . . . . . . . . . . . 10 5. Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Potentially Related Working Groups . . . . . . . . . . . . . 11 7. Tools Compilation . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Cryptographic Asset Discovery and Inventory (CADI) refers to a set of tools and guidelines that assist in identifying, collecting, normalizing, correlating, and continuously maintaining all cryptography-related assets, including configurations, dependencies, and usage contexts within a given organization, system, or product scope. It requires both technical tools and management approaches. Many Post-Quantum transition roadmaps have highlighted the importance of identifying legacy cryptographic assets inside of an organization as a crucial preparatory part. For example: * The G7 statement on "Advancing a Coordinated Roadmap for the Transition to Post-Quantum Cryptography in the Financial Sector" [G7] mentions there should exist six key PQ-migration activities: - Awareness and Preparation, *Discovery and Inventory*, Risk Assessment and Planning, Migration Execution, Migration Testing, Validation and Monitoring. The exact six stages are also published in NCCoE analysis on "Six Key Phases of the PQC Migration Journey" [NCCOEFAQ]. Liu Expires 7 January 2027 [Page 2] Internet-Draft CADI July 2026 * The United States Memorandum for the Heads of Executive Departments and Agencies on "Migrating to Post-Quantum Cryptography" [OMBM2302] requires: - All federal agencies to "*Submit cryptographic system inventory By May 4, 2023 and annually thereafter*". This important date is also mentioned in CISA directive "Strategy for Migrating to Automated Post-Quantum Cryptography Discovery and Inventory Tools"[CISAACDI]. Although the exact PQ-migration roadmap in each different nations varies, the fact that cryptographic asset discovery and inventory is a key prerequisite for Chief Information Security Officers to asses a migration budget and draft a migration plan does not change. In this draft, we analyze existing CADI methods and potential gaps. 2. Terminology * CADI (Cryptographic Asset Discovery and Inventory) -- A set of tools and guidelines designed to automate the identification, collection, normalization, correlation, and lifecycle management of an organization's cryptographic assets. * Cryptographic Asset -- A digital or physical element within a device or service-such as an algorithm, module, configuration, credential, secret, or communication protocol-that protects the confidentiality and integrity of secure data transmission or storage. * Cryptographic System -- An active software or hardware implementation of one or more cryptographic algorithms that provide one or more of the following services: (1) creation and exchange of encryption keys; (2) encrypted connections; or (3) creation and validation of digital signatures. (according to [OMBM2302]) * Cryptographically Relevant Quantum Computers (CRQC) -- A fault- tolerant quantum system capable of solving the underlying hardness assumption problems of widely used public-key cryptography in polynomial time, such as RSA and ECC. 3. Problem Statement and Challenges Apart from the milestones and requirements discussed above, there are also a few challenges to identify cryptographic assets: Liu Expires 7 January 2027 [Page 3] Internet-Draft CADI July 2026 * Legacy ICT systems were not engineered to treat cryptographic primitives as distinct, trackable assets. Instead, cryptographic implementations are deeply integrated, highly distributed, and hidden across heterogeneous layers of the technology stack. * Taking inventory manually would take enormous amount of effort, yet there may still be statistical omissions that leave security exposures. * Methods like Cryptographic Bill of Materials (CBOM) only take effect on new devices to self-announce its cryprographic assets, but it cannot help identify legacy devices and systems. * Legacy devices and systems often behave like blackboxes, many does not allow installing additional programs or tools on them. As a result, the ideal CADI tool should meet the following requirements: * *Automated* scanning and inventory taking * *Agnostic* to target object's system designs and architectures * *Integrate* the result to existing network management and operations systems for unified presentation The requirements for automation, architectural agnosticism, and network management integration suggest a protocol-driven approach, potentially placing this within the scope of the IETF. However, this remains open for discussion. 4. Discovery and Identification There are many ways of doing discovering and identification. We catagorize them into two: active identification and passive identification. * *Active Identification*: The case where devices and services modifies its development and/or management process, actively self- announcing their cryptographic assets. Methods falls into this category includes: - CBOM Declaration - Static Code Scanning - Binary / Image Scanning Liu Expires 7 January 2027 [Page 4] Internet-Draft CADI July 2026 - CI/CD Integration * *Passive Identification*: The case where devices and services will stay as-is and cannot self-announce their cryptographic assets. These devices will require additional external tools to assist the identification. Methods falls into this category includes: - Simulated Handshakes - Configuration Extraction - Traffic Pattern Analysis - Process Identification 4.1. Active Identification 4.1.1. Cryptographic Bill of Materials (CBOM) and Auxiliary Methods CBOM-based identification is to empower cryptographic asset owners or vendors to explicitly declare cryptographic usage within their products, components, or services. Usually CBOM declaration is achieved through static code scanning and/or CI/CD integration, so we keep them in the same section. *Scanning Methods:* * *Static Code Scanning*: - SCA (Software Composition Analysis): Scan manifest files (like package.json, requirements.txt, or pom.xml) from the codebase to create CBOMS, usually for analyzing third-party libraries dependency. - SAST (Static Application Security Testing): Builds a Abstract Syntax Tree (AST) with parsed syntax and data flow of the target source code. It then uses AST to track call chain to end crypto library, track variables (data flow) from source to destination, do reference matching, etc. o SCA and SAST is used by IBM CBOMKit-Hyperion. * *Binary / Image Scanning*: - Scan for algorithmic constants, signatures; Extract from OS trust stores and runtime configurations... The process details are omitted in this document due to complexity. Liu Expires 7 January 2027 [Page 5] Internet-Draft CADI July 2026 o Binary / Image Scanning is used by IBM CBOMKit-Theia and CycloneDX Cdxgen. *Tools and Modelling:* * *IBM CBOMkit*, Static code level scanning (Hyperion) and Artifact level scanning (Theia) [IBMCBOM]: uses implements and uses relationship to create dependency diagram. - implements: Describes the list of protocols or algorithms this module implements. - uses: Describes what modules are used by this service. - For example, Application Nginx uses Library libssl.so that uses Protocol TLS v1.3/v1.2 that uses libcrypto.so that implements Algorithm MD5, SHA256, AES-128-GCM. * *CycloneDX Cdxgen*, Artifact level scanning [CDXGEN]: uses dependsOn and provides relationship to create dependency diagram. - dependsOn: Describes other modules or services this module depends on. - provides: Describes all capabilities this module provides. - For example, Application Nginx dependsOn Library libssl.so , which provides TLS 1.2. After scanning, the result will be recorded as a CBOM object. *CBOM data specification:* A standardized cryptographic asset object includes cryptographic algorithms, digital certificates, protocols, private keys, public keys, cryptographic keys, ciphertext information, digital signatures, digests (the output values of hash functions), initialization vectors (input parameters for encryption algorithms), seeds, salts, shared secrets, authentication tags, passwords, credentials, and tokens. For a detailed specification, see CycloneDX SBOM v1.6 https://cyclonedx.org/news/cyclonedx- v1.6-released/ Liu Expires 7 January 2027 [Page 6] Internet-Draft CADI July 2026 "components": [ { "name": "google.com", "type": "cryptographic-asset", "bom-ref": "crypto/certificate/google.com@sha256:1e15e0fbd3ce9...", "cryptoProperties": { "assetType": "certificate", "certificateProperties": { "subjectName": "CN = www.google.com", "issuerName": "C = US, O = Google Trust ... LLC, CN = GTS CA 1C3", "notValidBefore": "2016-11-21T08:00:00Z", "notValidAfter": "2017-11-22T07:59:59Z", "signatureAlgorithmRef": "crypto/algorithm/sha-512-rsa@1.2.840..", "subjectPublicKeyRef": "crypto/key/rsa-2048@1.2.840.113549.1.1.1", "certificateFormat": "X.509", "certificateExtension": "crt" } } _Figure 1: Example CBOM_ *Gaps:* Obviously, this does not help with identifying the mass legacy devices, components or services. 4.2. Passive Identification 4.2.1. Simulated Handshakes Simulated handshake is a network-probing technique where a discovery tool acts as a client and intentionally initiates cryptographic protocol negotiations (e.g., TLS, SSH, IPsec) with enterprise network endpoints without completing the full data session. During the negotiation process, the discovery tool determines the specific cryptographic protocol versions, negotiation mechanisms, and ciphersuites supported by the endpoint. This is also known as _Active Probing_. *Steps of simulated handshake include:* 1. *Port Scan:* The tool scans for typical ports for specific secure communication protocols (443 for HTTPS, 22 for SSH, etc) 2. *Probing:* The tool generates a RFC-compliant connection initialization packet, including all currently standardized ciphersuites, and examine the response. 3. *Response Extraction:* The target object respond with supported ciphersuites, following its own internal priority rules. Liu Expires 7 January 2027 [Page 7] Internet-Draft CADI July 2026 4. *Parsing:* The tool intercepts this raw response and decodes it as cryptographic assets. This works for most secure protocols that includes negotiation: * IPSEC * TLS * SSH *Pros and Cons/Gaps:* * Strengths: - This kind of method does not require complex engineering refactoring. Since it is agnostic to the design of the target, it works best for the case where the manager operates vast heteogenous devices from different vendors, versions and locations, hence telecommunications case. - This probing is one-time, thus it will not create unhandleable amount of probing packets. * The limitation of this method is that - Some masking mechanism will stop the probing (firewalls, load balancers, port-concealing protocols like Single Packet Authorization that enforce a default drop for unexpected packets), leaving a hidden security posture inside of the system. - Network management cannot know local application components that rests internally in the device and are not exposed over a socket. *Tools:* * Cisco Mercury project [MERCURY] provides an open source packet capture and analysis tool. It can read network packets, identify metadata of interest, and write out the metadata (including cryptographic-related) in JSON format. Liu Expires 7 January 2027 [Page 8] Internet-Draft CADI July 2026 4.2.2. Traffic Pattern Analysis Unlike simulated handshakes that actively query an endpoint, Traffic Pattern Analysis listens passively to live network traffic at strategic aggregation points. It infers cryptographic asset usage from protocol metadata, statistical characteristics, and behaviors without decrypting the underlying data payload. *Methods of Traffic Pattern Analysis includes:* * Listen to unencrypted negotiations like clientHello/serverHello, Server Name Indication (SNI), response of an unencrypted server digital certificate request, etc. * Listen to handshake fingerprints and compare them to existing patterns, as protocol implementations and behaviors are often rigid. * Listen to packet length and arrival time, do statistical pattern recognition. *Pros and Cons/Gaps:* * Strengths: - Similar to Simulated Handshakes, this kind of method is not intrusive and is agnostic to the design of the target. * The limitation of this method is that - Negotiation information like clientHello [RFC9849] and SNI are tending to be encrypted. - Protocols tend to have constant size packets [RFC9347]. - Alternative routing: network requests/responses could exit through a different routing path. 4.2.3. Process Identification Process Identification requires Endpoint Detection and Response (EDR) installed to have cryptographic visibility inside of a system. *Methods of Process Identification includes:* Liu Expires 7 January 2027 [Page 9] Internet-Draft CADI July 2026 * Kernel-Level System Call Auditing by deploying eBPF programs into the kernal space. These filters can capture kernel events to determine exactly which process (down to PID) have initiated an encrypted network communication. * Shared Library and Binary Hooking, by monitoring process load table to see if cryptographic dynamic libraries are loaded into the memory space. * Live Memory Scanning, by periodically scanning volatile memory for indication of creation of keys or signatures (as high-entropy memory segments), and then compare them with known patterns. *Pros and Cons/Gaps:* * Strengths: - Have deeper visibility for cryptographic assets within devices. * The limitation of this method is that - Requires loading new software (at least EDR/RDR) to legacy devices. - Potential blind spots due to lower pattern coverage. 4.2.4. Configuration Extraction The Configuration Extraction is a bit similar to the source code scanning. This section focuses more on the runtime configurations. In different use cases, the configuration extraction methods differs significantly. This section is to be extended. *Methods of Configuration Extraction includes:* * In network device management, NETCONF and YANG provide a standardized, model-driven management interface that enables programmable configuration and state validation. The network managing platform can define a YANG model and extract configurations from a device. * In cloud-native development, general .yaml configuration files, .env environment variables files, Kubernetes secret manifest, etc, can be extracted by administrative scripts or through management interfaces (e.g., AWS CloudControl, Kubernetes API). Liu Expires 7 January 2027 [Page 10] Internet-Draft CADI July 2026 5. Inventory TBD: After discovery, the result should best be presented in a unified network management platform for a comprehensive view. The Network Inventory (IVY) working group is working on this topic and cryptographic properties could become extensions to IVY records. The details of this section could invite more network management experts for input. 6. Potentially Related Working Groups * IVY -- extend network management views with cryptographic attributes. * SCITT -- extend SBOMs to adapt CBOMs. * PQUIP -- as a migration guideline. 7. Tools Compilation Due to limited time, compiling existing CADI tools remain open and will be done in next version. 8. Security Considerations This document has no further security considerations. 9. IANA Considerations This document has no IANA actions. 10. References 10.1. Normative References [RFC9849] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849, March 2026, . [RFC9347] Hopps, C., "Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)", RFC 9347, DOI 10.17487/RFC9347, January 2023, . 10.2. Informative References Liu Expires 7 January 2027 [Page 11] Internet-Draft CADI July 2026 [G7] "Advancing a Coordinated Roadmap for the Transition to Post-Quantum Cryptography in the Financial Sector", January 2026, . [CISAACDI] "Strategy for Migrating to Automated Post-Quantum Cryptography Discovery and Inventory Tools", August 2024, . [NCCOEFAQ] "Frequently Asked Questions about Post-Quantum Cryptography", June 2026, . [OMBM2302] "MEMORANDUM FOR THE HEADS OF EXECUTIVE DEPARTMENTS AND AGENCIES, Migrating to Post-Quantum Cryptography", November 2022, . [NIST-SP-1800-38B] "Migration to Post-Quantum Cryptography Quantum Readiness- Cryptographic Discovery", December 2023, . [MERCURY] "Mercury - network metadata capture and analysis.", n.d., . [IBMCBOM] "CBOM", n.d., . [CDXGEN] "CycloneDX Generator", n.d., . Author's Address Chunchi Peter Liu Huawei China Email: liuchunchi@huawei.com Liu Expires 7 January 2027 [Page 12]