GuardNet Authorization Protocol (GNA): Pre-Execution Authorization for High-Risk Digital Actions
draft-madaras-guardsuite-gna-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | tom madaras , Pat Estis | ||
| Last updated | 2025-12-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-madaras-guardsuite-gna-00
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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]