Cryptographic Protocols - Codes: The Guide to Secrecy from Ancient to Modern Times - page 223

(b) Authenticated Di@e-Hellman : In this type of key exchange,
it is mandated that the server certificate contains the DiKe-
Hellman public-keyparameters, authenticated (signed) byTrent
as a CA. If the client is required to send a certificate (see step 3
of stage II, below), then the public-keyparameters as so included
(see step 2 of stage III). Hence, the Di K e-Hellman-generated se-
cret keyis fixed in this case.
(c) Anonymous Di@e-Hellman : Essentiallythe DiKe-Hellman
keyexchange as given on page 166, is used with no authentica-
tion. 5.4
(d) Fortezza : The Key-Exchange Algorithm (KEA) is the keyex-
change algorithm used with Fortezza. KEA was declassified by
the U.S. Department of Defense on June 23, 1998. KEA requires
a 1024-bit prime modulus, generated via the DSS specifications
in [91]. Moreover KEA is based on a DiKe-Hellman protocol
that uses SKIPJACK for the purpose of reduction of final values
to an 80-bit key(see [90]).
(iii) Some randomlygenerated data consisting of a 32-bit timestamp and
28 bits generated bya CSPRNG (see page 151), both of which are
treated as nonces to prevent replayattacks (see page 197).
(iv) List of compression methods supported bythe client.
(v) A variable length session ID.
2. The server sends a server-hello , which consists of the same parameters as
the client-hello. For instance, the server selects a cipher suite from the
list proposed bythe client, and the server chooses a compression method
from the client-proposed list. However, the random field is generated by
the server independent of the client-generated random field.
II Key Exchange and Server Authentication :
1. The server sends an identification certificate to the client (required for all
keyexchanges except anonymous DiKe-Hellman). (If RSA is used, we
assume that the server's public keywas sent with the certificate.)
2. The server sends a server-key-exchange message ( not required onlyif either
the server has sent a certificate with authenticated DiKe-Hellman param-
eters in step 1, or if RSA keyexchange is used). If exercised, this contains
the server's public keying material.
5.4 This means that the SSL handshake protocol supports a totally anonymous operation in
which neither the client nor the server is authenticated. As we saw with the Di)e-Hellman
protocol in particular, and with PKC in general in Section 4.3, impersonation is possible since
the entities are not authenticated, leaving the scheme open to the man-in-the-middle attacks.
We will study a remote login protocol in Chapter 9 (see page 334), called the SSH protocol
that does mandate server authentication.