Zero Trust: Single Packet Authorization | Passive authorization

Not everything in Software-Defined Perimeter (SDP) is new: Single Packet Authorization.

Even though we are looking at disruptive technology to replace the virtual private network and offer secure segmentation, one thing to keep in mind with zero trust and software-defined perimeter (SDP) is that it’s not based on entirely new protocols. So we have reversed the idea of how TCP connects. It started with an authentication first and then connect approach, but traditional networking and protocols still play a large part. For example, we still use encryption to ensure that only the receiver can read the data we send. We can, however, use encryption without authentication, which validates the sender. However, to stand any chance in today’s world, the two of them should go hand in hand. Attackers can circumvent many firewalls and secure infrastructure. As a result, message authenticity is a must for zero trust, and without an authentication process, a bad actor could change, for example, the ciphertext without the reviewer ever knowing.

zero trust security

Diagram: Zero trust security. Authenticate first and then connect.


A key aspect of zero trust networking and zero trust principles is to authenticate and authorize network traffic: i.e., the flows between the requesting resource and the intended service. Simply securing communications between two endpoints is not enough. Security pros must ensure that each individual flow is authorized. This can be done by implementing a combination of security technologies such as Single Packet Authorization (SPA), Mutual Transport Layer Security (MTLS), Internet Key Exchange (IKE), and IP security (IPsec).
IPsec can use a unique security association (SA) per application in which only authorized flows are allowed to construct security policies. While IPsec is considered to operate at Layer 3 or 4 in the open systems interconnection (OSI) model, application-level authorization can be carried out with X.509 or an access token.

There is also an enhanced version of TLS known as mutually authenticated TLS (MTLS) used to validate both ends of the connection. The most common TLS configuration is the validation which ensures that the client is connected to a trusted entity. But the authentication doesn’t happen the other way round so that the remote entity communicates with a trusted client. This is the job of mutual TLS. As I said, mutual TLS goes one step further and authenticates the client.



  • The pre-authentication stage

You can’t attack what you cannot see. The mode that allows pre-authentication is Single Packet Authorization. UDP is the preferred base for pre-authentication because UDP packets, by default, do not receive a response. However, TCP and even ICMP can be used with the SPA. Single Packet Authorization is a next-generation passive authentication technology, beyond what we previously had with port knocking, which uses closed ports to carry out the identification of trusted users. SPA is a step up from port knocking.

The typical port knocking scenario is for a port knocking server to configure a packet filter to block all access to a service, for example, the SSH service, until a specific port knock sequence is sent by a port knocking client. For example, the server could require the client to send TCP SYN packets to the following ports in order: 23400 1001 2003 65501.

If the server monitors this knock sequence, the packet filter reconfigures to allow a connection from the originating IP address. However, port knocking has its limitations which SPA addresses; SPA retains all of the benefits of port knocking but fixes the limitations.


  • What is Single Packet Authorization (SPA)

SPA was invented well over 10 years ago and was commonly used for superuser SSH access to servers where it mitigates attacks by unauthorized users. The SPA process happens before the TLS connection, mitigating attacks targeted at the TLS ports. As already mentioned, SDP didn’t invent new protocols; it was more of binding existing protocols. SPA used in the world of SDP was based on RFC 4226 HMAC-based One-Time Password “HOTP.” It is another layer of security and is not a replacement for the security technologies mentioned at the start of the post.

The first step in an attack is reconnaissance, whereby an attacker is on the prowl to locate a target. This stage is easy to do and can be automated with tools such as NMAP. However, SPA ( and port knocking ) employs a default-drop stance that provides service only to those IP addresses that can prove their identity via a passive mechanism. No TCP/IP stack access is required to authenticate remote IP addresses. Therefore, NMAP cannot tell that a server is running when protected with SPA, and whether the attacker has a zero-day exploit is irrelevant.


zero trust security model

Diagram: Zero trust security model.


The idea around SPA is that a single packet is sent: based on that packet, an authentication process is carried out. A key point to note is that nothing is listening on the service, so you have no open ports. For the SPA service to operate, there is not anything specifically listening. When the client sends a SPA packet, the packet will be rejected, but a second service identifies the SPA packet in the IP stack and then authenticates it. If the SPA packet is successfully authenticated, the server will open a port in the server’s firewall, which could be based on Linux iptables, so the client can establish a secure and encrypted connection with the intended service.


A simple SPA process flow

The SDP gateway protects assets, and this component could be containerized and listened for SPA packets. In the case of an open-source version of SDP, this could be fwknop, which is a popular open-source SPA implementation. When a client wants to connect to a web server, it sends a SPA packet. When the requested service receives the SPA packet, it will open the door once the credentials are verified. However, the service still does not respond to the request.

When the fwknop services receive a valid SPA packet, the contents of the packet will be decrypted for further inspection. The inspection will reveal the protocol and port numbers that the sender is requesting access to. Next, the SDP gateway adds a rule to the firewall to establish a mutual TLS connection to the intended service. Once this mutual TLS connection is established, the SDP gateway removes the firewall rules, and the service is invisible to the outside world.

single packet authorization

Diagram: Single Packet Authorization: The process flow.


Fwknop uses this information to open up firewall rules, allowing the sender to communicate with that service on those ports. The firewall will only be opened for some time and can be configurable by the administrator. Any attempts to connect to the service must know the SPA packet, and even if the packet can be recreated, the packet’s sequence number needs to be established prior to the connection. This is next to impossible, considering the sequence numbers are randomly generated.

Once the firewall rules are removed, let’s say after 1 minute, the initial MTLS session will not be affected as it is already established. However, any other sessions requesting access to the service on those ports will be blocked. This permits only the sender of the IP address to be tightly coupled with the requested destination ports. It’s also possible for the sender to include a source port, enhancing security even further.


    • What can SPA offer

Let’s face it; robust security is hard to achieve. We all know that you can never be 100% secure. Just have a look at OpenSSH. Some of the most security-conscious developers developed OpenSSH, yet it occasionally contains exploitable vulnerabilities.

Even when you look at some of the attacks on TLS, we have already discussed the DigiNotar forgery in a previous post on zero trust networking. Still, one that caused a major issue was the THC-SSL-DOS attack, where a single host could take down a server by taking advantage of the asymmetry performance required by the TLS protocol. Single Packet Authorization (SPA) overcomes many existing attacks and, combined with the enhancements of MTLS with pinned certificates, creates a robust security model. SPA defeats many a DDoS attack as only a limited amount of server performance is required for it to operate.


SPA provides the following security benefits to the SPA-protected asset:

    • SPA blackens the gateway and protected assets that sit behind the gateway. The gateway does not respond to any connection attempts until they have provided an authentic SPA. Essentially, all network resources are dark until security controls are passed.
    • SPA also mitigates DDoS attacks on TLS. More than likely, TLS is publicly reachable on the internet running the HTTPS protocol that is highly susceptible to DDoS. SPA mitigates these types of attacks because it allows the SDP gateway to discard the TLS DoS attempt before entering the TLS handshake. As a result, there will be no exhaustion from targeting the TLS port.
    • SPA assists with attack detection. The first packet to an SDP gateway must be a SPA packet. If a gateway receives any other type of packet, it should be viewed and treated as an attack. Therefore, the SPA enables the SDP to identify an attack based on a single malicious packet.