1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
|
Including Kerberos in Your Package
This document has been prepared by the maintainers of Kerberos
implementations in Debian as guidelines for adding Kerberos support to
packages in Debian. It does not currently represent policy, but by
following these guidelines you will help create a consistent user
experience and will minimize the likelihood of problems as Kerberos
implementations change. Kerberos in Debian is currently discussed on
the debian-kerberos@mekinok.com mailing list; go to
http://mailman.boxedpenguin.com/mailman/listinfo/debian-kerberos or
send mail to debian-kerberos-request@mekinok.com. Feel free to ask
questions about this document or about Kerberos in Debian on that list.
Information About Kerberos
There are two versions of Kerberos in wide use: version 4 and version
5. Version 4 uses DES exclusively, so its cryptographic strength is
somewhat weak. Basing new applications or new deployments on version
4 would be a poor idea but there is a significant deployed base of
version 4, so supporting it for some applications is important to our
users. Version 5 is an IETF standards-track protocol. It is somewhat
more complex than version 4, supporting multiple cryptosystems,
ticket forwarding and multi-homed machines.
In addition there are two other related security technologies. The
Generic Security Services API (GSSAPI) is an IETF standards-track API
for including security mechanisms into programs. There is a Kerberos
version 5 GSSAPI mechanism (RFC 1964), so programs that support GSSAPI
can use Kerberos and other authentication systems. Also, the Simple
Authentication and Security Layer (SASL, described by RFC 2222)
provides support for using any GSSAPI security mechanism, including
Kerberos, in applications.
There are three implementations of Kerberos in Debian. Kerberos4kth
is the Swedish Royal Institute of Technology's Kerberos version 4
implementation; it is packaged in the krb4 source package and the
Kerberos4kth binary packages. Heimdal is the Royal Institute's
Kerberos version 5 implementation. The upstream source supports
interoperability, so that an application can link against Kerberos4kth
and Heimdal to get both version 4 and version 5 support. The Debian
packages do not currently support this although they will soon. The
krb5 package includes MIT's reference implementation of Kerberos
version 5, along with backward compatibility for version 4.
To get development files for kerberos4kth, install kerberos4kth-dev. To
get development files for Heimdal install heimdal-dev. To get
development files for the MIT implementation install libkrb5-dev.
Note that libkrb5-dev does include Kerberos version 4 development
files as well.
Is Kerberos Useful for my Package
These guidelines are targeted at people who are trying to determine
whether to enable Kerberos support already present in their upstream
package. If you are considering adding security support to a program
that does not currently have it in the upstream source, then you are
strongly encouraged to ask for advice. Security is hard and we'd like
to try and help you benefit from the mistakes of others rather than
repeating them. You should generally prefer to add SASL support
rather than direct Kerberos support.
If you are considering enabling Kerberos version 4 support, you should
do so only if users of your package are in Kerberos version 4
environments or if users are choosing to build from source rather than
use your package because of the lack of Kerberos version 4 support.
There are many users of Kerberos version 4 POP, IMAP, CVS and Ssh, so
if your package implements one of these protocols it is probably worth
enabling Kerberos version 4.
Many programs use Kerberos as a way to perform initial authentication
or to check a password against a Kerberos server. For example an IMAP
server or web application might read a password over an SSL-encrypted
channel and try to authenticate that password against Kerberos. In
Debian, the libpam-krb5 and libpam-heimdal modules provide a better
approach to the same problem. You should enable PAM support in your
application and attempt to disable any code that uses Kerberos to get
a ticket from a plaintext password. If you need to leave this
functionality enabled for some reason, please get it reviewed by
someone familiar with the Kerberos API: getting initial tickets
correctly without creating a security hole can be problematic. Note
that some applications support SASL or a direct Kerberos mechanism for
doing a password-less authentication over the network but also include
Kerberos initial ticket support. For such applications, you probably
want to disable the initial ticket handling, but use the SASL or
networked Kerberos support.
Kerberos Behavior
Applications in Debian that support Kerberos should in general obey
the following guidelines:
1) Where practical Kerberos support should be built in the main
Debian package rather than providing a separate Kerberos package.
2) Non-Kerberized functionality should not be adversely affected by
the Kerberos functionality. For example building Kerberos into a
package should not suddenly cause previous authentication systems
to stop working.
3) Applications that function without Kerberos support should not
depend on Kerberos being configured. If the Kerberos configuration
files are not found, the application should simply disable
Kerberos. It is important to test that the application works
without Kerberos configuration files; if the application fails to
check error returns it may segfault.
4) If Kerberos is installed and configured, the application should
work with Kerberos with as little effort on the part of the user as
possible. For example in an ideal situation, installing a
networked application onto a computer with working Kerberos
configuration files and a Kerberos keytab for the appropriate
service should be sufficient for Kerberos authentication to work.
5) There should be a way for a user to disable plaintext or
unencrypted operation. For example, I should be able to configure
an IMAP server to require the Kerberos SASL mechanism and refuse
the plaintext login command.
6) There should be a way for a user to disable Kerberos for some
particular service that would normally use it without disabling
Kerberos for other services.
Choosing an Implementation
As mentioned there are three implementations of Kerberos in Debian.
The choice of which implementation to use is up to you, the maintainer
of a package adding Kerberos support. You should try to make your
package work both with the MIT implementation and with Heimdal (and
possibly KTH Kerberos version 4 if appropriate) depending on which
source package is used to build your package. However you will need
to pick an implementation to use for your uploads to Debian. Here are
some issues you should consider when picking an implementation.
1) Legal considerations may force you to use a particular
implementation. Currently the only known concern is that Heimdal
links against libssl, which is GPL incompatible. This means
that GPLed code without an exemption for linking against libssl
should use the MIT Kerberos implementation.
2) Otherwise it is your choice as maintainer. If you use a particular
implementation of Kerberos on a regular basis, then build your
packages with that. Otherwise consider which implementation of
Kerberos will be easiest to get working and will work best for your
package. If you don't have a clear choice, pick an implementation;
they should be interoperable so it doesn't matter that much which
one you choose.
|
