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
|
@c $Id: misc.texi,v 1.13 2003/03/30 21:30:59 lha Exp $
@node Things in search for a better place, Kerberos 4 issues, Setting up a realm, Top
@chapter Things in search for a better place
@section Making things work on Ciscos
Modern versions of Cisco IOS has some support for authenticating via
Kerberos 5. This can be used both by having the router get a ticket when
you login (boring), and by using Kerberos authenticated telnet to access
your router (less boring). The following has been tested on IOS
11.2(12), things might be different with other versions. Old versions
are known to have bugs.
To make this work, you will first have to configure your router to use
Kerberos (this is explained in the documentation). A sample
configuration looks like the following:
@example
aaa new-model
aaa authentication login default krb5-telnet krb5 enable
aaa authorization exec krb5-instance
kerberos local-realm FOO.SE
kerberos srvtab entry host/router.foo.se 0 891725446 4 1 8 012345678901234567
kerberos server FOO.SE 10.0.0.1
kerberos instance map admin 15
@end example
This tells you (among other things) that when logging in, the router
should try to authenticate with kerberised telnet, and if that fails try
to verify a plain text password via a Kerberos ticket exchange (as
opposed to a local database, RADIUS or something similar), and if that
fails try the local enable password. If you're not careful when you
specify the `login default' authentication mechanism, you might not be
able to login at all. The `instance map' and `authorization exec' lines
says that people with `admin' instances should be given `enabled' shells
when logging in.
The numbers after the principal on the `srvtab' line are principal type,
time stamp (in seconds since 1970), key version number (4), keytype (1 ==
des), key length (always 8 with des), and then the key.
To make the Heimdal KDC produce tickets that the Cisco can decode you
might have to turn on the @samp{encode_as_rep_as_tgs_rep} flag in the
KDC. You will also have to specify that the router can't handle anything
but @samp{des-cbc-crc}. This can be done with the @samp{del_enctype}
command of @samp{kadmin}.
This all fine and so, but unless you have an IOS version with encryption
(available only in the U.S) it doesn't really solve any problems. Sure
you don't have to send your password over the wire, but since the telnet
connection isn't protected it's still possible for someone to steal your
session. This won't be fixed until someone adds integrity to the telnet
protocol.
A working solution would be to hook up a machine with a real operating
system to the console of the Cisco and then use it as a backwards
terminal server.
@section Making things work on Transarc/OpenAFS AFS
@subsection How to get a KeyFile
@file{ktutil -k AFSKEYFILE:KeyFile get afs@@MY.REALM}
or you can extract it with kadmin
@example
kadmin> ext -k AFSKEYFILE:/usr/afs/etc/KeyFile afs@@My.CELL.NAME
@end example
You have to make sure you have a @code{des-cbc-md5} encryption type since that
is the key that will be converted.
@subsection How to convert a srvtab to a KeyFile
You need a @file{/usr/vice/etc/ThisCell} containing the cellname of you
AFS-cell.
@file{ktutil copy krb4:/root/afs-srvtab AFSKEYFILE:/usr/afs/etc/KeyFile}.
If keyfile already exists, this will add the new key in afs-srvtab to
KeyFile.
@section Using 2b tokens with AFS
@subsection What is 2b ?
2b is the name of the proposal that was implemented to give basic
Kerberos 5 support to AFS in rxkad. Its not real Kerberos 5 support
since it still uses fcrypt for data encryption and not Kerberos
encryption types.
Its only possible (in all cases) to do this for DES encryption types because
only then the token (the AFS equivalent of a ticket) will be be smaller
than the maximum size that can fit in the token cache in
OpenAFS/Transarc client. Its so tight fit that some extra wrapping on the ASN1/DER encoding is removed from the Kerberos ticket.
2b uses a Kerberos 5 EncTicketPart instead of a Kerberos 4 ditto for
the part of the ticket that is encrypted with the service's key. The
client doesn't know what's inside the encrypted data so to the client it doesn't matter.
To differentiate between Kerberos 4 tickets and Kerberos 5 tickets 2b
uses a special kvno, 213 for 2b tokens and 255 for Kerberos 5 tokens.
Its a requirement that all AFS servers that support 2b also support
native Kerberos 5 in rxkad.
@subsection Configuring Heimdal to use 2b tokens
Support for 2b tokens are turned on for specific principals by adding
them to the string list option @code{[kdc]use_2b} in the kdc's
@file{krb5.conf} file.
@example
[kdc]
use_2b = @{
afs@@SU.SE = yes
afs/it.su.se@@SU.SE = yes
@}
@end example
@subsection Configuring AFS clients
There is no need to configure AFS clients. The only software that
needs to be installed/upgrade is a Kerberos 5 enabled @file{afslog}.
|
