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.
| Version |
Location |
Description |
Submitted By |
| 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 |
| 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 |
| Printed |
Page 32
Figure 3-6 |
In the client message "krbgt principal name" should read "krbtgt principal name".
|
Anonymous |
| 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 |
