Kerberos: The Definitive Guide
by Jason Garman

The unconfirmed error reports are from readers.  They have not yet been 
approved or disproved by the author or editor and represent solely the
opinion of the reader.

Here's a key to the markup:
        [page-number]: serious technical mistake
        {page-number}: minor technical mistake
        <page-number>: important language/formatting problem
        (page-number): language change or minor formatting problem
        ?page-number?: reader question or request for clarification

This page was updated July 29, 2008.


UNCONFIRMED  errors and comments from readers: 


{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


(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.


(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"


[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.


[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.


{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.


(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).


{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"