aboutsummaryrefslogtreecommitdiffstats
path: root/doc/html/admin/advanced/retiring-des.html
blob: 8ac29b3dca5125e53e20fc985edbb3d1cd35b20f (plain) (blame)
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
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">


<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    
    <title>Retiring DES &mdash; MIT Kerberos Documentation</title>
    
    <link rel="stylesheet" href="../../_static/agogo.css" type="text/css" />
    <link rel="stylesheet" href="../../_static/pygments.css" type="text/css" />
    <link rel="stylesheet" href="../../_static/kerb.css" type="text/css" />
    
    <script type="text/javascript">
      var DOCUMENTATION_OPTIONS = {
        URL_ROOT:    '../../',
        VERSION:     '1.16',
        COLLAPSE_INDEX: false,
        FILE_SUFFIX: '.html',
        HAS_SOURCE:  true
      };
    </script>
    <script type="text/javascript" src="../../_static/jquery.js"></script>
    <script type="text/javascript" src="../../_static/underscore.js"></script>
    <script type="text/javascript" src="../../_static/doctools.js"></script>
    <link rel="author" title="About these documents" href="../../about.html" />
    <link rel="copyright" title="Copyright" href="../../copyright.html" />
    <link rel="top" title="MIT Kerberos Documentation" href="../../index.html" />
    <link rel="up" title="Advanced topics" href="index.html" />
    <link rel="next" title="Various links" href="../various_envs.html" />
    <link rel="prev" title="LDAP backend on Ubuntu 10.4 (lucid)" href="ldapbackend.html" /> 
  </head>
  <body>
    <div class="header-wrapper">
        <div class="header">
            
            
            <h1><a href="../../index.html">MIT Kerberos Documentation</a></h1>
            
            <div class="rel">
                
        <a href="../../index.html" title="Full Table of Contents"
            accesskey="C">Contents</a> |
        <a href="ldapbackend.html" title="LDAP backend on Ubuntu 10.4 (lucid)"
            accesskey="P">previous</a> |
        <a href="../various_envs.html" title="Various links"
            accesskey="N">next</a> |
        <a href="../../genindex.html" title="General Index"
            accesskey="I">index</a> |
        <a href="../../search.html" title="Enter search criteria"
            accesskey="S">Search</a> |
    <a href="mailto:krb5-bugs@mit.edu?subject=Documentation__Retiring DES">feedback</a>
            </div>
        </div>
    </div>

    <div class="content-wrapper">
      <div class="content">
        <div class="document">
            
      <div class="documentwrapper">
        <div class="bodywrapper">
          <div class="body">
            
  <div class="section" id="retiring-des">
