[5407] in Kerberos
Kerberized, dynamic swIPe?
daemon@ATHENA.MIT.EDU (Gord Matzigkeit)
Tue Jun 20 18:03:26 1995
To: kerberos@MIT.EDU
Date: 20 Jun 1995 13:55:01 -0600
From: gord@enci.ucalgary.ca (Gord Matzigkeit)
This must be a FII (frequently invented idea) by now, but I'll ask it
anyway...
First, sorry for the broad newsgroups line... followup to
comp.security.unix, please. Also, sorry for my relative ignorance of
IP and Kerberos... I would appreciate replies that inspire some good
discussion as opposed to flameage for not having my facts straight.
Thanks!
Second, does anybody know the status of swIPe? The last thing I saw
was an implementation by Matt Blaze for SunOS 4.1.3 from June of last
year. I read the Internet Draft on it, but it expired 6 months ago.
Last, are there any other, more elegant solutions to this problem that
deserve implementation (or have already been implemented)?
So, on with my proposal:
********************
The Problem
********************
swIPe solves the old problem of host authentication, data integrity,
and data encryption by wrapping packets from another network protocol
(in this implementation, IP). Then, the destination host can verify
the packet's integrity, since it shares a secret key with the source
host.
The problems that I see with swIPe (why I would probably not use the
current implementation) are as follows:
Routes are static. A swIPe route has to be set up as such in the
kernel routing table. This would, in my opinion, make it very
difficult for a smooth transition to swipe-based network protocols.
No key management is taken into account. This was listed as "outside
the scope" of the swipe protocol, in the internet draft.
It is "yet-another-protocol" that isn't (in the implementation that I
saw) tightly integrated with other authentication solutions.
********************
How to integrate Kerberos
********************
I personally am very attracted to Kerberos, since at least one of its
implementations is freely available, and it solves authentication
problems in a general way (via a trusted third party protocol).
The only problem I have with it, is that it is traditionally only
implemented at the application level of the ISO model.
My proposal is to treat the kernel implementation of secure network
protocols as "yet-another-kerberos-application."
So, the basic packet encryption/integrity/authentication would be
handled as the swipe draft proposed. The session key(s) would be
negotiated via kerberos across a non-authenticating network protocol,
such as traditional IP.
This process would move host-to-host authentication to the network
level of the ISO model.
********************
An example implementation
********************
(I'm speaking as a wannabe GNU Hurd-hacker... keep in mind that the
functions provided by the "kswipe" (short for "kerberized swipe") and
"swipe" daemons I describe could be implemented inside a traditional
*nix kernel.)
Again, please forgive my lack of knowledge of the nuances of IP and
Kerberos. I would appreciate it if you'd point any errors or
omissions out in comp.security.unix to help generate some valuable
discussion.
Assume the following:
Trent is a trusted third party, ie. the kerberos server
Angel is a kswipe host (a kerberos client of Trent). IP: 123.0.0.1
Bingo is another kswipe host. IP: 123.0.0.2
Alice is a client process running on Angel
Bob is a server process running on Bingo, registered on port 321
The "time to live" is some arbitrary time, say a day, that is used to
help keep the swiping "fresh".
In this example, Alice wants to start a session with Bob:
1) Alice tries to send a packet to Bingo, port 321
2) Angel intercepts the request, and gives it to her kswipe daemon (if
there is one running on Angel).
3) kswipe sees that Bingo is indeed kswipe-able, so it asks Trent
for a ticket to Bingo's encrypting network protocol (probably a
principal like: "ip/123.0.0.2@SOME.KERB.REALM").
4) kswipe negotiates a session key with Bingo's kswipe process.
5) If either of the last three steps fails, Angel's kernel marks Bingo
a non-kswipe-able, and continues with the traditional network
protocol. This mark would only exist for the time-to-live, after
which the kswipe session would be attempted again, in case Bingo or
Trent is encountering temporary problems.
6) Otherwise, kswipe spawns a "swipe" daemon, giving it a
time-to-live, Bingo's address, and the session key itself.
7) kswipe tells Angel's kernel to mark Bingo as swipe-able, and to
filter network protocols through the new swipe daemon.
8) Angel sends Alice's request through the swipe daemon, which
encrypts and/or authenticates each packet, and sends it on via regular
IP to Bingo.
9) Whenever swiped packets with Bingo's source address are received by
Angel, they are first sent through the appropriate swipe daemon, which
decrypts and/or authenticates each packet.
10) When the time-to-live is up, the swipe daemon kills itself, and
Alice's kernel unmarks Bingo. If the session is continued, or
reinitiated, a new key will be negotiated.
******************
Problems I see with my example implementation
******************
Step 4 is oversimplified. In that step, Bingo's kswipe needs to be
listening for requests, and be able to initiate a swipe for any host,
just like Angel did in steps 6-9, given that host's credentials.
The Kerberos protocol should prevent unauthorized initiation of swipe
sessions. ie. if some attacker, Mallet, wants to start a swipe
session between Alice and Bob, with his own key, then he has to
present Alice's credentials to Bob's kswipe, and vice versa. This
should be very difficult. However, does anybody out there see other
possibilities for a denial-of-service or man-in-the-middle attack
(besides spoofing Trent, which is "outside the scope of this protocol"
:))?
Are there flaws with swIPe or Kerberos (v5) that I am not aware of?
I have no idea whether the protocol would be fast enough to be
practical. Maybe a new "swipe" process shouldn't be spawned, and all
swipe requests should be handled by kswipe.
Step 3 is also oversimplified. How would the kswipe process determine
the realm for a network protocol request? Is there some fast way of
determining whether or not a host is swipe-able without having to
bother a kerberos server?
To me, the above problem will be the crux of the protocol. It will
determine whether or not this new protocol will become popular.
******************
Conclusion
******************
I am looking for a good, final solution to the problem of host-to-host
authentication, and I think that swIPe offers most of that solution.
However, the current implementation of swIPe is too disruptive to
become popular.
If a new, fast, simple implementation was created that would be able
to dynamically negotiate swipe sessions, then I would use it.
This new protocol would also need to be non-disruptive, and upwardly
compatible with standard network protocols, so that it could be
introduced gradually. Also, by necessity, sessions must be negotiated
across standard network protocols.
On second thought, in a perfect world, all the Kerberos KDC hosts
would implement kswipe with each of their clients... then, "standard"
network protocols would only be needed to initiate a new session with
an untrusted host.
By implementing this protocol in terms of Kerberos, the kerberos API
would be available as "standard fare" on more platforms, which would
broaden the base of kerberized applications.
However, standard Kerberos would only be needed for "fine-grained"
authentication, or authentication to non-kswipe-able hosts, since
host-to-host authentication would be handled transparently.
This is as close to a perfect network protocol as I can
imagine... especially if it is fast enough.
Are there any comments? Have I overlooked something? Is it possible?
Has it already been implemented? Who wants to help? :) ...
--Gordon
--
Gordon Matzigkeit | Emacs is not "just an editor" --- it's a
gord@enci.ucalgary.ca | whole new lifestyle.
