-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathauthentication.html
449 lines (335 loc) · 22.8 KB
/
authentication.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
<!DOCTYPE html>
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>8.4 Authentication Protocols — Computer Networks: A Systems Approach Version 6.1-dev documentation</title>
<link rel="shortcut icon" href="../static/bridge.ico"/>
<script type="text/javascript" src="../static/js/modernizr.min.js"></script>
<script type="text/javascript" id="documentation_options" data-url_root="../" src="../static/documentation_options.js"></script>
<script type="text/javascript" src="../static/jquery.js"></script>
<script type="text/javascript" src="../static/underscore.js"></script>
<script type="text/javascript" src="../static/doctools.js"></script>
<script type="text/javascript" src="../static/language_data.js"></script>
<script async="async" type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.5/latest.js?config=TeX-AMS-MML_HTMLorMML"></script>
<script type="text/javascript" src="../static/js/theme.js"></script>
<link rel="stylesheet" href="../static/css/theme.css" type="text/css" />
<link rel="stylesheet" href="../static/pygments.css" type="text/css" />
<link rel="stylesheet" href="../static/css/rtd_theme_mods.css" type="text/css" />
<link rel="index" title="Index" href="../genindex.html" />
<link rel="search" title="Search" href="../search.html" />
<link rel="next" title="8.5 Example Systems" href="systems.html" />
<link rel="prev" title="8.3 Key Predistribution" href="key-distro.html" />
</head>
<body class="wy-body-for-nav">
<div class="wy-grid-for-nav">
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
<div class="wy-side-scroll">
<div class="wy-side-nav-search" >
<a href="../index.html" class="icon icon-home"> Computer Networks: A Systems Approach
</a>
<div class="version">
Version 6.1-dev
</div>
<div role="search">
<form id="rtd-search-form" class="wy-form" action="../search.html" method="get">
<input type="text" name="q" placeholder="Search docs" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
</div>
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
<p class="caption"><span class="caption-text">Table of Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="../preface.html">Preface</a></li>
<li class="toctree-l1"><a class="reference internal" href="../foundation.html">Chapter 1: Foundation</a></li>
<li class="toctree-l1"><a class="reference internal" href="../direct.html">Chapter 2: Direct Links</a></li>
<li class="toctree-l1"><a class="reference internal" href="../internetworking.html">Chapter 3: Internetworking</a></li>
<li class="toctree-l1"><a class="reference internal" href="../scaling.html">Chapter 4: Advanced Internetworking</a></li>
<li class="toctree-l1"><a class="reference internal" href="../e2e.html">Chapter 5: End-to-End Protocols</a></li>
<li class="toctree-l1"><a class="reference internal" href="../congestion.html">Chapter 6: Congestion Control</a></li>
<li class="toctree-l1"><a class="reference internal" href="../data.html">Chapter 7: End-to-End Data</a></li>
<li class="toctree-l1 current"><a class="reference internal" href="../security.html">Chapter 8: Network Security</a><ul class="current">
<li class="toctree-l2"><a class="reference internal" href="problem.html">Problem: Security Attacks</a></li>
<li class="toctree-l2"><a class="reference internal" href="trust.html">8.1 Trust and Threats</a></li>
<li class="toctree-l2"><a class="reference internal" href="crypto.html">8.2 Cryptographic Building Blocks</a></li>
<li class="toctree-l2"><a class="reference internal" href="key-distro.html">8.3 Key Predistribution</a></li>
<li class="toctree-l2 current"><a class="current reference internal" href="#">8.4 Authentication Protocols</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#originality-and-timeliness-techniques">Originality and Timeliness Techniques</a></li>
<li class="toctree-l3"><a class="reference internal" href="#public-key-authentication-protocols">Public-Key Authentication Protocols</a></li>
<li class="toctree-l3"><a class="reference internal" href="#secret-key-authentication-protocols">Secret-Key Authentication Protocols</a><ul>
<li class="toctree-l4"><a class="reference internal" href="#kerberos">Kerberos</a></li>
</ul>
</li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="systems.html">8.5 Example Systems</a></li>
<li class="toctree-l2"><a class="reference internal" href="trend.html">Perspective: Blockchain and a Decentralized Internet</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="../applications.html">Chapter 9: Applications</a></li>
<li class="toctree-l1"><a class="reference internal" href="../README.html">About This Book</a></li>
</ul>
</div>
</div>
</nav>
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
<nav class="wy-nav-top" aria-label="top navigation">
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
<a href="../index.html">Computer Networks: A Systems Approach</a>
</nav>
<div class="wy-nav-content">
<div class="rst-content">
<div role="navigation" aria-label="breadcrumbs navigation">
<ul class="wy-breadcrumbs">
<li><a href="../index.html">Docs</a> »</li>
<li><a href="../security.html">Chapter 8: Network Security</a> »</li>
<li>8.4 Authentication Protocols</li>
<li class="wy-breadcrumbs-aside">
<a href="../_sources/security/authentication.rst.txt" rel="nofollow"> View page source</a>
</li>
</ul>
<hr/>
</div>
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
<div itemprop="articleBody">
<div class="section" id="authentication-protocols">
<h1>8.4 Authentication Protocols<a class="headerlink" href="#authentication-protocols" title="Permalink to this headline">¶</a></h1>
<p>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.</p>
<p>There are two main reasons why it’s not that simple. First, there is the
problem of a <em>replay attack</em>: 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 <em>originality</em>.</p>
<p>In a variation of this attack called a <em>suppress-replay attack</em>, an
adversary might merely delay your message (by intercepting and later
replaying it), so that it is received at a time when it is no longer
appropriate. For example, an adversary could delay your order to buy
stock from an auspicious time to a time when you would not have wanted
to buy. Although this message would in a sense be the original, it
wouldn’t be timely. So we also need to ensure <em>timeliness</em>. Originality
and timeliness may be considered aspects of integrity. Ensuring them
will in most cases require a nontrivial, back-and-forth protocol.</p>
<p>The second problem we have not yet solved is how to establish a session
key. A session key is a secret-key cipher key generated on the fly and
used for just one session. This too involves a nontrivial protocol.</p>
<p>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.
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
time, so that at the end of the protocol Alice and Bob have
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 <em>authentication protocol</em> and <em>session key
establishment protocol</em> are almost synonymous.</p>
<p>There is a core set of techniques used to ensure originality and
timeliness in authentication protocols. We describe those techniques
before moving on to particular protocols.</p>
<div class="section" id="originality-and-timeliness-techniques">
<h2>Originality and Timeliness Techniques<a class="headerlink" href="#originality-and-timeliness-techniques" title="Permalink to this headline">¶</a></h2>
<p>We have seen that authenticators 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
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
security threats, in addition to the usual challenges of clock
synchronization. Another issue is that distributed clocks are
synchronized to only a certain degree—a certain margin of error. Thus,
the timing integrity provided by timestamps is only as good as the
degree of synchronization.</p>
<p>Another approach is to include a <em>nonce</em>—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.</p>
<p>Another solution to the shortcomings of timestamps and nonces is to
use one or both of them in a <em>challenge-response</em> 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 <a class="reference internal" href="#fig-challenge-response"><span class="std std-numref">Figure 202</span></a>). 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
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
long; any purported response with an unrecognized nonce must be bogus.</p>
<div class="figure align-center" id="id1">
<span id="fig-challenge-response"></span><a class="reference internal image-reference" href="../_images/f08-07-9780123850591.png"><img alt="../_images/f08-07-9780123850591.png" src="../_images/f08-07-9780123850591.png" style="width: 450px;" /></a>
<p class="caption"><span class="caption-number">Figure 202. </span><span class="caption-text">A challenge-response protocol.</span></p>
</div>
<p>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.</p>
</div>
<div class="section" id="public-key-authentication-protocols">
<h2>Public-Key Authentication Protocols<a class="headerlink" href="#public-key-authentication-protocols" title="Permalink to this headline">¶</a></h2>
<p>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.</p>
<div class="figure align-center" id="id2">
<span id="fig-pkauthsync"></span><a class="reference internal image-reference" href="../_images/f08-08-9780123850591.png"><img alt="../_images/f08-08-9780123850591.png" src="../_images/f08-08-9780123850591.png" style="width: 600px;" /></a>
<p class="caption"><span class="caption-number">Figure 203. </span><span class="caption-text">A public-key authentication protocol that depends on synchronization.</span></p>
</div>
<p>This first protocol (<a class="reference internal" href="#fig-pkauthsync"><span class="std std-numref">Figure 203</span></a>) 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.</p>
<p>The second protocol (<a class="reference internal" href="#fig-pkauthnosync"><span class="std std-numref">Figure 204</span></a>) 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.</p>
<div class="figure align-center" id="id3">
<span id="fig-pkauthnosync"></span><a class="reference internal image-reference" href="../_images/f08-09-9780123850591.png"><img alt="../_images/f08-09-9780123850591.png" src="../_images/f08-09-9780123850591.png" style="width: 500px;" /></a>
<p class="caption"><span class="caption-number">Figure 204. </span><span class="caption-text">A public-key authentication protocol that does not depend on
synchronization. Alice checks her own timestamp against her own clock,
and likewise for Bob.</span></p>
</div>
</div>
<div class="section" id="secret-key-authentication-protocols">
<h2>Secret-Key Authentication Protocols<a class="headerlink" href="#secret-key-authentication-protocols" title="Permalink to this headline">¶</a></h2>
<p>Only in fairly small systems is it practical to predistribute secret
keys to every pair of entities. We focus here on larger systems, where
each entity would have its own <em>master key</em> shared only with a Key
Distribution Center (KDC). In this case, secret-key-based authentication
protocols involve three parties: Alice, Bob, and a KDC. The end product
of the authentication protocol is a session key shared between Alice and
Bob that they will use to communicate directly, without involving the
KDC.</p>
<div class="figure align-center" id="id4">
<span id="fig-needhamschroeder"></span><a class="reference internal image-reference" href="../_images/f08-10-9780123850591.png"><img alt="../_images/f08-10-9780123850591.png" src="../_images/f08-10-9780123850591.png" style="width: 500px;" /></a>
<p class="caption"><span class="caption-number">Figure 205. </span><span class="caption-text">The Needham-Schroeder authentication protocol.</span></p>
</div>
<p>The Needham-Schroeder authentication protocol is illustrated in
<a class="reference internal" href="#fig-needhamschroeder"><span class="std std-numref">Figure 205</span></a>. 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
Bob’s master keys to construct a reply that would be useless to anyone
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.</p>
<p>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.</p>
<div class="section" id="kerberos">
<h3>Kerberos<a class="headerlink" href="#kerberos" title="Permalink to this headline">¶</a></h3>
<p>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.</p>
<p>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.</p>
<p>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
reply), and it gives her a sort of secret-key certificate or “ticket”
to present to Bob—the session key and Alice’s identifier, encrypted
with Bob’s master key. In Kerberos, those two functions—and the KDC
itself, in effect—are split up (<a class="reference internal" href="#fig-kerberos"><span class="std std-numref">Figure 206</span></a>). A
trusted server called an Authentication Server (AS) plays the first
KDC role of providing Alice with something she can use to prove her
identity—not to Bob this time, but to a second trusted server called a
Ticket Granting Server (TGS). The TGS plays the second KDC role,
replying to Alice with a ticket she can present to Bob. The attraction
of this scheme is that if Alice needs to communicate with several
servers, not just Bob, then she can get tickets for each of them from
the TGS without going back to the AS.</p>
<div class="figure align-center" id="id5">
<span id="fig-kerberos"></span><a class="reference internal image-reference" href="../_images/f08-11-9780123850591.png"><img alt="../_images/f08-11-9780123850591.png" src="../_images/f08-11-9780123850591.png" style="width: 600px;" /></a>
<p class="caption"><span class="caption-number">Figure 206. </span><span class="caption-text">Kerberos authentication.</span></p>
</div>
<p>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.</p>
</div>
</div>
</div>
</div>
</div>
<footer>
<div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
<a href="systems.html" class="btn btn-neutral float-right" title="8.5 Example Systems" accesskey="n" rel="next">Next <span class="fa fa-arrow-circle-right"></span></a>
<a href="key-distro.html" class="btn btn-neutral float-left" title="8.3 Key Predistribution" accesskey="p" rel="prev"><span class="fa fa-arrow-circle-left"></span> Previous</a>
</div>
<hr/>
<div role="contentinfo">
<p>
© Copyright 2019
</p>
</div>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/rtfd/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
</footer>
</div>
</div>
</section>
</div>
<script type="text/javascript">
jQuery(function () {
SphinxRtdTheme.Navigation.enable(true);
});
</script>
</body>
</html>