Errata

Kerberos: The Definitive Guide

Errata for Kerberos: The Definitive Guide

Submit your own errata for this product.

The errata list is a list of errors and their corrections that were found after the product was released.

The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.

Color Key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted by Date submitted
Figure 3-6
Figure 3-6

In Figure 3-6, the principal listed in the AS request is "krbgt". It should have been "krbtgt", as described in the text and as per the response.

NB: I'm in the online version. I can't find the page number in the online version.

 morty_a  Feb 20, 2018 
Part 8
Cross-Realm Authentication, paragraph 6

The page reads "However, direct cross-realm between all of these organizations would require approximately n2 different keys, where n is the number of participating Kerberos realms." The 2 in n2 should be a superscript -- the meaning should be n^2.

 Martin Greenberg  Jan 28, 2019 
Printed Page 16
last paragraph

"(this simple example only provides 1025 possible hash values)"
should read:
"(this simple example only provides 1024 possible hash values)"

as n % 1024 is in 0 .. 1023

 Anonymous   
PDF Page 23
title "Putting the Pieces Together", 2nd paragraph, line 6-7

"instead, my telnet client obtained a service principal from the Ticket Granting Server",
should it be
"instead, my telnet client obtained a service ticket from the Ticket Granting Server" ?

 Anonymous  Aug 19, 2016 
Printed Page 25
Figure 3-1, 3-2, 3-3,etc.

In Figure 3-1 Needham-Schroeder Authentication Request, the "identity of the
application server that [the client] wishes to contact" is represented in the message
as "Service Name". In all diagrams that proceed this, the application server is
represented in messages as "Application Name". This may give confuse the reader.

 Anonymous   
Printed Page 27
Figure 3-3: Ticket box

The caption for the ticket box is:
"Ticket box loaded with application server's key"
should read:
"Ticket box locked with application server's key"

 Anonymous   
Printed Page 29
2nd paragraph

The nonce mentioned in the 4th paragraph of page 26, and shown in Figure 3-2, seems to have nothing to do with the nonce the application server later sends the client to prevent replay attacks (Figure 3-5).

In fact, in their original paper (Communications of the ACM, 21(12), 993) Needham and Schroeder talk about two separate nonces. The first is the one Garman shows in Figs. 3-1 and 3-2. The client sends it to the authentication server, and then checks that it gets it back in the server's reply. N-S state in their paper that is, "in order to verify that the message really is a reply by [authentication server] to the current enquiry." If the nonce is left out, then an intruder could substitute a previously recorded message and trick the client into reusing a previous session key. This first nonce can also help the client map replies to requests, in case it has several requests in transit.

The nonce in Fig. 3-5, and discussed in the 2nd paragraph of p. 29 is the second nonce. Garman describes its function correctly (i.e., his description matches what N-S say in their paper.)

So actually, both nonces foil replay attacks, just at different stages of the authentication: the transaction between the authentication server and the client, and the transaction between the application server and the client.

 Anonymous   
Printed Page 29
Figure 3-5

Communication is wrong way round in Figure 3.5 Needham-Schroeder reply attack
prevention. Previous paragraph states:

"the application server generates ... random number, encrypts it with the session
key, and sends it to the client. Then the client decrypts the number, performs an
operation on it (for example, adding one to it), encrypts the new number with the
session key, and sends the message back to the application server"

Figure 3-5 shows random number (n) being sent from Client to Application server and
random number plus 1 (n+1) being sent from Application server to Client.

 Anonymous   
Printed Page 29
Figure 3-5

the paragraph before the Figure talks about how the application server "force the client to prove to the application server that it is really knows the session key"
however the figure shows the other way around, i.e. the picture inferrs that clients gets a proof that the application server can do n+1.
furthermore, the picture does not show that 'n' and 'n+1' are encrypted (no key near them), which means that anyone that sniffs the network can read and increment this number.

 Anonymous  Jul 27, 2008 
Printed Page 32
Figure 3-6

In the client message "krbgt principal name" should read "krbtgt principal name".

 Anonymous  Oct 24, 2008 
Printed Page 34
figure 3-8

The figure shows the authenticator as being encrypted with the "service's key". I think this should be the session key.

 Anonymous   
Printed Page 41
Figure 3-10

The figure seems to be depicting an AS reply. The purpose of the session key in 9780596004033 5 is to limit the exposure of the user key. Only the session key from the initial AS_REP should be used to encrypt the EncTGSRepPart in the TGS reply (NOT the user key).

 Anonymous   
Printed Page 62
2nd and 3rd paragraph

use qoute when qouting computer response messages.
i.e.
Pgph.1) "Cannot contact any KDC for requested realm.
Pgph.2) "Cannot set GSS-API authentication names"

 Anonymous   
Printed Page 62
2nd and 3rd paragraph

use qoute when qouting computer response messages.
i.e.
Pgph.1) "Cannot contact any KDC for requested realm.
Pgph.2) "Cannot set GSS-API authentication names"

 Anonymous  Jul 28, 2008 
Other Digital Version 1391
2nd Paragraph

You use an encryption in the kdc.conf which is not used with kerberos by default, but not changin the default_tgs_enctype in the krb5.conf

If you change the kdc5.conf to an non-default encryption, you also have to change the krb5.conf, otherwise you get this

# kinit user/admin
kinit: KDC has no support for encryption type while getting initial credentials

Accroding to the man-page default ecnryptions are those

aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4

Used by the book is

des3-hmac-sha1

This way you get just stuck

 Anonymous  Sep 12, 2014