<span id="id1"></span><h1>Retiring DES<a class="headerlink" href="#retiring-des" title="Permalink to this headline"></a></h1>
<p>Version 5 of the Kerberos protocol was originally implemented using
the Data Encryption Standard (DES) as a block cipher for encryption.
While it was considered secure at the time, advancements in computational
ability have rendered DES vulnerable to brute force attacks on its 56-bit
keyspace.  As such, it is now considered insecure and should not be
used (<span class="target" id="index-0"></span><a class="rfc reference external" href="http://tools.ietf.org/html/rfc6649.html"><strong>RFC 6649</strong></a>).</p>
<div class="section" id="history">
<h2>History<a class="headerlink" href="#history" title="Permalink to this headline"></a></h2>
<p>DES was used in the original Kerberos implementation, and was the
only cryptosystem in krb5 1.0.  Partial support for triple-DES (3DES) was
added in version 1.1, with full support following in version 1.2.
The Advanced Encryption Standard (AES), which supersedes DES, gained
partial support in version 1.3.0 of krb5 and full support in version 1.3.2.
However, deployments of krb5 using Kerberos databases created with older
versions of krb5 will not necessarily start using strong crypto for
ordinary operation without administrator intervention.</p>
</div>
<div class="section" id="types-of-keys">
<h2>Types of keys<a class="headerlink" href="#types-of-keys" title="Permalink to this headline"></a></h2>
<ul class="simple">
<li>The database master key:  This key is not exposed to user requests,
but is used to encrypt other key material stored in the kerberos
database.  The database master key is currently stored as <tt class="docutils literal"><span class="pre">K/M</span></tt>
by default.</li>
<li>Password-derived keys:  User principals frequently have keys
derived from a password.  When a new password is set, the KDC
uses various string2key functions to generate keys in the database
for that principal.</li>
<li>Keytab keys:  Application server principals generally use random
keys which are not derived from a password.  When the database
entry is created, the KDC generates random keys of various enctypes
to enter in the database, which are conveyed to the application server
and stored in a keytab.</li>
<li>Session keys:  These are short-term keys generated by the KDC while
processing client requests, with an enctype selected by the KDC.</li>
</ul>
<p>For details on the various enctypes and how enctypes are selected by the KDC
for session keys and client/server long-term keys, see <a class="reference internal" href="../enctypes.html#enctypes"><em>Encryption types</em></a>.
When using the <a class="reference internal" href="../admin_commands/kadmin_local.html#kadmin-1"><em>kadmin</em></a> interface to generate new long-term keys,
the <strong>-e</strong> argument can be used to force a particular set of enctypes,
overriding the KDC default values.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">When the KDC is selecting a session key, it has no knowledge about the
kerberos installation on the server which will receive the service ticket,
only what keys are in the database for the service principal.
In order to allow uninterrupted operation to
clients while migrating away from DES, care must be taken to ensure that
kerberos installations on application server machines are configured to
support newer encryption types before keys of those new encryption types
are created in the Kerberos database for those server principals.</p>
</div>
</div>
<div class="section" id="upgrade-procedure">
<h2>Upgrade procedure<a class="headerlink" href="#upgrade-procedure" title="Permalink to this headline"></a></h2>
<p>This procedure assumes that the KDC software has already been upgraded
to a modern version of krb5 that supports non-DES keys, so that the
only remaining task is to update the actual keys used to service requests.
The realm used for demonstrating this procedure, ZONE.MIT.EDU,
is an example of the worst-case scenario, where all keys in the realm
are DES.  The realm was initially created with a very old version of krb5,
and <strong>supported_enctypes</strong> in <a class="reference internal" href="../conf_files/kdc_conf.html#kdc-conf-5"><em>kdc.conf</em></a> was set to a value
appropriate when the KDC was installed, but was not updated as the KDC
was upgraded:</p>
<div class="highlight-python"><div class="highlight"><pre>[realms]
        ZONE.MIT.EDU = {
                [...]
                master_key_type = des-cbc-crc
                supported_enctypes = des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3
        }
