Re: Intent to package kth kerberos (krb4 or heimdal, not sure which)
Jean Pierre LeJacq <jplejacq@quoininc.com> wrote:
> I'm not particular familiar with IPsec but SKIP provides
> authentication. True you could use Kerberos but it would be
> redundant. Not to say that Kerberos wouldn't be nice to have in
> Debian but, as you mentioned earlier, it would require patching all
> network applications.
IPsec provides authentication and encryption, but the issue is key
management. This isn't a minor issue: security derives from the security
of the key.
Kerberos manages keys by providing a central point of control (for
multiple machines -- which must all be configured to respect that point
of control). IPsec is much more scalable but doesn't really address user
or application layer concepts.
I've been presuming that Kerberos could be used to manage IPsec keys.
This might not be true, I'll have to go study for a bit.
> > Furthermore, I have some doubt about whether IPsec really addresses
> > the issues of user authentication and privacy -- in many cases it
> > seems more applicable to host and maybe application issues.
> Not so. Its a network security protocol.
How does a user authenticate herself with SKIP?
> > Also, SKIP, as far as I know, is an example of an early IPsec effort,
> > and SSL does not address all the same issues.
> Not so. SKIP is a competitor for ISAKMP which is part of IPSec. That
> is the major disadvantage of SKIP; IETF has selected ISAKMP for
> standardization. However, there are few if any implementation of
> ISAKMP and none that I know of for Linux. Anyone have pointers here?
> SKIP is available now for many platforms and its seems to be getting
> industry backing.
I think we're saying the same thing (except that I've simplified it a
bit, perhaps too much).
> > Raul, wondering about the implications of a Kerberos and ssh combo.
> SKIP is very much like ssh except all the work is done at the IP level
> and all protocols get the benefit of encryption/authentication.
Hmm... I just realized that I'm ignorant here. To fill Kerberos's niche,
you'd have to be able to encode user id and group ids on a SKIP session
(that's not quite how Kerberos operates, but that's one of the reasons
why Kerberos requires so many things be rebuilt). How does SKIP deal
with the user obtaining these ids while signed on at different machines?
[Kerberos requires that the user be able to trust the machine they're
signing on at (e.g. to not reveal keystrokes), and that the machine be
able to talk kerberos with the authentication server. But nothing about
the user's identity need be stored on that machine.]
Finally, I think that an easy "plug in and configure" version of
Kerberos would require much of kerberos to go into the kernel, pam
support, and a bit of design work. But maybe that's not all that
relevant to this discussion. [Note that I expect we're going to have to
have some kind of support for Kerberos of some kind because it's being
built into some mass market products -- but maybe that work should be
left to the people that need to interoperate with those products?]
--
Raul
--
E-mail the word "unsubscribe" to debian-devel-request@lists.debian.org
TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to listmaster@lists.debian.org
Reply to: