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
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
|
.\"
.\" This source code is no longer held under any constraint of USA
.\" `cryptographic laws' since it was exported legally. The cryptographic
.\" functions were removed from the code and a "Bones" distribution was
.\" made. A Commodity Jurisdiction Request #012-94 was filed with the
.\" USA State Department, who handed it to the Commerce department. The
.\" code was determined to fall under General License GTDA under ECCN 5D96G,
.\" and hence exportable. The cryptographic interfaces were re-added by Eric
.\" Young, and then KTH proceeded to maintain the code in the free world.
.\"
.\"Copyright (C) 1989 by the Massachusetts Institute of Technology
.\"
.\"Export of this software from the United States of America is assumed
.\"to require a specific license from the United States Government.
.\"It is the responsibility of any person or organization contemplating
.\"export to obtain such a license before exporting.
.\"
.\"WITHIN THAT CONSTRAINT, permission to use, copy, modify, and
.\"distribute this software and its documentation for any purpose and
.\"without fee is hereby granted, provided that the above copyright
.\"notice appear in all copies and that both that copyright notice and
.\"this permission notice appear in supporting documentation, and that
.\"the name of M.I.T. not be used in advertising or publicity pertaining
.\"to distribution of the software without specific, written prior
.\"permission. M.I.T. makes no representations about the suitability of
.\"this software for any purpose. It is provided "as is" without express
.\"or implied warranty.
.\"
.\" $OpenBSD: kerberos.8,v 1.4 1998/02/25 15:50:56 art Exp $
.TH KERBEROS 8 "Kerberos Version 4.0" "MIT Project Athena"
.SH NAME
kerberos \- introduction to the Kerberos system
.SH DESCRIPTION
The
Kerberos
system authenticates
individual users in a network environment.
After authenticating yourself to
Kerberos,
you can use network utilities such as
.IR rlogin ,
.IR rcp ,
and
.IR rsh
without
having to present passwords to remote hosts and without having to bother
with
.I \.rhosts
files.
Note that these utilities will work without passwords only if
the remote machines you deal with
support the
Kerberos
system.
All Athena timesharing machines and public workstations support
Kerberos.
.PP
Before you can use
Kerberos,
you must register as an Athena user,
and you must make sure you have been added to
the
Kerberos
database.
You can use the
.I kinit
command to find out.
This command
tries to log you into the
Kerberos
system.
.I kinit
will prompt you for a username and password.
Enter your username and password.
If the utility lets you login without giving you a message,
you have already been registered.
.PP
If you enter your username and
.I kinit
responds with this message:
.nf
Principal unknown (kerberos)
.fi
you haven't been registered as a
Kerberos
user.
See your system administrator.
.PP
A Kerberos name contains three parts.
The first is the
.I principal name,
which is usually a user's or service's name.
The second is the
.I instance,
which in the case of a user is usually null.
Some users may have privileged instances, however,
such as ``root'' or ``admin''.
In the case of a service, the instance is the
name of the machine on which it runs; i.e. there
can be an
.I rlogin
service running on the machine ABC, which
is different from the rlogin service running on
the machine XYZ.
The third part of a Kerberos name
is the
.I realm.
The realm corresponds to the Kerberos service providing
authentication for the principal.
For example, at MIT there is a Kerberos running at the
Laboratory for Computer Science and one running at
Project Athena.
.PP
When writing a Kerberos name, the principal name is
separated from the instance (if not null) by a period,
and the realm (if not the local realm) follows, preceded by
an ``@'' sign.
The following are examples of valid Kerberos names:
.sp
.nf
.in +8
billb
jis.admin
srz@lcs.mit.edu
treese.root@athena.mit.edu
.in -8
.fi
.PP
When you authenticate yourself with
Kerberos,
through either the workstation
.I toehold
system or the
.I kinit
command,
Kerberos
gives you an initial
Kerberos
.IR ticket .
(A
Kerberos
ticket
is an encrypted protocol message that provides authentication.)
Kerberos
uses this ticket for network utilities
such as
.I rlogin
and
.IR rcp .
The ticket transactions are done transparently,
so you don't have to worry about their management.
.PP
Note, however, that tickets expire.
Privileged tickets, such as root instance tickets,
expire in a few minutes, while tickets that carry more ordinary
privileges may be good for several hours or a day, depending on the
installation's policy.
If your login session extends beyond the time limit,
you will have to re-authenticate yourself to
Kerberos
to get new tickets.
Use the
.IR kinit
command to re-authenticate yourself.
.PP
If you use the
.I kinit
command to get your tickets,
make sure you use the
.I kdestroy
command
to destroy your tickets before you end your login session.
You should probably put the
.I kdestroy
command in your
.I \.logout
file so that your tickets will be destroyed automatically when you logout.
For more information about the
.I kinit
and
.I kdestroy
commands,
see the
.I kinit(1)
and
.I kdestroy(1)
manual pages.
.PP
Currently,
Kerberos
supports the following network services:
.IR rlogin ,
.IR rsh ,
and
.IR rcp .
Other services are being worked on,
such as the
.IR pop
mail system and NFS (network file system),
but are not yet available.
.SH "SEE ALSO"
kdestroy(1), kinit(1), klist(1), kpasswd(1), des_crypt(3), kerberos(3),
kadmin(8)
.SH BUGS
Kerberos
will not do authentication forwarding.
In other words,
if you use
.I rlogin
to login to a remote host,
you cannot use
Kerberos
services from that host
until you authenticate yourself explicitly on that host.
Although you may need to authenticate yourself on the remote
host,
be aware that when you do so,
.I rlogin
sends your password across the network in clear text.
.SH AUTHORS
Steve Miller, MIT Project Athena/Digital Equipment Corporation
.br
Clifford Neuman, MIT Project Athena
The following people helped out on various aspects of the system:
Jeff Schiller designed and wrote the administration server and its
user interface, kadmin.
He also wrote the dbm version of the database management system.
Mark Colan developed the
Kerberos
versions of
.IR rlogin ,
.IR rsh ,
and
.IR rcp ,
as well as contributing work on the servers.
John Ostlund developed the
Kerberos
versions of
.I passwd
and
.IR userreg .
Stan Zanarotti pioneered Kerberos in a foreign realm (LCS),
and made many contributions based on that experience.
Many people contributed code and/or useful ideas, including
Jim Aspnes,
Bob Baldwin,
John Barba,
Richard Basch,
Jim Bloom,
Bill Bryant,
Rob French,
Dan Geer,
David Jedlinsky,
John Kohl,
John Kubiatowicz,
Bob McKie,
Brian Murphy,
Ken Raeburn,
Chris Reed,
Jon Rochlis,
Mike Shanzer,
Bill Sommerfeld,
Jennifer Steiner,
Ted Ts'o,
and
Win Treese.
.SH RESTRICTIONS
COPYRIGHT 1985,1986 Massachusetts Institute of Technology
|