Network Working Group T. Madaras Internet-Draft GuardSuite, a VXMSecure Co. Intended status: Experimental P. Estis Expires: June 2, 2026 GuardSuite, a VXMSecure Co. December 2, 2025 GuardNet Authorization Protocol (GNA): Pre-Execution Authorization for High-Risk Digital Actions draft-madaras-guardsuite-gna-00 Abstract This document specifies the GuardNet Authorization Protocol (GNA), a pre-execution authorization framework for high-risk digital and physical actions. GNA defines an enforcement model in which sensitive operations (for example, payments, administrative changes, OT/ICS commands, and AI-initiated actions) are intercepted before execution, evaluated against policy and context, routed to one or more authenticated approvers, and executed only after a valid authorization token is issued. GNA provides non-repudiable authorization receipts and is designed to integrate with existing identity providers and logging systems without requiring architectural changes. The protocol provides stronger authorization guarantees using digital signatures and contextual decisioning and is intended as a complement to, not a replacement for, existing authentication and monitoring systems. 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 June 2, 2026. Copyright Notice Copyright (c) 2025 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. Madaras & Estis Expires June 2, 2026 [Page 1] Internet-Draft GuardNet GNA December 2025 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . 3 4. Architecture and Roles . . . . . . . . . . . . . . . . . 5 5. Protocol Overview . . . . . . . . . . . . . . . . . . . 7 6. Messages and Data Structures . . . . . . . . . . . . . 8 6.1. AUTH-REQ . . . . . . . . . . . . . . . . . . . . . 8 6.2. AUTH-CHALLENGE . . . . . . . . . . . . . . . . . . 9 6.3. AUTH-DECISION . . . . . . . . . . . . . . . . . . 9 6.4. AUTH-RESULT . . . . . . . . . . . . . . . . . . . 10 6.5. RECEIPT . . . . . . . . . . . . . . . . . . . . . 10 7. Policy and Materiality Evaluation . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . 13 10. Normative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 14 1. Introduction Modern digital systems authenticate who a user is but rarely verify whether a specific high-risk action should be allowed at the moment of execution. Once a user or service is authenticated, many systems assume that all subsequent actions taken during that session are legitimate. This creates a gap between authentication and actual authorization at the action level. The absence of a pre-execution authorization layer contributes to incidents such as privilege misuse, fraudulent financial transfers, misconfigurations of critical infrastructure, unsafe AI-driven actions, and other high-impact events. GNA introduces a standardized way to intercept and evaluate such actions before they execute, requiring explicit approval and producing a non-repudiable audit trail. GNA is designed to be transport-agnostic and applicable across multiple domains, including financial systems, cloud infrastructure, operational technology (OT), and AI systems. It does not replace identity providers or logging systems; instead, it provides a complementary enforcement plane focused on high-risk actions. 2. Requirements Language 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, RFC 2119 [RFC2119] and RFC 8174 [RFC8174] when, and only when, they appear in all capitals, as shown here. Madaras & Estis Expires June 2, 2026 [Page 2] Internet-Draft GuardNet GNA December 2025 3. Terminology The following terms are used throughout this document: RS (Requesting System) A system, application, service, or agent that initiates a high- risk action requiring pre-execution authorization. AS (Authorization Service) The GuardNet Core service responsible for evaluating policy and context and issuing authorization decisions and tokens. UA (User Agent) A secure device-based approver agent (for example, GuardID) used by human approvers to review and approve or deny an action. Action A high-risk operation that MUST be authorized before execution, such as a large payment, critical configuration change, OT/ICS control operation, or AI-initiated task. Challenge A request sent from the Authorization Service to one or more User Agents asking for an authorization decision on a specific Action. Decision An APPROVE or DENY response returned from a User Agent to the Authorization Service, typically accompanied by a digital signature and relevant metadata. Receipt A non-repudiable, tamper-evident record created by the Authorization Service that binds the Action, the applied policy, and the approver Decisions. Execution Token A token issued by the Authorization Service that proves an Action was authorized and MAY now be executed by the Requesting System. 4. Architecture and Roles GNA follows a model similar to Policy Enforcement Point (PEP) and Policy Decision Point (PDP) architectures common in access control systems, with components specialized for pre-execution action authorization: Policy Enforcement Point (PEP) The GuardNet Edge Hook that intercepts Actions in the Requesting System and forwards authorization requests to the Authorization Service. Madaras & Estis Expires June 2, 2026 [Page 3] Internet-Draft GuardNet GNA December 2025 Policy Decision Point (PDP) The GuardCore Authorization Engine that evaluates policies, risk, and context, issues Challenges to User Agents, and returns an Execution Token upon approval. Approver Trust Anchor The User Agent (for example, GuardID) which provides a trusted interface for human approvers and signs Decisions. A typical end-to-end flow is: 1. The Requesting System invokes the PEP when a high-risk Action is requested. 2. The PEP constructs an AUTH-REQ message and sends it to the PDP (Authorization Service). 3. The PDP evaluates policies and context and, if required, sends AUTH-CHALLENGE messages to one or more User Agents. 4. User Agents present the Action context to human approvers and return AUTH-DECISION messages (APPROVE or DENY). 5. The PDP aggregates Decisions, creates a Receipt, and issues an AUTH-RESULT containing an Execution Token if the Action is approved. 6. The PEP validates the Execution Token and either allows or blocks execution of the Action in the Requesting System. 5. Protocol Overview GNA defines a small set of logical messages: o AUTH-REQ: Sent by the PEP to the PDP to request authorization for a specific Action. o AUTH-CHALLENGE: Sent by the PDP to one or more UAs, requesting a Decision. o AUTH-DECISION: Sent by a UA to the PDP to convey an APPROVE or DENY decision. o AUTH-RESULT: Sent by the PDP to the PEP, containing an Execution Token and a result (approved or denied). o RECEIPT: Created by the PDP and persisted to a logging or ledger system for non-repudiation and audit. GNA does not mandate specific transport protocols. Implementers MAY choose HTTPS/REST, gRPC, message queues, or other secure transports Madaras & Estis Expires June 2, 2026 [Page 4] Internet-Draft GuardNet GNA December 2025 as appropriate, provided that confidentiality, integrity, and authenticity are preserved. 6. Messages and Data Structures This section describes the abstract fields associated with the various messages. Concrete encodings (for example, JSON, CBOR, protobuf) are left to profiles and future documents. 6.1. AUTH-REQ AUTH-REQ is constructed by the PEP and sent to the PDP when a high- risk Action is initiated. It SHOULD include: o action_id: Unique identifier for the Action. o action_type: Category or type of Action (for example, "payment", "config_change", "ot_command"). o requester_identity: Identity of the initiator (derived from an existing identity provider). o context: Metadata such as amount, target resource, environment, and location. o client_metadata: Optional device, application, or session attributes. 6.2. AUTH-CHALLENGE AUTH-CHALLENGE is sent from the PDP to one or more UAs when policy requires human or multi-party approval. It SHOULD include: o challenge_id: Unique identifier for this Challenge. o action_summary: Human-readable description of the Action. o policy_id: Identifier of the policy being applied. o context_snapshot: Relevant context at the time of the request. o nonce: Random value to prevent replay. 6.3. AUTH-DECISION AUTH-DECISION is sent from a UA to the PDP to convey an approval or denial. It SHOULD include: o challenge_id o decision: APPROVE or DENY. Madaras & Estis Expires June 2, 2026 [Page 5] Internet-Draft GuardNet GNA December 2025 o approver_identity o signature: Digital signature over the decision and key context. o timestamp 6.4. AUTH-RESULT AUTH-RESULT is sent from the PDP back to the PEP. It MUST indicate whether the Action is authorized and SHOULD carry an Execution Token if approved. It SHOULD include: o action_id o result: APPROVED or DENIED. o execution_token: Token the PEP can validate prior to executing the Action. o expiry: Time after which the token is no longer valid. 6.5. RECEIPT A Receipt is generated by the PDP after processing the Action and any required approvals. It is intended for logging and audit and is not normally transmitted inline to RS or UA. It SHOULD include: o receipt_id o action_hash: Hash of the Action parameters. o policy_hash: Hash of the policy used. o approver_identities o decision_summary o timestamp o signature: Digital signature over the Receipt. 7. Policy and Materiality Evaluation GNA assumes a configurable policy layer that governs which Actions require authorization and what form that authorization MUST take. Policies MAY define: o Thresholds (for example, amounts or scope of change). o Required approver roles or identities. o N-of-M approval schemes. Madaras & Estis Expires June 2, 2026 [Page 6] Internet-Draft GuardNet GNA December 2025 o Segregation-of-duties requirements. o Contextual conditions such as time of day, location, or device posture. The exact policy language and storage is out of scope for this document, but GNA is designed to work with existing PDP tools as well as custom policy engines. 8. Security Considerations GNA is designed to reduce risk arising from: o Compromised credentials used to execute high-value actions. o Malicious insiders acting alone with excessive privileges. o Deepfake and social-engineering attacks that coerce execution of harmful actions. o Automated or AI-driven systems operating without human oversight. Implementers MUST consider: o Protection of private keys for signing Decisions and Receipts. o Hardening of PEPs and PDP against bypass or tampering. o Availability strategies for the PDP (for example, fail-open versus fail-closed behavior for different classes of Actions). GNA does not prevent collusion between multiple approvers or compromise of both a Requesting System and its corresponding approver devices. Those risks MUST be addressed with broader organizational controls and endpoint security. 9. IANA Considerations This document makes no requests of IANA. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Madaras & Estis Expires June 2, 2026 [Page 7] Internet-Draft GuardNet GNA December 2025 Authors' Addresses Tom Madaras GuardSuite, a VXMSecure Company Hollywood, FL 33021 USA Email: tom@vxmsecure.com Pat Estis GuardSuite, a VXMSecure Company Houston, TX USA Email: pat.estis@gmail.com Madaras & Estis Expires June 2, 2026 [Page 8]