Network-Infrastructure Hiding Protocol

4.1. OSI Layer Positioning

+-------------------+
| Application (L7)  |  HTTP, SMTP, SSH, etc.
+-------------------+
        ↓
+-------------------+
| Presentation (L6) |  TLS/SSL - Data encryption & integrity
+-------------------+
        ↓
+-------------------+
| Session (L5)      |  NHP - Authentication before connection
+-------------------+
        ↓
+-------------------+
| Transport (L4)    |  TCP, UDP, QUIC
+-------------------+
        ↓
+-------------------+
| Network (L3)      |  IP
+-------------------+

4.2. Key Differences

4.3. The Pre-Authentication Problem

TLS provides excellent protection for data in transit, but it has a fundamental limitation: the service must be reachable to initiate the TLS handshake. This creates a pre-authentication attack window:¶

Traditional TLS Flow:

Attacker    ──────►  Open Port 443  ──────►  TLS Handshake  ──────►  Authentication
                         ↑
                    Service is VISIBLE
                    Port scan succeeds
                    Pre-auth exploits possible

NHP + TLS Flow:

Attacker    ──────►  No Open Ports  ──────►  BLOCKED (Service Invisible)
                         ↑
                    Cannot discover service
                    Port scan fails

Authorized  ──────►  NHP Knock  ──────►  Port Opens  ──────►  TLS  ──────►  Application
User                     ↑                    ↑
                    Authenticated         Encrypted
                    BEFORE connect        data transfer

4.4. Complementary Security Model

NHP and TLS are designed to work together, not replace each other:¶

1. NHP provides: Authentication-before-connect, infrastructure invisibility, access control¶

2. TLS provides: Data encryption, integrity verification, server authentication¶

A complete Zero Trust deployment SHOULD use both:¶

• NHP ensures only authorized users can discover and reach the service¶

• TLS encrypts all data exchanged after access is granted¶

4.5. Vulnerabilities Addressed by NHP but Not TLS

4.6. Why Both Are Needed

NHP alone does not encrypt application data—it only controls access. TLS alone does not hide services—it only encrypts traffic. Together, they provide defense in depth:¶

• Without NHP: Attackers can scan, probe, and exploit services before any authentication occurs¶

• Without TLS: Authorized traffic would be transmitted in plaintext after NHP grants access¶

• With Both: Services are invisible to attackers, and all authorized traffic is encrypted¶

This layered approach aligns with Zero Trust principles: never trust, always verify, and minimize attack surface at every layer.¶

5.1. Reconnaissance and Scanning

Automated scanning tools and AI-driven reconnaissance continuously probe Internet-facing services. NHP eliminates the ability to discover protected resources by requiring cryptographic authentication before any network visibility is granted.¶

5.2. Pre-Authentication Exploits

Many vulnerabilities can be exploited before authentication occurs. By enforcing authentication-before-connect, NHP prevents attackers from reaching vulnerable services.¶

5.3. DDoS Attacks

NHP reduces DDoS attack surface by hiding service endpoints. Attackers cannot target what they cannot discover.¶

5.4. Credential Theft and Replay

NHP uses ephemeral keys and timestamp-based nonces to prevent credential replay attacks. Each session requires fresh cryptographic material.¶

5.5. Man-in-the-Middle Attacks

Mutual authentication using asymmetric cryptography ensures both parties verify each other's identity before establishing communication.¶

6.1. Core Components

6.2. Component Interactions

The following diagram illustrates the relationship between NHP components:¶

+-------------+          +-------------+          +-------------+
|             |  NHP-KNK |             |  Auth    |             |
| NHP-Agent   |--------->| NHP-Server  |<-------->|    ASP      |
|             |<---------|             |  Query   |   (IAM)     |
+-------------+  NHP-ACK +-------------+          +-------------+
      |                        |
      |                        | NHP-AOP
      |                        v
      |                  +-------------+
      |    NHP-ACC       |             |
      +----------------->|   NHP-AC    |
      |                  |             |
      v                  +-------------+
+-------------+                |
|  Protected  |<---------------+
|  Resource   |   Data Plane
+-------------+

6.3. Deployment Models

NHP components can be deployed in different configurations:¶

7.1. Control Plane vs Data Plane

The Control Plane carries cryptographic authentication and authorization information among NHP-Agent, NHP-Server, NHP-AC, and optional external ASP. Control plane messages are encrypted using Noise Protocol handshakes.¶

The Data Plane carries application data between the resource requester (NHP-Agent host) and the protected resource, but only after NHP-AC explicitly authorizes access.¶

This strict separation enforces the authenticate-before-connect principle central to Zero Trust.¶

7.2. Workflow Steps

The complete NHP workflow consists of the following steps:¶

1. Knock Request: NHP-Agent sends NHP-KNK message to NHP-Server containing encrypted identity claims and access request.¶

2. Authorization Query: NHP-Server validates the cryptographic envelope and queries ASP for authorization decision.¶

