Network Working Group Y. Ni Internet-Draft C. P. Liu Intended status: Informational Huawei Expires: 7 January 2027 6 July 2026 DNS-based Entity-Level Discovery and End-to-End Connection for AI Agents draft-ni-agent-entity-discovery-00 Abstract This document defines a new DNS resource record type, Agent Entity Discovery (AED), to publish agent-specific trust anchors or direct match constraints for verifying an agent's certificate or token. This enables the cross-domain users or agents to authenticate, and establish secure, end-to-end connections directly with a private- domain agent entity. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://NiYuan224.github.io/draft-ni-agent-entity-discovery/draft-ni- agent-entity-discovery.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ni-agent- entity-discovery/. Source for this draft and an issue tracker can be found at https://github.com/NiYuan224/draft-ni-agent-entity-discovery. 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. Ni & Liu Expires 7 January 2027 [Page 1] Internet-Draft draft-ni-agent-entity-discovery July 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Domain Names for AED RR . . . . . . . . . . . . . . . . . . . 5 5. The AED RR . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. AED RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 5.1.1. The Usage Field . . . . . . . . . . . . . . . . . . . 6 5.1.2. The Selector Field . . . . . . . . . . . . . . . . . 6 5.1.3. The Matching Type Field . . . . . . . . . . . . . . . 7 5.1.4. The Credential Association Data Field . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6.1. DNSSEC Dependency . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction AI agents are evolving from isolated, single-domain components into collaborative entities interacting across domain boundaries. This shift requires agent-specific credential associations, such as private-domain trust anchors, to be securely exchanged or published for cross-domain authentication. For instance, SPIFFE Federation allows disparate domains to securely exchange their trust bundles via the bundle endpoint, enabling agents to cryptographically verify other agents' credentials. However, such a federation relies on out- of-band pre-configuration between participating organizations, and is therefore not suitable for dynamic, internet-scale discovery and authentication. Ni & Liu Expires 7 January 2027 [Page 2] Internet-Draft draft-ni-agent-entity-discovery July 2026 Conversely, existing internet-scale mechanisms such as DNSSEC [RFC4033] and DANE [RFC6698] only secure identities at the domain level. Consequently, a client cannot differentiate among multiple agents that are served from the same domain name, leading to risks of impersonation and lateral movement. To bridge this gap, this document introduces a mechanism that re- anchors trust at the agent entity level rather than at the domain name level. By extending DNS Resource Records (RRs) to publish agent-specific credential associations, a cross-domain client can retrieve these records during the discovery phase and establish an end-to-end connection directly to the target AI agent, rather than the domain name that hosts it. The credential association defined in this mechanism provides two functions, inheriting the definition of certificate associations of [RFC6698]: it functions either as a credential trust anchor used to cryptographically verify the signature of an agent's presented credential (either via certification path validation or JWT signature verification), or as a credential constraint used to perform a direct match against the agent's credential. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Workflow This section outlines the workflow for establishing a secure, end-to- end connection directly with a private-domain agent entity (see Figure 1). A private-domain administrator (e.g. a private-domain identity server) publishes agent-specific AED (Agent Entity Discovery) RRs to the DNS server. Then, a client can query and parse these records, and use the retrieved credential associations to verify the target agent during the connection. Ni & Liu Expires 7 January 2027 [Page 3] Internet-Draft draft-ni-agent-entity-discovery July 2026 +--------+ +----------+ +--------+ +--------+ | Client | |DNS Server| | Agent | | Admin | +--------+ +----------+ +--------+ +--------+ | | | | | |1. Register AED | | |<------------------------------| | | | | |2.Query AED | | | |-------------->| | | | | | | | Answer AED | | | |<--------------| | | | | | | |3.TLS handshake| | | |<------------------------------> | | (Validate X.509/RPK/PSK etc.)| | | | | | |4.Application credential validation (Optional) | |<------------------------------- | | | | | | | | | _Figure 1: Workflow of Agent Entity-Level Discovery and End-to-End Connection_ 1. Registration: The private-domain administrator constructs a dedicated QNAME (as defined in Section 4) for the internal agent and publishes its AED RRs (as defined in Section 5) to the DNS server. 2. Discovery: A client sends a DNS query for the agent's specific QNAME with the AED QTYPE, and extracts the agent's credential associations from the recevied AED RRs. The client also obtains the agent's network location (IP address and port) via A/AAAA or SRV RRs. Subsequent TLS handshake messages SHOULD be sent to this obtained address. 3. Connection: The client initiates a direct TLS connection to the agent. During the handshake, the client validates the credential presented by the agent against the credential associations. 4. Application credential validation (Optional): If additional application-layer authentication is required inside the secure tunnel, the agent presents an application-layer token, then the client utilizes the credential associations from the AED RR to verify the token signature. Ni & Liu Expires 7 January 2027 [Page 4] Internet-Draft draft-ni-agent-entity-discovery July 2026 4. Domain Names for AED RR The QNAME for an AED RR is constructed by prepending the agent identifier (agent_id) as the left-most label to the base domain name, as shown below: . _Figure 2: Domain Names for AED_ For example, to request AED RRs for an AI agent identified as "agent- 007" hosted at "www.example.com", the QNAME "agent- 007.www.example.com" is used. To maintain flexibility, the internal structure and generation mechanism of the "agent_id" label are left open to deployment- specific choices or future specifications. However, any abstract identifier used MUST be mapped to a valid DNS label. Examples of such identifiers MAY include: * a WIMSE workload identifier; * a W3C DID; * an encoded application-layer path component, etc. 5. The AED RR This section defines a new DNS RR type: AED, which is used to associate a set of trust anchors or credential constraints with a specific AI agent entity, thus enabling a client to authenticate that AI agent. 5.1. AED RDATA Wire Format The RDATA for an AED RR consists of a one-octet Usage field, a one- octet Selector field, a one-octet Matching Type field, and a variable-length Credential Association Data field. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Usage | Selector | Matching Type| / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / / Credential Association Data (variable) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ni & Liu Expires 7 January 2027 [Page 5] Internet-Draft draft-ni-agent-entity-discovery July 2026 _Figure 3: AED RDATA Wire Format_ 5.1.1. The Usage Field A one-octet value, called "usage", specifies how the association data is to be used for agent authentication. The usages defined in this document are: 0 -- Certificate Trust Anchor: Usage 0 is used to specify a certificate or public key that MUST serve as a domain-specific trust anchor for TLS certification path validation of the presented agent certificate during the TLS handshake. 1 -- JWT Trust Anchor: Usage 1 is used to specify a JSON Web Key (JWK) that MUST serve as a domain-specific trust anchor to verify the signature of an application-layer JSON Web Token (JWT) presented by the agent inside the tunnel. 2 -- Certificate Constraint: Usage 2 is used to specify a certificate or the public key that MUST directly match the certificate presented by the agent during the TLS handshake. 3 -- JWT Constraint: Usage 3 is used to specify a JWT that MUST directly match the JWT presented by the agent inside the tunnel. 4 -- RPK Constraint: Usage 4 is used to specify a raw public key (RPK) that MUST directly match the RPK presented by the agent during a TLS handshake [RFC7250] and be used to verify the agent's possession of the private key via the CertificateVerify signature. 5 -- PSK Constraint: Usage 5 is used to specify a pre-shared key (PSK) identity. The PSK MUST be pre-established out-of-band and stored securely by both the client and the agent so that the client can use the PSK identity to select the correct key during a TLS-PSK handshake [RFC8446]. The record MUST contain only the identity string, never the secret key material. 5.1.2. The Selector Field A one-octet value, called "selector", specifies which part of the trust anchor or credential is contained in the credential association data. The selectors defined in this document are: 0 -- Full credential: The full binary or textual structure of the credential or trust anchor. * For X.509 certificates (usages 0 and 2): The DER-encoded binary structure of the full X.509 Certificate [RFC5280]. Ni & Liu Expires 7 January 2027 [Page 6] Internet-Draft draft-ni-agent-entity-discovery July 2026 * For JWT trust anchors (usage 1): The UTF-8 encoded JSON string of the JWK [RFC7517]. * For JWT constraints (usage 3): The ASCII string representing the full JWT compact serialization [RFC7519]. * For PSK constraints (usage 5): The opaque string representing the PSK identity [RFC8446]. 1 -- SubjectPublicKeyInfo: DER-encoded binary structure of the public key. * For X.509 certificates (usages 0 and 2): The SubjectPublicKeyInfo field within the certificate, encoded in DER binary format [RFC5280]. * For RPK constraints (usage 4): The DER-encoded RPK structure [RFC7250]. 5.1.3. The Matching Type Field A one-octet value, called "matching type", specifies how the credential association is presented and matched. The types defined in this document are the same as Section 2.1.3 of [RFC6698]: 0 -- Exact match on selected content. 1 -- SHA-256 hash of selected content. 2 -- SHA-512 hash of selected content. The following constraints apply to this document: For JWT Trust Anchors (Usage 1): Matching type 1 or 2 is NOT RECOMMENDED unless the companion application protocol explicitly guarantees that the plain-text JWK is delivered alongside the token. Without the plain-text JWK, the client cannot obtain the public key material needed to verify the JWT signature. For PSK Constraints (Usage 5): The matching type MUST be set to 0. The client requires the raw, unhashed PSK identity to construct the TLS ClientHello message. 5.1.4. The Credential Association Data Field This variable-length field contains the credential association data to be matched, constructed according to the preceding fields: Ni & Liu Expires 7 January 2027 [Page 7] Internet-Draft draft-ni-agent-entity-discovery July 2026 * The Usage field exemplifies the use of the credential association data. * The Selector field determines whether the credential association data contains the full structure or the SubjectPublicKeyInfo of the credential. * The Matching Type field determines the data's representation: the raw data, or its cryptographic hash. 6. Security Considerations 6.1. DNSSEC Dependency All AED RRs MUST be authenticated via DNSSEC [RFC4033]. Clients MUST reject AED RRs that do not have a valid DNSSEC validation chain. 7. IANA Considerations This document has no IANA actions. 8. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005, . Ni & Liu Expires 7 January 2027 [Page 8] Internet-Draft draft-ni-agent-entity-discovery July 2026 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Acknowledgments TODO acknowledge. Authors' Addresses Yuan Ni Huawei Email: niyuan1@huawei.com Chunchi Peter Liu Huawei Email: liuchunchi@huawei.com Ni & Liu Expires 7 January 2027 [Page 9]