← Back to branch summary

~ubuntu-branches/ubuntu/trusty/heimdal/trusty-proposed

« back to all changes in this revision

Viewing changes to .pc/texinfo_5.1/doc/whatis.texi

  • Committer: Package Import Robot
  • Author(s): Brian May
  • Date: 2013-06-03 12:06:56 UTC
  • Revision ID: package-import@ubuntu.com-20130603120656-s8cd5igpolk3c6h3
Tags: 1.6~git20120403+dfsg1-3
http://bugs.debian.org/710731
http://bugs.debian.org/711221
* Move /usr/share/doc/heimdal-kdc/examples to
  /usr/share/heimdal-kdc. Closes: #710731.
* Fix textinfo build errors. Closes: #711221.

Show diffs side-by-side

added added

removed removed

Lines of Context:
.pc/texinfo_5.1/doc/whatis.texi
 
1
@c $Id$
 
2
 
 
3
@node What is Kerberos?, Building and Installing, Introduction, Top
 
4
@chapter What is Kerberos?
 
5
 
 
6
@quotation
 
7
@flushleft
 
8
        Now this Cerberus had three heads of dogs,
 
9
        the tail of a dragon, and on his back the
 
10
        heads of all sorts of snakes.
 
11
        --- Pseudo-Apollodorus Library 2.5.12
 
12
@end flushleft
 
13
@end quotation
 
14
 
 
15
Kerberos is a system for authenticating users and services on a network.
 
16
It is built upon the assumption that the network is ``unsafe''.  For
 
17
example, data sent over the network can be eavesdropped and altered, and
 
18
addresses can also be faked.  Therefore they cannot be used for
 
19
authentication purposes.
 
20
@cindex authentication
 
21
 
 
22
Kerberos is a trusted third-party service.  That means that there is a
 
23
third party (the kerberos server) that is trusted by all the entities on
 
24
the network (users and services, usually called @dfn{principals}).  All
 
25
principals share a secret password (or key) with the kerberos server and
 
26
this enables principals to verify that the messages from the kerberos
 
27
server are authentic.  Thus trusting the kerberos server, users and
 
28
services can authenticate each other.
 
29
 
 
30
@section Basic mechanism
 
31
 
 
32
@ifinfo
 
33
@macro sub{arg}
 
34
<\arg\>
 
35
@end macro
 
36
@end ifinfo
 
37
 
 
38
@tex
 
39
@def@xsub#1{$_{#1}$}
 
40
@global@let@sub=@xsub
 
41
@end tex
 
42
 
 
43
@ifhtml
 
44
@macro sub{arg}
 
45
@html
 
46
<sub>\arg\</sub>
 
47
@end html
 
48
@end macro
 
49
@end ifhtml
 
50
 
 
51
@c ifdocbook
 
52
@c macro sub{arg}
 
53
@c docbook
 
54
@c <subscript>\arg\</subscript>
 
55
@c end docbook
 
56
@c end macro
 
57
@c end ifdocbook
 
58
 
 
59
@quotation
 
60
@strong{Note} This discussion is about Kerberos version 4, but version
 
61
5 works similarly.
 
62
@end quotation
 
63
 
 
64
In Kerberos, principals use @dfn{tickets} to prove that they are who
 
65
they claim to be. In the following example, @var{A} is the initiator of
 
66
the authentication exchange, usually a user, and @var{B} is the service
 
67
that @var{A} wishes to use.
 
68
 
 
69
To obtain a ticket for a specific service, @var{A} sends a ticket
 
70
request to the kerberos server. The request contains @var{A}'s and
 
71
@var{B}'s names (along with some other fields). The kerberos server
 
72
checks that both @var{A} and @var{B} are valid principals.
 
73
 
 
74
Having verified the validity of the principals, it creates a packet
 
75
containing @var{A}'s and @var{B}'s names, @var{A}'s network address
 
76
(@var{A@sub{addr}}), the current time (@var{t@sub{issue}}), the lifetime
 
77
of the ticket (@var{life}), and a secret @dfn{session key}
 
78
@cindex session key
 
79
(@var{K@sub{AB}}). This packet is encrypted with @var{B}'s secret key
 
80
(@var{K@sub{B}}).  The actual ticket (@var{T@sub{AB}}) looks like this:
 