3. Authorization Response: ASP returns authorization decision with granted permissions and session parameters.¶

4. Door Opening: NHP-Server sends NHP-AOP command to NHP-AC instructing it to open access for the specific NHP-Agent.¶

5. AC Confirmation: NHP-AC enforces the access rule and replies with NHP-ART confirming the operation.¶

6. Agent Notification: NHP-Server sends NHP-ACK to NHP-Agent with access token and connection parameters.¶

7. Resource Access: NHP-Agent sends NHP-ACC to NHP-AC and establishes data plane connection to protected resource.¶

8. Session Maintenance: NHP-Server and NHP-AC maintain session state through NHP-KPL keepalive messages.¶

9. Logging and Audit: NHP-AC uploads access logs via NHP-LOG messages for compliance and auditing.¶

7.3. Sequence Diagram

NHP-Agent           NHP-Server            NHP-AC             ASP/IAM
    |                    |                    |                   |
    |--- NHP-KNK ------->|                    |                   |
    |                    |--- Auth Query -----|------------------>|
    |                    |<-- Auth Result ----|-------------------|
    |                    |                    |                   |
    |                    |--- NHP-AOP ------->|                   |
    |                    |<-- NHP-ART --------|                   |
    |                    |                    |                   |
    |<-- NHP-ACK --------|                    |                   |
    |                    |                    |                   |
    |--- NHP-ACC --------|------------------>|                   |
    |<================== Data Session ======>|                   |
    |                    |                    |                   |
    |                    |<-- NHP-LOG --------|                   |
    |                    |--- NHP-LAK ------->|                   |
    |                    |                    |                   |

8.1. Cryptographic Primitives

Implementations MUST support the following cryptographic primitives:¶

Implementations MAY additionally support:¶

8.2. Noise Protocol Handshake Patterns

NHP supports the following Noise handshake patterns:¶

XX:
  -> e
  <- e, ee, s, es
  -> s, se

IK:
  <- s
  ...
  -> e, es, s, ss
  <- e, ee, se

K:
  <- s
  ...
  -> e, es, ss

8.3. Key Management

9.1. Message Header

The NHP message header is 32 bytes with the following structure:¶

 0                   1                   2                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Version    |     Type      |     Flags     |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                          Nonce (96 bits)                      +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                       Timestamp (64 bits)                     +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Payload Length         |        Header Checksum        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.2. Message Types

9.3. Message Definitions

10.1. Log Types

NHP defines the following log categories:¶

Access Logs

Record all access attempts, including source identity, timestamp, requested resource, and decision outcome.¶

Authentication Logs

Record authentication events including key exchanges, identity verification, and authentication failures.¶

Policy Logs

Record policy evaluation decisions and the factors considered.¶

System Logs

Record component health, configuration changes, and operational events.¶

10.2. Log Format

All NHP logs SHOULD use structured JSON format with the following mandatory fields:¶

{
  "timestamp": "2025-01-01T12:00:00.000Z",
  "log_type": "access",
  "component": "nhp-ac-01",
  "session_id": "abc123...",
  "user_id": "user@example.com",
  "device_id": "device-uuid",
  "source_ip": "192.0.2.1",
  "resource_id": "resource-001",
  "action": "access_granted",
  "details": {}
}

10.3. Log Transmission

NHP-AC components transmit logs to NHP-Server using NHP-LOG messages. Implementations MUST:¶

• Encrypt all log transmissions using the established Noise session¶

• Batch logs to reduce network overhead¶

• Implement retry logic for failed transmissions¶

• Store logs locally if transmission fails¶

10.4. Compliance Considerations

NHP logging supports compliance with:¶

• SOC 2 Type II audit requirements¶

• GDPR access logging requirements¶

• HIPAA audit trail requirements¶

• PCI-DSS logging requirements¶

11.1. Integration Architecture

In an SDP integration, NHP components map to SDP components as follows:¶

11.2. Integration Process

1. Discovery: SDP Controller advertises NHP-Server endpoint to SDP Initiating Hosts.¶

2. Authentication: SDP Initiating Host uses NHP-KNK to authenticate with NHP-Server instead of SPA.¶

3. Authorization: NHP-Server queries SDP Controller for policy decisions.¶

4. Enforcement: NHP-AC opens ports on SDP Gateway based on NHP-AOP commands.¶

11.3. Benefits of NHP-SDP Integration

• Stronger Cryptography: NHP's Noise-based key exchange provides better forward secrecy than traditional SPA.¶

• Mutual Authentication: Both client and server authenticate each other.¶

• Scalability: NHP's architecture supports enterprise-scale deployments.¶

• Extensibility: NHP message types support richer interaction patterns.¶

12.1. DNS Integration Architecture

+-------------+     +-------------+     +-------------+
| NHP-Agent   |---->| NHP-Server  |---->| DNS Server  |
|             |     |             |     | (Internal)  |
+-------------+     +-------------+     +-------------+
      |                   |
      v                   v