</pre></div>
</div>
<p>This resulted in the keys for all principals in the realm being forced
to DES-only, unless specifically requested using <a class="reference internal" href="../admin_commands/kadmin_local.html#kadmin-1"><em>kadmin</em></a>.</p>
<p>Before starting the upgrade, all KDCs were running krb5 1.11,
and the database entries for some &#8220;high-value&#8221; principals were:</p>
<div class="highlight-python"><div class="highlight"><pre>[root@casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q &#39;getprinc krbtgt/ZONE.MIT.EDU&#39;
[...]
Number of keys: 1
Key: vno 1, des-cbc-crc:v4
[...]
[root@casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q &#39;getprinc kadmin/admin&#39;
[...]
Number of keys: 1
Key: vno 15, des-cbc-crc
[...]
[root@casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q &#39;getprinc kadmin/changepw&#39;
[...]
Number of keys: 1
Key: vno 14, des-cbc-crc
[...]
</pre></div>
</div>
<p>The <tt class="docutils literal"><span class="pre">krbtgt/REALM</span></tt> key appears to have never been changed since creation
(its kvno is 1), and all three database entries have only a des-cbc-crc key.</p>
<div class="section" id="the-krbtgt-key-and-kdc-keys">
<h3>The krbtgt key and KDC keys<a class="headerlink" href="#the-krbtgt-key-and-kdc-keys" title="Permalink to this headline"></a></h3>
<p>Perhaps the biggest single-step improvement in the security of the cell
is gained by strengthening the key of the ticket-granting service principal,
<tt class="docutils literal"><span class="pre">krbtgt/REALM</span></tt>&#8212;if this principal&#8217;s key is compromised, so is the
entire realm.  Since the server that will handle service tickets
for this principal is the KDC itself, it is easy to guarantee that it
will be configured to support any encryption types which might be
selected.  However, the default KDC behavior when creating new keys is to
remove the old keys, which would invalidate all existing tickets issued
against that principal, rendering the TGTs cached by clients useless.
Instead, a new key can be created with the old key retained, so that
existing tickets will still function until their scheduled expiry
(see <a class="reference internal" href="../database.html#changing-krbtgt-key"><em>Changing the krbtgt key</em></a>).</p>
<div class="highlight-python"><div class="highlight"><pre>[root@casio krb5kdc]# enctypes=aes256-cts-hmac-sha1-96:normal,\
&gt; aes128-cts-hmac-sha1-96:normal,des3-hmac-sha1:normal,des-cbc-crc:normal
[root@casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q &quot;cpw -e ${enctypes} -randkey \
&gt; -keepold krbtgt/ZONE.MIT.EDU&quot;
Authenticating as principal root/admin@ZONE.MIT.EDU with password.
Key for &quot;krbtgt/ZONE.MIT.EDU@ZONE.MIT.EDU&quot; randomized.
</pre></div>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The new <tt class="docutils literal"><span class="pre">krbtgt&#64;REALM</span></tt> key should be propagated to slave KDCs
immediately so that TGTs issued by the master KDC can be used to
issue service tickets on slave KDCs.  Slave KDCs will refuse requests
using the new TGT kvno until the new krbtgt entry has been propagated
to them.</p>
</div>
<p>It is necessary to explicitly specify the enctypes for the new database
entry, since <strong>supported_enctypes</strong> has not been changed.  Leaving
<strong>supported_enctypes</strong> unchanged makes a potential rollback operation
easier, since all new keys of new enctypes are the result of explicit
administrator action and can be easily enumerated.
Upgrading the krbtgt key should have minimal user-visible disruption other
than that described in the note above, since only clients which list the
new enctypes as supported will use them, per the procedure
in <a class="reference internal" href="../enctypes.html#session-key-selection"><em>Session key selection</em></a>.
Once the krbtgt key is updated, the session and ticket keys for user
TGTs will be strong keys, but subsequent requests
for service tickets will still get DES keys until the service principals
have new keys generated.  Application service
remains uninterrupted due to the key-selection procedure on the KDC.</p>
<p>After the change, the database entry is now:</p>
<div class="highlight-python"><div class="highlight"><pre>[root@casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q &#39;getprinc krbtgt/ZONE.MIT.EDU&#39;
[...]
Number of keys: 5
Key: vno 2, aes256-cts-hmac-sha1-96
Key: vno 2, aes128-cts-hmac-sha1-96
Key: vno 2, des3-cbc-sha1
Key: vno 2, des-cbc-crc
Key: vno 1, des-cbc-crc:v4
[...]
</pre></div>
</div>
<p>Since the expected disruptions from rekeying the krbtgt principal are
minor, after a short testing period, it is
appropriate to rekey the other high-value principals, <tt class="docutils literal"><span class="pre">kadmin/admin&#64;REALM</span></tt>
and <tt class="docutils literal"><span class="pre">kadmin/changepw&#64;REALM</span></tt>. These are the service principals used for
changing user passwords and updating application keytabs.  The kadmin
and password-changing services are regular kerberized services, so the
session-key-selection algorithm described in <a class="reference internal" href="../enctypes.html#session-key-selection"><em>Session key selection</em></a>
applies.  It is particularly important to have strong session keys for
these services, since user passwords and new long-term keys are conveyed
over the encrypted channel.</p>
<div class="highlight-python"><div class="highlight"><pre>[root@casio krb5kdc]# enctypes=aes256-cts-hmac-sha1-96:normal,\
&gt; aes128-cts-hmac-sha1-96:normal,des3-hmac-sha1:normal
[root@casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q &quot;cpw -e ${enctypes} -randkey \
&gt; kadmin/admin&quot;
Authenticating as principal root/admin@ZONE.MIT.EDU with password.
Key for &quot;kadmin/admin@ZONE.MIT.EDU&quot; randomized.
[root@casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q &quot;cpw -e ${enctypes} -randkey \
&gt; kadmin/changepw&quot;
Authenticating as principal root/admin@ZONE.MIT.EDU with password.
Key for &quot;kadmin/changepw@ZONE.MIT.EDU&quot; randomized.
</pre></div>
</div>
<p>It is not necessary to retain a single-DES key for these services, since
password changes are not part of normal daily workflow, and disruption
from a client failure is likely to be minimal.  Furthermore, if a kerberos
client experiences failure changing a user password or keytab key,
this indicates that that client will become inoperative once services
are rekeyed to non-DES enctypes.  Such problems can be detected early
at this stage, giving more time for corrective action.</p>
</div>
<div class="section" id="adding-strong-keys-to-application-servers">
<h3>Adding strong keys to application servers<a class="headerlink" href="#adding-strong-keys-to-application-servers" title="Permalink to this headline"></a></h3>
<p>Before switching the default enctypes for new keys over to strong enctypes,
it may be desired to test upgrading a handful of services with the
new configuration before flipping the switch for the defaults.  This
still requires using the <strong>-e</strong> argument in <a class="reference internal" href="../admin_commands/kadmin_local.html#kadmin-1"><em>kadmin</em></a> to get non-default
enctypes:</p>
<div class="highlight-python"><div class="highlight"><pre>[root@casio krb5kdc]# enctypes=aes256-cts-hmac-sha1-96:normal,\
&gt; aes128-cts-hmac-sha1-96:normal,des3-cbc-sha1:normal,des-cbc-crc:normal
[root@casio krb5kdc]# kadmin -r ZONE.MIT.EDU -p zephyr/zephyr@ZONE.MIT.EDU -k -t \
&gt; /etc/zephyr/krb5.keytab  -q &quot;ktadd -e ${enctypes} \
&gt; -k /etc/zephyr/krb5.keytab zephyr/zephyr@ZONE.MIT.EDU&quot;
Authenticating as principal zephyr/zephyr@ZONE.MIT.EDU with keytab /etc/zephyr/krb5.keytab.
Entry for principal zephyr/zephyr@ZONE.MIT.EDU with kvno 4, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/zephyr/krb5.keytab.
Entry for principal zephyr/zephyr@ZONE.MIT.EDU with kvno 4, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/etc/zephyr/krb5.keytab.
Entry for principal zephyr/zephyr@ZONE.MIT.EDU with kvno 4, encryption type des3-cbc-sha1 added to keytab WRFILE:/etc/zephyr/krb5.keytab.
Entry for principal zephyr/zephyr@ZONE.MIT.EDU with kvno 4, encryption type des-cbc-crc added to keytab WRFILE:/etc/zephyr/krb5.keytab.
</pre></div>
</div>
<p>Be sure to remove the old keys from the application keytab, per best
practice.</p>
<div class="highlight-python"><div class="highlight"><pre>[root@casio krb5kdc]# k5srvutil -f /etc/zephyr/krb5.keytab delold
Authenticating as principal zephyr/zephyr@ZONE.MIT.EDU with keytab /etc/zephyr/krb5.keytab.
Entry for principal zephyr/zephyr@ZONE.MIT.EDU with kvno 3 removed from keytab WRFILE:/etc/zephyr/krb5.keytab.
</pre></div>
</div>
</div>
<div class="section" id="adding-strong-keys-by-default">
<h3>Adding strong keys by default<a class="headerlink" href="#adding-strong-keys-by-default" title="Permalink to this headline"></a></h3>
<p>Once the high-visibility services have been rekeyed, it is probably
appropriate to change <a class="reference internal" href="../conf_files/kdc_conf.html#kdc-conf-5"><em>kdc.conf</em></a> to generate keys with the new
encryption types by default.  This enables server administrators to generate
new enctypes with the <strong>change</strong> subcommand of <a class="reference internal" href="../admin_commands/k5srvutil.html#k5srvutil-1"><em>k5srvutil</em></a>,
and causes user password
changes to add new encryption types for their entries.  It will probably
be necessary to implement administrative controls to cause all user
principal keys to be updated in a reasonable period of time, whether
by forcing password changes or a password synchronization service that
has access to the current password and can add the new keys.</p>
<div class="highlight-python"><div class="highlight"><pre>[realms]
        ZONE.MIT.EDU = {
                supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal des3-hmac-sha1:normal des-cbc-crc:normal
</pre></div>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The krb5kdc process must be restarted for these changes to take effect.</p>
</div>
<p>At this point, all service administrators can update their services and the
servers behind them to take advantage of strong cryptography.
If necessary, the server&#8217;s krb5 installation should be configured and/or
upgraded to a version supporting non-DES keys.  See <a class="reference internal" href="../enctypes.html#enctypes"><em>Encryption types</em></a> for
krb5 version and configuration settings.
Only when the service is configured to accept non-DES keys should
the key version number be incremented and new keys generated
(<tt class="docutils literal"><span class="pre">k5srvutil</span> <span class="pre">change</span> <span class="pre">&amp;&amp;</span> <span class="pre">k5srvutil</span> <span class="pre">delold</span></tt>).</p>
<div class="highlight-python"><div class="highlight"><pre>root@dr-willy:~# k5srvutil change
Authenticating as principal host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU with keytab /etc/krb5.keytab.
Entry for principal host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU with kvno 3, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
root@dr-willy:~# klist -e -k -t /etc/krb5.keytab
Keytab name: WRFILE:/etc/krb5.keytab
KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   2 10/10/12 17:03:59 host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU (DES cbc mode with CRC-32)
   3 12/12/12 15:31:19 host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   3 12/12/12 15:31:19 host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   3 12/12/12 15:31:19 host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU (Triple DES cbc mode with HMAC/sha1)
   3 12/12/12 15:31:19 host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU (DES cbc mode with CRC-32)
root@dr-willy:~# k5srvutil delold
Authenticating as principal host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU with keytab /etc/krb5.keytab.
Entry for principal host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU with kvno 2 removed from keytab WRFILE:/etc/krb5.keytab.
</pre></div>
</div>
<p>When a single service principal is shared by multiple backend servers in
a load-balanced environment, it may be necessary to schedule downtime
or adjust the population in the load-balanced pool in order to propagate
the updated keytab to all hosts in the pool with minimal service interruption.</p>
</div>
<div class="section" id="removing-des-keys-from-usage">
<h3>Removing DES keys from usage<a class="headerlink" href="#removing-des-keys-from-usage" title="Permalink to this headline"></a></h3>
<p>This situation remains something of a testing or transitory state,
as new DES keys are still being generated, and will be used if requested
by a client.  To make more progress removing DES from the realm, the KDC
should be configured to not generate such keys by default.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">An attacker posing as a client can implement a brute force attack against
a DES key for any principal, if that key is in the current (highest-kvno)
key list.  This attack is only possible if <strong>allow_weak_crypto = true</strong>
is enabled on the KDC.  Setting the <strong>+requires_preauth</strong> flag on a
principal forces this attack to be an online attack, much slower than
the offline attack otherwise available to the attacker.  However, setting
this flag on a service principal is not always advisable; see the entry in
<a class="reference internal" href="../admin_commands/kadmin_local.html#add-principal"><em>add_principal</em></a> for details.</p>
</div>
<p>The following KDC configuration will not generate DES keys by default:</p>
<div class="highlight-python"><div class="highlight"><pre>[realms]
        ZONE.MIT.EDU = {
                supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal des3-hmac-sha1:normal
</pre></div>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">As before, the KDC process must be restarted for this change to take
effect.  It is best practice to update kdc.conf on all KDCs, not just the
master, to avoid unpleasant surprises should the master fail and a slave
need to be promoted.</p>
</div>
<p>It is now appropriate to remove the legacy single-DES key from the
<tt class="docutils literal"><span class="pre">krbtgt/REALM</span></tt> entry:</p>
<div class="highlight-python"><div class="highlight"><pre>[root@casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q &quot;cpw -randkey -keepold \
&gt; krbtgt/ZONE.MIT.EDU&quot;
Authenticating as principal host/admin@ATHENA.MIT.EDU with password.
Key for &quot;krbtgt/ZONE.MIT.EDU@ZONE.MIT.EDU&quot; randomized.
</pre></div>
</div>
<p>After the maximum ticket lifetime has passed, the old database entry
should be removed.</p>
<div class="highlight-python"><div class="highlight"><pre>[root@casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q &#39;purgekeys krbtgt/ZONE.MIT.EDU&#39;
Authenticating as principal root/admin@ZONE.MIT.EDU with password.
Old keys for principal &quot;krbtgt/ZONE.MIT.EDU@ZONE.MIT.EDU&quot; purged.
</pre></div>
</div>
<p>After the KDC is restarted with the new <strong>supported_enctypes</strong>,
all user password changes and application keytab updates will not
generate DES keys by default.</p>
<div class="highlight-python"><div class="highlight"><pre>contents-vnder-pressvre:~&gt; kpasswd zonetest@ZONE.MIT.EDU
Password for zonetest@ZONE.MIT.EDU:  [enter old password]
Enter new password:                  [enter new password]
Enter it again:                      [enter new password]
Password changed.
contents-vnder-pressvre:~&gt; kadmin -r ZONE.MIT.EDU -q &#39;getprinc zonetest&#39;
[...]
Number of keys: 3
Key: vno 9, aes256-cts-hmac-sha1-96
Key: vno 9, aes128-cts-hmac-sha1-96
Key: vno 9, des3-cbc-sha1
[...]

[kaduk@glossolalia ~]$ kadmin -p kaduk@ZONE.MIT.EDU -r ZONE.MIT.EDU -k \
&gt; -t kaduk-zone.keytab -q &#39;ktadd -k kaduk-zone.keytab kaduk@ZONE.MIT.EDU&#39;
Authenticating as principal kaduk@ZONE.MIT.EDU with keytab kaduk-zone.keytab.
Entry for principal kaduk@ZONE.MIT.EDU with kvno 3, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:kaduk-zone.keytab.
Entry for principal kaduk@ZONE.MIT.EDU with kvno 3, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:kaduk-zone.keytab.
Entry for principal kaduk@ZONE.MIT.EDU with kvno 3, encryption type des3-cbc-sha1 added to keytab WRFILE:kaduk-zone.keytab.
</pre></div>
</div>
<p>Once all principals have been re-keyed, DES support can be disabled on the
KDC (<strong>allow_weak_crypto = false</strong>), and client machines can remove
<strong>allow_weak_crypto = true</strong> from their <a class="reference internal" href="../conf_files/krb5_conf.html#krb5-conf-5"><em>krb5.conf</em></a> configuration
files, completing the migration.  <strong>allow_weak_crypto</strong> takes precedence over
all places where DES enctypes could be explicitly configured.  DES keys will
not be used, even if they are present, when <strong>allow_weak_crypto = false</strong>.</p>
</div>
<div class="section" id="support-for-legacy-services">
<h3>Support for legacy services<a class="headerlink" href="#support-for-legacy-services" title="Permalink to this headline"></a></h3>
<p>If there remain legacy services which do not support non-DES enctypes
(such as older versions of AFS), <strong>allow_weak_crypto</strong> must remain
enabled on the KDC.  Client machines need not have this setting,
though&#8212;applications which require DES can use API calls to allow
weak crypto on a per-request basis, overriding the system krb5.conf.
However, having <strong>allow_weak_crypto</strong> set on the KDC means that any
principals which have a DES key in the database could still use those
keys.  To minimize the use of DES in the realm and restrict it to just
legacy services which require DES, it is necessary to remove all other
DES keys.  The realm has been configured such that at password and
keytab change, no DES keys will be generated by default.  The task
then reduces to requiring user password changes and having server
administrators update their service keytabs.  Administrative outreach
will be necessary, and if the desire to eliminate DES is sufficiently
strong, the KDC administrators may choose to randkey any principals
which have not been rekeyed after some timeout period, forcing the
user to contact the helpdesk for access.</p>
</div>
</div>
<div class="section" id="the-database-master-key">
<h2>The Database Master Key<a class="headerlink" href="#the-database-master-key" title="Permalink to this headline"></a></h2>
<p>This procedure does not alter <tt class="docutils literal"><span class="pre">K/M&#64;REALM</span></tt>, the key used to encrypt key
material in the Kerberos database.  (This is the key stored in the stash file
on the KDC if stash files are used.)  However, the security risk of
a single-DES key for <tt class="docutils literal"><span class="pre">K/M</span></tt> is minimal, given that access to material
encrypted in <tt class="docutils literal"><span class="pre">K/M</span></tt> (the Kerberos database) is generally tightly controlled.
If an attacker can gain access to the encrypted database, they likely
have access to the stash file as well, rendering the weak cryptography
broken by non-cryptographic means.  As such, upgrading <tt class="docutils literal"><span class="pre">K/M</span></tt> to a stronger
encryption type is unlikely to be a high-priority task.</p>
<p>Is is possible to upgrade the master key used for the database, if
desired.  Using <a class="reference internal" href="../admin_commands/kdb5_util.html#kdb5-util-8"><em>kdb5_util</em></a>&#8216;s <strong>add_mkey</strong>, <strong>use_mkey</strong>, and
<strong>update_princ_encryption</strong> commands, a new master key can be added
and activated for use on new key material, and the existing entries
converted to the new master key.</p>
</div>
</div>


          </div>
        </div>
      </div>
        </div>
        <div class="sidebar">
    <h2>On this page</h2>
    <ul>
<li><a class="reference internal" href="#">Retiring DES</a><ul>
<li><a class="reference internal" href="#history">History</a></li>
<li><a class="reference internal" href="#types-of-keys">Types of keys</a></li>
<li><a class="reference internal" href="#upgrade-procedure">Upgrade procedure</a><ul>
<li><a class="reference internal" href="#the-krbtgt-key-and-kdc-keys">The krbtgt key and KDC keys</a></li>
<li><a class="reference internal" href="#adding-strong-keys-to-application-servers">Adding strong keys to application servers</a></li>
<li><a class="reference internal" href="#adding-strong-keys-by-default">Adding strong keys by default</a></li>
<li><a class="reference internal" href="#removing-des-keys-from-usage">Removing DES keys from usage</a></li>
<li><a class="reference internal" href="#support-for-legacy-services">Support for legacy services</a></li>
</ul>
</li>
<li><a class="reference internal" href="#the-database-master-key">The Database Master Key</a></li>
</ul>
</li>
</ul>

    <br/>
    <h2>Table of contents</h2>
    <ul class="current">
<li class="toctree-l1"><a class="reference internal" href="../../user/index.html">For users</a></li>
<li class="toctree-l1 current"><a class="reference internal" href="../index.html">For administrators</a><ul class="current">
<li class="toctree-l2"><a class="reference internal" href="../install.html">Installation guide</a></li>
<li class="toctree-l2"><a class="reference internal" href="../conf_files/index.html">Configuration Files</a></li>
<li class="toctree-l2"><a class="reference internal" href="../realm_config.html">Realm configuration decisions</a></li>
<li class="toctree-l2"><a class="reference internal" href="../database.html">Database administration</a></li>
<li class="toctree-l2"><a class="reference internal" href="../lockout.html">Account lockout</a></li>
<li class="toctree-l2"><a class="reference internal" href="../conf_ldap.html">Configuring Kerberos with OpenLDAP back-end</a></li>
<li class="toctree-l2"><a class="reference internal" href="../appl_servers.html">Application servers</a></li>
<li class="toctree-l2"><a class="reference internal" href="../host_config.html">Host configuration</a></li>
<li class="toctree-l2"><a class="reference internal" href="../backup_host.html">Backups of secure hosts</a></li>
<li class="toctree-l2"><a class="reference internal" href="../pkinit.html">PKINIT configuration</a></li>
<li class="toctree-l2"><a class="reference internal" href="../otp.html">OTP Preauthentication</a></li>
<li class="toctree-l2"><a class="reference internal" href="../princ_dns.html">Principal names and DNS</a></li>
<li class="toctree-l2"><a class="reference internal" href="../enctypes.html">Encryption types</a></li>
<li class="toctree-l2"><a class="reference internal" href="../https.html">HTTPS proxy configuration</a></li>
<li class="toctree-l2"><a class="reference internal" href="../auth_indicator.html">Authentication indicators</a></li>
<li class="toctree-l2"><a class="reference internal" href="../admin_commands/index.html">Administration  programs</a></li>
<li class="toctree-l2"><a class="reference internal" href="../../mitK5defaults.html">MIT Kerberos defaults</a></li>
<li class="toctree-l2"><a class="reference internal" href="../env_variables.html">Environment variables</a></li>
<li class="toctree-l2"><a class="reference internal" href="../troubleshoot.html">Troubleshooting</a></li>
<li class="toctree-l2 current"><a class="reference internal" href="index.html">Advanced topics</a><ul class="current">
<li class="toctree-l3"><a class="reference internal" href="ldapbackend.html">LDAP backend on Ubuntu 10.4 (lucid)</a></li>
<li class="toctree-l3 current"><a class="current reference internal" href="">Retiring DES</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="../various_envs.html">Various links</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="../../appdev/index.html">For application developers</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../plugindev/index.html">For plugin module developers</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../build/index.html">Building Kerberos V5</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../basic/index.html">Kerberos V5 concepts</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../formats/index.html">Protocols and file formats</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../mitK5features.html">MIT Kerberos features</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../build_this.html">How to build this documentation from the source</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../about.html">Contributing to the MIT Kerberos Documentation</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../resources.html">Resources</a></li>
</ul>

    <br/>
    <h4><a href="../../index.html">Full Table of Contents</a></h4>
    <h4>Search</h4>
    <form class="search" action="../../search.html" method="get">
      <input type="text" name="q" size="18" />
      <input type="submit" value="Go" />
      <input type="hidden" name="check_keywords" value="yes" />
      <input type="hidden" name="area" value="default" />
    </form>
        </div>
        <div class="clearer"></div>
      </div>
    </div>

    <div class="footer-wrapper">
        <div class="footer" >
            <div class="right" ><i>Release: 1.16</i><br />
                &copy; <a href="../../copyright.html">Copyright</a> 1985-2017, MIT.
            </div>
            <div class="left">
                
        <a href="../../index.html" title="Full Table of Contents"
            >Contents</a> |
        <a href="ldapbackend.html" title="LDAP backend on Ubuntu 10.4 (lucid)"
            >previous</a> |
        <a href="../various_envs.html" title="Various links"
            >next</a> |
        <a href="../../genindex.html" title="General Index"
            >index</a> |
        <a href="../../search.html" title="Enter search criteria"
            >Search</a> |
    <a href="mailto:krb5-bugs@mit.edu?subject=Documentation__Retiring DES">feedback</a>
            </div>
        </div>
    </div>

  </body>
</html>