I 248 H2001

10. forelesning 28.9.2001

• Authentication protocols use elementary authentication functions to establish authentication
• Usages:
• One-way authentication
• Mutual authentication
• Digital signatures

• Key exchange
• Confidentiality
• Requires existing keys (secret or public/private pairs)
• Mechanisms to prevent replays.
• Replay attacks (Gong, 1993):
• Simple replay: Attacker copies messages to be resent later
• Replay that can be logged:  The receiver must accept messages with a timestamp
within some timing window. The attacker can replay messages soon enough for the
messages to arrive within the window.
• Undetectable replay. Original message blocked and does not arrive; only replay message arrives.
May or may not be a threat.
• (Conventional encryption): Backward replay: Message is replayed back to sender.
• Prevention mechanisms:
• Sequence numbers? Would solve the problem, but it may be too complex to maintain
a full history of sequence numbers for every potential connection.
• Challenge/response: A protocol that requires current authentication.
• For example, the receiver can issue a nonce and demand that the message is
accompanied by an encrypted version of the nonce. Requires a connection-oriented type
of communication because of the inherent overhead.
A connectionless communication should rather use....
• Timestamps
• Requires timing window. The length of the window depends on the typical delays in
the network, as well as on the degree of clock synchronization throughout the network.
Clock synchronization over a faulty and delay-prone network is itself a process that
requires a sophisticated protocol.
• Mutual authentication protocols based on conventional encryption:
• By use of a Key Distribution Center
• Needham and Schroeder. (1978)..Fig. 5.9
• Handshake of steps 4&5 is there to prevent a replay attack on  the message in step 3
• Another attack: The attacker
1. has obtained an old session key (Ks),
2. has obtained a copy of the message in number 3, and
3. can intercept (read and stop) message #4 in the protocol.
In this case the attacker can impersonate A.
• Improvement: Timestamps in steps 2 and 3. assumes K_a and K_b safe. (Denning 1982)
1. A -> KDC: ID_A | ID_B
2. KDC -> A: E_Ka(K_s | ID_B | T |  E_Kb(K_s | ID_A | T ) )
3. A -> B:       E_Kb (K_s | ID_A | T )
4. B-> A:        E_Ks (N₁ )
5. A->B:         E _Ks(  f(N₁ ) )
Prevents the mentioned attack, but...
The clocks or the clock synchronization protocol can fail or can be sabotaged.
If sender's clock is ahead of the receiver's clock:
An attacker could intercept a message and replay it later when it is still within the recipient's
allowable time window. (suppress/replay attack....), so, still another protocol...
• (Kehne et. al, 1992, Neuman and Stubblebine, 1993)
1. A -> B:        ID _A | N_a
• A's identifier and A's nonce. Nonce will be returned to A, encrypted, in step 3
(authenticating message 3 and guaranteeing timeliness)
2. B-> KDC:   ID_B | N_b |  E_Kb( ID_A |  N_a | T_b )
• B requests a session key. B's nonce will be returned, in encrypted form, in step 4
(authenticating message 3 and guaranteeing timeliness).
Asks to send a "ticket" to A
3. KDC -> A:  E_Ka((  ID_B   | N_a | K_s | T_b )  |   E_Kb ( ID_A | K_s  |  T_b ) )  | N_b
• KDC sends an encrypted session key & nonce, as well as a ticket, to A
4. A->B:          E_Kb( ID _A | K_s  |  T_b ) )   |  E _Ks( N_b )
• A presents current ticket to B, and the encrypted nonce as proof of timeliness.
  Note that both time stamping and time checking goes on at B, so there is no need for
  clock synchronization.
  
The ticket can be retained by A and used repeatedly to establish a new connection,
as long as the time stamp T_b remains within B's time window, with a simple
challenge/response protocol and without asking the KDC:
 

1. A -> B:        E_Kb ( ID_A | K_s  |  T_b ) )   |  N'_a
• Old ticket; new nonce
2. B-> A:         E _Ks( N'_a ) | N'_b
3. A->B:          E_Ks( N'_b )
• Mutual authentication protocols based on public key encryption:
• Fig. 6.15
What if  A and B do not possess each other's public keys?
• Denning 1981: Use of an Authentication Server (AS)
1. A -> AS:         ID _A | ID_B
2. AS-> A:          E_KRas( ID_A  | KU_a | T )  |   E_KRas( ID_B  | KU_b | T  )
3. A->B:              E_KRas( ID_A  | KU_a | T )  |   E_KRas( ID_B  | KU_b | T  )      |     E_KUb(  E_KRa ( K _s | T  ) )
Requires clock synchronization. Solution without need for  synchronization:
• Woo and Lam, 1992
1. A -> KDC:   ID_A | ID_B
• Initialization request
2. KDC -> A:   E_KRauth(ID_B | KU _b )
• B's certificate.
3. A -> B:         E _KUb(N_a | ID_A )
• Send encrypted nonce & identifier
4. B -> KDC:   ID_B | ID_A | E _KUauth(N_a )
• Request for A's certificate and session key
5. KDC -> B:   E_KRauth(ID_A | KU _a )  |  E_KUb(  E_KRauth(  N_a | K_s | ID_A| ID_B ) )
• A's certificate, and an encrypted and authenticated session key, together with nonce, and

an identifier that ties the nonce to A
6. B -> A:         E _KUa(  E_KRauth(  N_a | K_s | ID_A| ID_B )  |  N_b )
• A receives its own nonce back and knows that this is no replay and that K_s is current
7. A->B:           E_Ks( N_b )
• B gets its encrypted nonce back

• Used when two parties cannot engage in a two-way conversation to establish authentication, e. g. e-mail.
• Note: E-mail is delivered by agent programs (acting on behalf of the users). The agent programs
communicate by use of a connection oriented protocols. However, at the application (or user) level
from the user's point of view, the communicaton is connectionless. This perspective makes sense in
an encryption/authentication context, since all encryption keys should be kept at the user level.
• One-way authentication protocols based on conventional  encryption:
• Fig. 5.11 is impractical since the communication is connectionless
• Fig 5.9, with KDC. Some refinements are necessary:
• We must avoid the dialog of steps 4 and 5:
1. A -> KDC:         ID_A | ID_B | N₁
2. KDC-> A:          E_Ka( K_s | ID_B  | N₁  |   E_Kb(   K_s | ID _A  ) )
3. A->B:                 E_Kb(   K_s | ID_A  )  |  E_Ks(   M  )
Confidentiality and basic authentication. No protection against replays. 
Replay prevention:
• A timestamp could be included, but that makes limited  sense for e-mail messages. 
  However, two messages with the exact same timestamps could be regarded replicas
  with this approach.
• Sequence numbers at the applicaton level? i. e.,
• "Order number 12345: Buy 1000 Kværner shares"
• One-way authentication protocols based on public key  encryption:
• Schemes with authentication, confidentiality, or both, using, respectively,
  digital signatures, encryption or both.
  Will see more of this in Chapter 12.