+-------------+     +-------------+
| Public DNS  |     | NHP-AC      |
| (No Records)|     |             |
+-------------+     +-------------+

12.2. Integration Process

1. Protected resources have no public DNS records.¶

2. NHP-Agent authenticates with NHP-Server via NHP-KNK.¶

3. NHP-Server returns resource IP addresses in NHP-ACK only after successful authentication.¶

4. NHP-Agent can then connect to the resolved addresses.¶

This prevents DNS enumeration attacks and keeps resource addresses invisible to unauthorized users.¶

13.1. FIDO Integration Flow

1. User initiates NHP-KNK with FIDO assertion¶

2. NHP-Server validates FIDO assertion with FIDO server¶

3. Upon successful FIDO authentication, NHP-Server proceeds with access grant¶

13.2. Recovery and Fallback

For FIDO authentication failures, NHP supports fallback to:¶

• One-Time Password (OTP) via NHP-OTP message¶

• SMS/Email verification codes¶

• Recovery codes¶

14.1. Infrastructure Invisibility

NHP ensures infrastructure invisibility by:¶

• Encrypting all control plane traffic using Noise Protocol¶

• Requiring mutual authentication before any resource visibility¶

• Maintaining default-deny firewall rules on all NHP-AC components¶

• Supporting ephemeral port allocation for data plane connections¶

14.2. Replay Attack Prevention

NHP prevents replay attacks through:¶

• Timestamp validation with configurable tolerance (RECOMMENDED: 60 seconds)¶

• Unique nonce per message¶

• Session-bound tokens that cannot be reused across sessions¶

14.3. Key Security

Implementations MUST:¶

• Use cryptographically secure random number generators for all key generation¶

• Store private keys in secure enclaves or HSMs where available¶

• Implement key rotation policies¶

• Securely erase key material when no longer needed¶

14.4. Session Security

• Sessions MUST have configurable expiration (RECOMMENDED default: 4 hours)¶

• Sessions MUST be revocable by NHP-Server¶

• Session tokens MUST be bound to client identity and IP address¶

14.5. Denial of Service Mitigation

NHP provides DoS resistance through:¶

• Cryptographic puzzles for computationally expensive operations¶

• Rate limiting on NHP-Server and NHP-AC¶

• Cookie-based session resumption to avoid repeated handshakes¶

14.6. Limitations

NHP does not protect against:¶

• Compromised endpoints with valid credentials¶

• Insider threats with legitimate access¶

• Attacks on the data plane after access is granted¶

• Social engineering attacks targeting user credentials¶

16.1. Implementation Characteristics

The OpenNHP reference implementation is designed with the following characteristics:¶

16.2. Practical Use Case: StealthDNS

StealthDNS is a Zero Trust DNS client powered by OpenNHP that demonstrates practical application of the NHP protocol for DNS-level infrastructure hiding. It is available at:¶

https://github.com/OpenNHP/StealthDNS¶

StealthDNS implements the NHP-DNS integration described in this specification, providing:¶

• Invisible DNS Resolution: Protected domains have no public DNS records. Only authenticated clients can resolve hidden service addresses.¶

• NHP-Powered Authentication: Uses the OpenNHP library to perform cryptographic NHP knocking before DNS resolution.¶

• Transparent Local Resolver: Runs as a local DNS resolver (127.0.0.1:53), requiring no application changes.¶

• Cross-Platform Support: Available on Windows, macOS, Linux, Android, and iOS.¶

The StealthDNS workflow demonstrates the authenticate-before-connect principle:¶

1. Application performs DNS lookup for a protected domain.¶

2. StealthDNS checks if the domain is NHP-protected.¶

3. If protected, StealthDNS performs NHP knock with identity and device context.¶

4. Upon successful authentication, the NHP Controller returns ephemeral address mappings.¶

5. StealthDNS returns valid DNS records only to authorized clients.¶

6. Unauthorized clients receive NXDOMAIN—the service remains invisible.¶

This enforces identity before visibility and authorization before connectivity, demonstrating real-world application of NHP principles.¶

17.1. Normative References

[NoiseFramework]

Perrin, T., "The Noise Protocol Framework", 2018, <https://noiseprotocol.org/noise.html>.

[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/rfc/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/rfc/rfc8174>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

[RFC9000]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/rfc/rfc9000>.

[RFC9180]

Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.

17.2. Informative References

[CSA.NHP.Whitepaper]

Cloud Security Alliance, "Stealth Mode SDP for Zero Trust Network Infrastructure: Introducing the Network-Infrastructure Hiding Protocol (NHP)", 2026.

[CSA.SDP.Spec2.0]

Cloud Security Alliance, "Software Defined Perimeter Specification v2.0", 2022.

[NIST.SP.800-207]

Rose, S., Borchert, O., Mitchell, S., and S. Connelly, "Zero Trust Architecture", NIST Special Publication 800-207, 2020.