Merge pull request #9 from SystemsApproach/auth

minor edit on key distribution; freshen up & expand authentication chapter

Author: llpeterson

authentication.rst

@@ -1,19 +1,21 @@
 Chapter 5:  Authentication Protocols
 =====================================
 
-So far we described how to encrypt messages, build authenticators,
-predistribute the necessary keys. It might seem as if all we have to do
-to make a protocol secure is append an authenticator to every message
-and, if we want confidentiality, encrypt the message.
-
-There are two main reasons why it’s not that simple. First, there is the
-problem of a *replay attack*: an adversary retransmitting a copy of a
-message that was previously sent. If the message was an order you had
-placed on a website, for example, then the replayed message would appear
-to the website as though you had ordered more of the same. Even though
-it wasn’t the original incarnation of the message, its authenticator
-would still be valid; after all, the message was created by you, and it
-wasn’t modified. Clearly, we need a solution that ensures *originality*.
+So far we described how to encrypt messages, build message
+authentication codes, and distribute keys. It might seem
+as if all we have to do to make a protocol secure is append an
+authentication code to every message and, if we want confidentiality,
+encrypt the message.
+
+There are two main reasons why it’s not that simple. First, there is
+the problem of a *replay attack*: an adversary retransmitting a copy
+of a message that was previously sent. One could imagine, for example,
+that a message in which you place an order for some item on a website
+could be replayed, appearing to the website as though you had ordered
+more of the same. Even though it wasn’t the original incarnation of
+the message, its authentication code would still be valid; after all,
+the message was created by you, and it wasn’t modified. Clearly, we
+need a solution that ensures *originality*.
 
 In a variation of this attack called a *suppress-replay attack*, an
 adversary might merely delay your message (by intercepting and later
@@ -31,7 +33,7 @@ used for just one session. This too involves a nontrivial protocol.
 
 What these two issues have in common is authentication. If a message is
 not original and timely, then from a practical standpoint we want to
-consider it as not being authentic, not being from whom it claims to be.
+consider it as not being authentic, i.e., not being from whom it claims to be.
 And, obviously, when you are arranging to share a new session key with
 someone, you want to know you are sharing it with the right person.
 Usually, authentication protocols establish a session key at the same
@@ -40,9 +42,10 @@ authenticated each other and they have a new secret key to use. Without
 a new session key, the protocol would just authenticate Alice and Bob at
 one point in time; a session key allows them to efficiently authenticate
 subsequent messages. Generally, session key establishment protocols
-perform authentication. A notable exception is Diffie-Hellman, as
-described below, so the terms *authentication protocol* and *session key
-establishment protocol* are almost synonymous.
+perform authentication. As we noted in the last chapter,
+Diffie-Hellman key exchange in its simplest form does not provide
+authentication, but in practical usage it is almost always combined
+with an authentication protocol.
 
 There is a core set of techniques used to ensure originality and
 timeliness in authentication protocols. We describe those techniques
@@ -51,10 +54,10 @@ before moving on to particular protocols.
 5.1 Originality and Timeliness Techniques
 -------------------------------------------
 
-We have seen that authenticators alone do not enable us to detect
+We have seen that authentication codes alone do not enable us to detect
 messages that are not original or timely. One approach is to include a
 timestamp in the message. Obviously the timestamp itself must be
-tamperproof, so it must be covered by the authenticator. The primary
+tamperproof, so it must be covered by the message authentication code. The primary
 drawback to timestamps is that they require distributed clock
 synchronization. Since our system would then depend on synchronization,
 the clock synchronization itself would need to be defended against
@@ -66,23 +69,20 @@ degree of synchronization.
 
 Another approach is to include a *nonce*—a random number used only
 once—in the message. Participants can then detect replay attacks by
-checking whether a nonce has been used previously. Unfortunately, this
-requires keeping track of past nonces, of which a great many could
-accumulate. One solution is to combine the use of timestamps and nonces,
-so that nonces are required to be unique only within a certain span of
-time. That makes ensuring uniqueness of nonces manageable while
-requiring only loose synchronization of clocks.
-
-Another solution to the shortcomings of timestamps and nonces is to
-use one or both of them in a *challenge-response* protocol. Suppose we
-use a timestamp. In a challenge-response protocol, Alice sends Bob a
+checking whether a nonce has been used previously. On its own, this
+would require keeping track of past nonces, of which a great many could
+accumulate.
+
+A solution to the shortcomings of timestamps and nonces is to use one
+or both of them in a *challenge-response* protocol. Suppose we use a
+timestamp. In a challenge-response protocol, Alice sends Bob a
 timestamp, challenging Bob to encrypt it in a response message (if
 they share a secret key) or digitally sign it in a response message
 (if Bob has a public key, as in :numref:`Figure %s
 <fig-challenge-response>`). The encrypted timestamp is like an
-authenticator that additionally proves timeliness. Alice can easily
-check the timeliness of the timestamp in a response from Bob since
-that timestamp comes from Alice’s own clock—no distributed clock
+authentication code that additionally proves timeliness. Alice can
+easily check the timeliness of the timestamp in a response from Bob
+since that timestamp comes from Alice’s own clock—no distributed clock
 synchronization needed. Suppose instead that the protocol uses
 nonces. Then Alice need only keep track of those nonces for which
 responses are currently outstanding and haven’t been outstanding too
@@ -95,64 +95,50 @@ long; any purported response with an unrecognized nonce must be bogus.
 
    A challenge-response protocol.
 
-The beauty of challenge-response, which might otherwise seem excessively
-complex, is that it combines timeliness and authentication; after all,
-only Bob (and possibly Alice, if it’s a secret-key cipher) knows the key
-necessary to encrypt the never before seen timestamp or nonce.
-Timestamps or nonces are used in most of the authentication protocols
-that follow.
+The beauty of challenge-response is that it combines timeliness and
+authentication; after all, only Bob (and possibly Alice, if it’s a
+secret-key cipher) knows the key necessary to encrypt the
+never-before-seen timestamp or nonce.  Timestamps or nonces are used
+in most of the authentication protocols that follow.
 
 5.2 Public-Key Authentication Protocols
 -----------------------------------------
 
-In the following discussion, we assume that Alice and Bob’s public keys
-have been predistributed to each other via some means such as a PKI. We
-mean this to include the case where Alice includes her certificate in
-her first message to Bob, and the case where Bob searches for a
-certificate about Alice when he receives her first message.
 
-.. _fig-pKAuthSync:
-.. figure:: figures/f08-08-9780123850591.png
-   :width: 600px
-   :align: center
 
-   A public-key authentication protocol that depends on synchronization.
-
-This first protocol (:numref:`Figure %s <fig-pKAuthSync>`) relies on
-Alice and Bob’s clocks being synchronized. Alice sends Bob a message
-with a timestamp and her identity in plaintext plus her digital
-signature. Bob uses the digital signature to authenticate the message
-and the timestamp to verify its freshness. Bob sends back a message
-with a timestamp and his identity in plaintext, as well as a new
-session key encrypted (for confidentiality) using Alice’s public key,
-all digitally signed. Alice can verify the authenticity and freshness
-of the message, so she knows she can trust the new session key. To
-deal with imperfect clock synchronization, the timestamps could be
-augmented with nonces.
-
-The second protocol (:numref:`Figure %s <fig-pKAuthNoSync>`) is
-similar but does not rely on clock synchronization. In this protocol,
-Alice again sends Bob a digitally signed message with a timestamp and
-her identity.  Because their clocks aren’t synchronized, Bob cannot be
-sure that the message is fresh. Bob sends back a digitally signed
-message with Alice’s original timestamp, his own new timestamp, and
-his identity. Alice can verify the freshness of Bob’s reply by
-comparing her current time against the timestamp that originated with
-her. She then sends Bob a digitally signed message with his original
-timestamp and a new session key encrypted using Bob’s public key. Bob
-can verify the freshness of the message because the timestamp came
-from his clock, so he knows he can trust the new session key. The
-timestamps essentially serve as convenient nonces, and indeed this
-protocol could use nonces instead.
+In the following discussion, we assume that Alice and Bob’s public
+keys have been predistributed to each other via some means as
+described in the previous chapter. This could include the case where
+Alice includes her certificate in her first message to Bob, and the
+case where Bob searches some sort of public key infrastructure for a
+certificate about Alice when he receives her first message.
+
+We describe here a simple authentication protocol that uses
+timestamps, illustrated in :numref:`Figure %s <fig-pKAuthNoSync>`. In
+this protocol, Alice sends Bob a digitally signed message with a
+timestamp from her local clock and her identity.  Because their clocks
+aren’t synchronized, Bob cannot be sure that the message is fresh. Bob
+sends back a digitally signed message with Alice’s original timestamp,
+his own locally generated timestamp, and his identity. Alice can verify the
+freshness of Bob’s reply by comparing her current time against the
+timestamp that originated with her. She then sends Bob a digitally
+signed message with his original timestamp and a new session key
+encrypted using Bob’s public key. Bob can verify the freshness of the
+message because the timestamp came from his clock, so he knows he can
+trust the new session key.
+
+The timestamps in this example essentially serve as convenient nonces, and indeed this
+protocol could use nonces instead. We will see some examples of this
+when we look at Transport Layer Security (TLS) in a later chapter.
 
 .. _fig-pKAuthNoSync:
 .. figure:: figures/f08-09-9780123850591.png
    :width: 500px
    :align: center
 
-   A public-key authentication protocol that does not depend on
-   synchronization. Alice checks her own timestamp against her own clock,
-   and likewise for Bob.
+   A public-key authentication protocol. Alice checks her own
+   timestamp, signed by Bob, against her own clock,
+   and Bob does the same with his timestamp signed by Alice.
 
 
 5.3 Secret-Key Authentication Protocols
@@ -174,7 +160,8 @@ KDC.
 
    The Needham-Schroeder authentication protocol.
 
-The Needham-Schroeder authentication protocol is illustrated in
+The Needham-Schroeder authentication protocol formed the basis for
+many future authentication systems, and is illustrated in
 :numref:`Figure %s <fig-needhamSchroeder>`. Note that the KDC doesn’t
 actually authenticate Alice’s initial message and doesn’t communicate
 with Bob at all. Instead, the KDC uses its knowledge of Alice’s and
@@ -183,39 +170,51 @@ other than Alice (because only Alice can decrypt it) and contains the
 necessary ingredients for Alice and Bob to perform the rest of the
 authentication protocol themselves.
 
-The nonce in the first two messages is to assure Alice that the KDC’s
-reply is fresh. The second and third messages include the new session
-key and Alice’s identifier, encrypted together using Bob’s master key.
-It is a sort of secret-key version of a public-key certificate; it is in
-effect a signed statement by the KDC (because the KDC is the only entity
-besides Bob who knows Bob’s master key) that the enclosed session key is
-owned by Alice and Bob. Although the nonce in the last two messages is
-intended to assure Bob that the third message was fresh, there is a flaw
-in this reasoning.
+The process begins with Alice sending a message to the KDC that
+includes a nonce and the names of the two principals, A(lice) and
+B(ob). The KDC responds by creating a new session key, encrypting that
+with the key that the KDC shares with Bob (indicated by the small,
+inner envelope), and including that in a message sent back to Alice.
+This message is in turn encrypted using the key that is shared by the
+KDC and Alice (as indicated by the outer envelope). Thus, only Alice
+can decrypt this message, and now she has both the unencrypted session
+key and an encrypted copy of the session key to send to Bob. On receiving
+the message from Alice, Bob is able to decrypt it and obtain the
+session key. He now creates another nonce and encrypts it with the
+session key and replies to Alice. Finally, Alice decrypts the nonce,
+increments it, and replies to Bob with the encrypted result, proving
+that she has seen the nonce.  Although the nonce created by Bob and
+used in the last two messages shows that the final message from Alice
+is fresh, it does not guarantee freshness of the initial message Bob
+received from Alice at step 3. Kerberos addresses this shortcoming.
 
 5.3.1 Kerberos
 ~~~~~~~~~~~~~~~~
 
 Kerberos is an authentication system based on the Needham-Schroeder
 protocol and specialized for client/server environments. Originally
 developed at MIT, it has been standardized by the IETF and is available
-as both open source and commercial products. We will focus here on some
-of Kerberos’s interesting innovations.
+as both open source and commercial products. We focus here on some
+of Kerberos’s interesting innovations. Notably, it addresses the
+freshness problem identified in Needham-Schroeder by using timestamps
+rather than nonces.
 
 Kerberos clients are generally human users, and users authenticate
-themselves using passwords. Alice’s master key, shared with the KDC, is
-derived from her password—if you know the password, you can compute the
-key. Kerberos assumes anyone can physically access any client machine;
-therefore, it is important to minimize the exposure of Alice’s password
-or master key not just in the network but also on any machine where she
-logs in. Kerberos takes advantage of Needham-Schroeder to accomplish
-this. In Needham-Schroeder, the only time Alice needs to use her
-password is when decrypting the reply from the KDC. Kerberos client-side
-software waits until the KDC’s reply arrives, prompts Alice to enter her
-password, computes the master key and decrypts the KDC’s reply, and then
-erases all information about the password and master key to minimize its
-exposure. Also note that the only sign a user sees of Kerberos is when
-the user is prompted for a password.
+themselves using passwords. Alice’s master key, shared with the KDC,
+is derived from her password—if you know the password, you can compute
+the key. Kerberos assumes anyone can physically access any client
+machine; therefore, it is important to minimize the exposure of
+Alice’s password or master key not just in the network but also on any
+machine where she logs in. Kerberos takes advantage of an approach
+derived from Needham-Schroeder to accomplish this. In
+Needham-Schroeder, the only time Alice needs to use her password to
+access her master key is when decrypting the reply from the
+KDC. Kerberos client-side software waits until the KDC’s reply
+arrives, prompts Alice to enter her password, computes the master key
+and decrypts the KDC’s reply, and then erases all information about
+the password and master key to minimize its exposure. Also note that
+the only sign a user sees of Kerberos is when the user is prompted for
+a password.
 
 In Needham-Schroeder, the KDC’s reply to Alice plays two roles: It
 gives her the means to prove her identity (only Alice can decrypt the
@@ -239,10 +238,25 @@ the TGS without going back to the AS.
 
    Kerberos authentication.
 
-In the client/server application domain for which Kerberos is intended,
-it is reasonable to assume a degree of clock synchronization. This
-allows Kerberos to use timestamps and lifespans instead of
-Needham-Shroeder’s nonces, and thereby eliminate the Needham-Schroeder
-security weakness. Kerberos supports a choice of hash functions and
-secret-key ciphers, allowing it to keep pace with the state-of-the-art
-in cryptographic algorithms.
+Once Alice has received the ticket from the AS, she is able to
+communicate with the TGS. She provides the ticket, the identifier for
+Bob, and an encrypted timestamp (in place of the nonce used in
+Needham-Schroeder). The TGS replies with a ticket that will be
+readable by Bob, because it is encrypted with his master key, and a
+session key that is encrypted using the key shared by Alice and the
+TGS. Alice can now start communicating with Bob, sending the ticket
+and another encrypted timestamp using the newly provided session key.
+
+In the client/server application domain for which Kerberos is
+intended, it is reasonable to assume a degree of clock
+synchronization. This allows Kerberos to use timestamps and lifespans
+instead of Needham-Shroeder’s nonces. This means that the TGS and Bob
+can both be assured that the messages that came from Alice are fresh
+and not replays, thereby eliminating the Needham-Schroeder security
+weakness noted above. The freshness of Bob's reply to Alice is assured
+because it is a response to the challenge from Alice.
+
+Kerberos has undergone considerable development and standardization over
+the decades. It supports a choice of hash functions and secret-key
+ciphers, which has allowed it to evolve along with the standards for
+cryptographic algorithms.

crypto.rst

@@ -632,6 +632,17 @@ authenticated. We won't go into details here, but there is now a set of
 integrated algorithms that produce both ciphertext and authentication
 codes using a combination of ciphers and hash functions.
 
+If you want to get a deeper understanding of the principles of ciphers
+and hash functions, among other cryptographic concepts, we recommend the following book.
+
+.. admonition:: Further Reading
+
+   A. Menezes, P. van Oorschot, and S. Vanstone. `Handbook of Applied
+   Cryptography <https://cacr.uwaterloo.ca/hac/>`__. CRC Press, 1996.
+
+
+
+
 Now that we have seen some of the building blocks for encryption and
 authentication, we have the foundations for building some complete security
 solutions. Before we get to those, however, we address the issue of how participants

key-distro.rst

@@ -477,12 +477,12 @@ A further variant of Diffie-Hellman, which is used in TLS, is called
 *ephemeral* Diffie-Hellman. Like the fixed variant, it relies on at
 least one participant having a certificate issued by a CA, but in this
 case it certifies that Alice is associated with a given public key
-(e.g., an RSA key). Alice then generates an ephemeral value of $a$
+(e.g., an RSA key). Alice then generates an ephemeral value of *a*
 rather than a fixed one, and uses her private key to sign the Diffie
 Hellman parameters: *p, g*, and :math:`g^a \bmod p`. By providing the
 certificate and the signed value, Alice is able to show Bob that the
 message has really come from her and authenticate the Diffie-Hellman
-parameters, while still keeping $a$ secret. Unlike fixed
+parameters, while still keeping *a* secret. Unlike fixed
 Diffie-Hellman, this approach provides *forward secrecy*, meaning that
 even if the long-lived private key of Alice were to be compromised,
 past sessions that had been recorded by an attacker will still be