81
(@{@var{A}, @var{B}, @var{A@sub{addr}}, @var{t@sub{issue}}, @var{life},
 
82
@var{K@sub{AB}}@}@var{K@sub{B}}).
 
83
 
 
84
The reply to @var{A} consists of the ticket (@var{T@sub{AB}}), @var{B}'s
 
85
name, the current time, the lifetime of the ticket, and the session key, all
 
86
encrypted in @var{A}'s secret key (@{@var{B}, @var{t@sub{issue}},
 
87
@var{life}, @var{K@sub{AB}}, @var{T@sub{AB}}@}@var{K@sub{A}}). @var{A}
 
88
decrypts the reply and retains it for later use.
 
89
 
 
90
@sp 1
 
91
 
 
92
Before sending a message to @var{B}, @var{A} creates an authenticator
 
93
consisting of @var{A}'s name, @var{A}'s address, the current time, and a
 
94
``checksum'' chosen by @var{A}, all encrypted with the secret session
 
95
key (@{@var{A}, @var{A@sub{addr}}, @var{t@sub{current}},
 
96
@var{checksum}@}@var{K@sub{AB}}). This is sent together with the ticket
 
97
received from the kerberos server to @var{B}.  Upon reception, @var{B}
 
98
decrypts the ticket using @var{B}'s secret key.  Since the ticket
 
99
contains the session key that the authenticator was encrypted with,
 
100
@var{B} can now also decrypt the authenticator. To verify that @var{A}
 
101
really is @var{A}, @var{B} now has to compare the contents of the ticket
 
102
with that of the authenticator. If everything matches, @var{B} now
 
103
considers @var{A} as properly authenticated.
 
104
 
 
105
@c (here we should have some more explanations)
 
106
 
 
107
@section Different attacks
 
108
 
 
109
@subheading Impersonating A
 
110
 
 
111
An impostor, @var{C} could steal the authenticator and the ticket as it
 
112
is transmitted across the network, and use them to impersonate
 
113
@var{A}. The address in the ticket and the authenticator was added to
 
114
make it more difficult to perform this attack.  To succeed @var{C} will
 
115
have to either use the same machine as @var{A} or fake the source
 
116
addresses of the packets. By including the time stamp in the
 
117
authenticator, @var{C} does not have much time in which to mount the
 
118
attack.
 
119
 
 
120
@subheading Impersonating B
 
121
 
 
122
@var{C} can hijack @var{B}'s network address, and when @var{A} sends
 
123
her credentials, @var{C} just pretend to verify them. @var{C} can't
 
124
be sure that she is talking to @var{A}.
 
125
 
 
126
@section Defence strategies
 
127
 
 
128
It would be possible to add a @dfn{replay cache}
 
129
@cindex replay cache
 
130
to the server side.  The idea is to save the authenticators sent during
 
131
the last few minutes, so that @var{B} can detect when someone is trying
 
132
to retransmit an already used message. This is somewhat impractical
 
133
(mostly regarding efficiency), and is not part of Kerberos 4; MIT
 
134
Kerberos 5 contains it.
 
135
 
 
136
To authenticate @var{B}, @var{A} might request that @var{B} sends
 
137
something back that proves that @var{B} has access to the session
 
138
key. An example of this is the checksum that @var{A} sent as part of the
 
139
authenticator. One typical procedure is to add one to the checksum,
 
140
encrypt it with the session key and send it back to @var{A}.  This is
 
141
called @dfn{mutual authentication}.
 
142
 
 
143
The session key can also be used to add cryptographic checksums to the
 
144
messages sent between @var{A} and @var{B} (known as @dfn{message
 
145
integrity}).  Encryption can also be added (@dfn{message
 
146
confidentiality}). This is probably the best approach in all cases.
 
147
@cindex integrity
 
148
@cindex confidentiality
 
149
 
 
150
@section Further reading
 
151
 
 
152
The original paper on Kerberos from 1988 is @cite{Kerberos: An
 
153
Authentication Service for Open Network Systems}, by Jennifer Steiner,
 
154
Clifford Neuman and Jeffrey I. Schiller.
 
155
 
 
156
A less technical description can be found in @cite{Designing an
 
157
Authentication System: a Dialogue in Four Scenes} by Bill Bryant, also
 
158
from 1988.
 
159
 
 
160
These documents can be found on our web-page at
 
161
@url{http://www.pdc.kth.se/kth-krb/}.