Port 910 is the official home of KINK—Kerberized Internet Negotiation of Keys. If you've never heard of it, you're not alone. This is a protocol that solved real problems elegantly, then watched the world choose a different solution.
What KINK Does
KINK establishes IPsec security associations using Kerberos for authentication.1 Where IKE (Internet Key Exchange) requires multiple rounds of negotiation to set up a secure tunnel, KINK can do it in two messages. It's faster, computationally cheaper, and integrates with the Kerberos infrastructure that many enterprises already run.
The protocol is stateless—each command or response stands alone, unlike IKE's stateful handshake. This makes it simpler to implement and less vulnerable to certain denial-of-service attacks.
The Problem It Solved
In environments with centralized authentication systems (corporate networks, universities, research institutions), IKE felt like overkill. You already had Kerberos managing who could access what. Why build a separate key exchange protocol when you could leverage the authentication system you already trusted?
KINK's answer: don't. Use Kerberos to authenticate peers and establish keys. Keep policy management centralized. Reduce latency. Lower computational cost.2
The History
KINK emerged from CableLabs' PacketCable effort in the early 2000s, which had defined a simplified version of Kerberized IPsec. Contributors including Sasha Medvinsky, Mike Froh, Matt Hur, and David McGrew refined the concept. Tero Kivinen's work on grafting Kerberos authentication onto IKE's Quick Mode provided inspiration for the protocol's design.3
RFC 4430 was published in March 2006, defining the complete protocol. The Racoon2 project implemented support for KINK alongside IKEv1 and IKEv2, proving the protocol could work in production environments.4
What Happened
Almost nothing. KINK saw limited deployment, primarily in research networks and specific enterprise environments that already had strong Kerberos infrastructure. The rest of the Internet kept using IKE.
This wasn't because KINK was technically inferior. By many measures—latency, computational cost, implementation complexity—it was better. But IKE had momentum, vendor support, and the weight of existing deployments. KINK required Kerberos infrastructure that many networks didn't have. And for networks that did have Kerberos, the pain of IKE wasn't quite severe enough to justify switching.
Security Considerations
KINK's security is only as strong as the underlying Kerberos infrastructure. If your Kerberos realm is compromised, so are your IPsec associations. This dependency on a separate authentication system was both KINK's strength (leverage existing trust infrastructure) and its limitation (single point of failure).
The protocol provides mutual authentication, replay protection, and perfect forward secrecy. It avoids many of IKE's denial-of-service vulnerabilities because of its stateless design.
Checking What's Listening
To see if anything is listening on port 910:
You're unlikely to find anything. KINK deployments are rare enough that encountering one in the wild would be genuinely surprising.
Related Ports
- Port 88 — Kerberos authentication, the foundation KINK builds on
- Port 500 — IKE/IKEv2, the protocol that won the key exchange battle
- Port 4500 — IPsec NAT-Traversal, IKE's solution for NAT environments
Why This Port Matters
Port 910 represents something important beyond the protocol itself: not every good idea wins. KINK was technically sound, offered real advantages, and had working implementations. But network protocols don't succeed on technical merit alone. They need timing, momentum, vendor support, and a pain point severe enough to overcome switching costs.
KINK didn't fail because it was wrong. It failed because IKE was good enough, and good enough with momentum beats better without it.
The port sits mostly empty now, a monument to elegant engineering that came too late or too early, depending on how you look at it.
Frequently Asked Questions
War diese Seite hilfreich?