Re: [kitten] Replacing Kerberos

[Nico Williams <[e-mail]>]

On Thu, Feb 23, 2023 at 09:56:09PM +0100, [e-mail] wrote:
>    I dont know if its worth mentioning but in 2013 I published a paper
>    concerning combining Kerberos with IPsec. Perhaps some ideas may still be
>    relevant
>     
>    http://www.ijoee.org/uploadfile/2013/1006/20131006120339992.pdf

I'll take a look.  Some related research / protocols you might be
interested in:

 - RFC 4430 Kerberized Internet Negotiation of Keys (KINK)
   RFC 3129 Requirements for Kerberized Internet Negotiation of Keys

   This is a KE protocol for IPsec, like IKE, but based on Kerberos.

 - RFC 5386 Better-Than-Nothing Security: An Unauthenticated Mode of IPsec
   RFC 5660 IPsec Channels: Connection Latching

   This is a scheme for using IPsec (with potentially anonymous
   end-points) w/ channel binding from application layer authentication
   schemes.  The only missing piece is a definition of the channel
   bindings for an "IPsec channel" (we never got to it mainly because we
   ran out of energy).

   An "IPsec channel" is a packet flow for a ULP connection (e.g., TCP
   connection, or UDP "connection", etc.) where a) the SPD is held
   unchanged for that flow during the flow's lifetime, b) the SAs
   protecting that flow retain the same end-points during the flow's
   lifetime.

   See the concluded BTNS WG: https://datatracker.ietf.org/wg/btns/about/

IPsec deals in IP addresses, so it has to have an authorization function
of "authenticated entity" to "claimed IP address(es) / address range".
In an environment with dynamic IP addressing that's a problem: you can't
guarantee that the other end of some packet flow remains the same for
the lifetime of that packet flow.

The approach that we (well, I) took regarding this problem was to expand
on Dan McDonald's "connection latching" functionality in Solaris (see
the IP_SEC_OPT socket option) to go beyond SPD latching and also latch
the identities of the two end-points.  "Latching" here means "ensure
they don't change [while the connection remains alive]".  Then add
channel binding (which we never got around to) from application layer
authentication systems.

IMO the connection latching approach is better than the KINK approach
because then one need not work hard on credential provisioning for IKE
(since anonymous credentials will do) and also there is no need to worry
about dynamic IP address allocations nor about how to authorize
authenticated entities to IP addresses.  Except this only really works
for transport mode IPsec.  If you wanted to do Kerberos authentication
to a security gateway... well, at Sun we had a fabulous VPN system
called "punchin" that Dan wrote that essentially ran the equivalent of a
tunnel over transport mode IPsec to the gateway so that you could
authenticate to the gateway using an "application" protocol (punchin)
that would cause the SG to plumb your tunnel's routing, and presto, you
were on-network.  Since Dan wrote punchin, naturally it used the
IP_SEC_OPT socket option that he also wrote.  We could have used
Kerberos via IAKERB, or by plumbing enough routing to reach the KDCs
before the rest of the routing came up.

Nico
--