Protocol's Features

[the-moisrex]

Some features that comes to my mind:

• [ ] Not being vulnerable to trivial replay attacks
  • [ ] Random looking sequence of port numbers
• [ ] Not being vulnerable to Man In The Middle Attacks
• [ ] #3
• [ ] Username Based Authentication (optional = root as default?)
• [ ] No identifiable feedback to the client when the wrong sequence is knocked
• [ ] No problem with packets being received out-of-order
• [ ] Port Aliasing (using NAT?)
  • [ ] Temporarily choosing a port for the authenticated client
  • [ ] Different temp ports for different authenticated clients
  • [ ] Same port for different authenticated clients connects to different ports locally
• [ ] MAC Address authentication (optional)
• [ ] Tunneling ???
• [ ] Public-private key authentication or password-based(hashes) or both?

What do you think? Let's talk about each and every one of them and even more and let's see which ones are good to be included in the protocol and which ones don't need to.

[wmerfalen]

So I will start with the things that I'm not interested in incorporating.

No problem with packets being received out-of-order

The way I have the code setup, ports have to be knocked in a specific sequence. I don't plan on changing that, though I also don't care if a fork of the code implements that.

No identifiable feedback to the client when the wrong sequence is knocked

This is the current behavior

MAC address authentication will be difficult because I'm almost positive most gateway interfaces will stamp their own MAC address onto outgoing traffic. This would have to be a LAN feature

... to be continued. It's late and I need sleep. Will add more comments in a day or so

[the-moisrex]

I'm okay with your current project, my intention is to design a protocol here and write the RFC, not to implement one; the implementation comes after when we have a good enough document to base it on.

Yes, MAC address authentication needs to be a local thing, but we also can let the client send (include it in the hash) its own MAC address. Even though the attacker would be able to choose any MAC address to send, but I think of this as a feature that would let the client and server config files to be able to specify a MAC address to restrict the port to.

We can separate the MAC address authentication in two parts:

• Live MAC Address validation: requires the client to be directly connected; this is almost useless (maybe useful for tunneling?)
• Offline MAC Address validation: previously specified mac, included in the hashed/encrypted port sequence

At least that's what I think so far!

I'm aware that we're living in different time-zones. It's okay.

[the-moisrex]

Regarding out-of-order sequences,

well that's a big problem to solve. I think it can be a math problem to solve. Instead of a ASCII-to-Port-number conversion, we might be able to find a way to add some sort of sequencing built into the ASCII-to-Port algorithm. Do you have any ideas for that?

If we use a DNS-Based port knocking (which I don't think it's a good idea) (explained here) this problem won't exist at all because we're just doing one knock.

But one-knock protocols shouldn't be called port-knocking at all, we could just write a simple service for that. That's not what we want.

[wmerfalen]

So the reason I don't have a payload that is encrypted (or a payload at all) is because the method of unlocking a port is the act of using the port numbers in the packet. If we added any data to the body of the packets, then we're just creating a different type of authentication system. I'm just using port numbers

[the-moisrex]

Yes that's what I would want too. The act of calling the ports, that's it. I don't like to send or get anything other than the ports. The sequence of the port numbers is the hash itself.

[wmerfalen]

I'm not interested in working on this if you're not going to help with the implementation. This was more your idea than mine

[the-moisrex]

I understand.

My idea was to create a Secure Port Knocking Protocol, and then we would implement it, not to continue working on knockd. Knockd seems great, but I don't want to bound ourselves to the design decisions made during knockd while we're writing the RFC.

[wmerfalen]

Well, if you want to create a secure port knocking daemon, the last thing you do is make it a kernel module.

[wmerfalen]

I won't write anything that is a kernel module

[the-moisrex]

I'm still deciding if it's a good idea to make it a kernel module or a daemon.

I'm still leaning toward a kernel module because then we can involve the firewall rules.

Imagine something like this in nftables:

table inet door {
   pknoker {
      str "username:password"
   }

   chain inbound {
      knock @pknocker;
      ip addr in @pknocker accept;
   }
}

[the-moisrex]

I won't write anything that is a kernel module

I understand.

Why do you think it's a better idea to write it as a daemon?

[wmerfalen]

Not interested in making it a kernel module. Not interested in keeping it ran as root. If you have ideas for how to remove the root capability, I'm all ears. All the suggestions so far have been pretty terrible