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
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- This manual is last updated 4 March 2015 for version
3.5.4 of GnuTLS.
Copyright (C) 2001-2015 Free Software Foundation, Inc.\\
Copyright (C) 2001-2015 Nikos Mavrogiannopoulos
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with no
Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled "GNU Free
Documentation License". -->
<!-- Created by GNU Texinfo 6.1, http://www.gnu.org/software/texinfo/ -->
<head>
<title>GnuTLS 3.5.4: Selecting an appropriate authentication method</title>
<meta name="description" content="GnuTLS 3.5.4: Selecting an appropriate authentication method">
<meta name="keywords" content="GnuTLS 3.5.4: Selecting an appropriate authentication method">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="makeinfo">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link href="index.html#Top" rel="start" title="Top">
<link href="Function-and-Data-Index.html#Function-and-Data-Index" rel="index" title="Function and Data Index">
<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
<link href="Authentication-methods.html#Authentication-methods" rel="up" title="Authentication methods">
<link href="Hardware-security-modules-and-abstract-key-types.html#Hardware-security-modules-and-abstract-key-types" rel="next" title="Hardware security modules and abstract key types">
<link href="Anonymous-authentication.html#Anonymous-authentication" rel="prev" title="Anonymous authentication">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
blockquote.indentedblock {margin-right: 0em}
blockquote.smallindentedblock {margin-right: 0em; font-size: smaller}
blockquote.smallquotation {font-size: smaller}
div.display {margin-left: 3.2em}
div.example {margin-left: 3.2em}
div.lisp {margin-left: 3.2em}
div.smalldisplay {margin-left: 3.2em}
div.smallexample {margin-left: 3.2em}
div.smalllisp {margin-left: 3.2em}
kbd {font-style: oblique}
pre.display {font-family: inherit}
pre.format {font-family: inherit}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
pre.smalldisplay {font-family: inherit; font-size: smaller}
pre.smallexample {font-size: smaller}
pre.smallformat {font-family: inherit; font-size: smaller}
pre.smalllisp {font-size: smaller}
span.nolinebreak {white-space: nowrap}
span.roman {font-family: initial; font-weight: normal}
span.sansserif {font-family: sans-serif; font-weight: normal}
ul.no-bullet {list-style: none}
body {
margin: 2%;
padding: 0 5%;
background: #ffffff;
}
h1,h2,h3,h4,h5 {
font-weight: bold;
padding: 5px 5px 5px 5px;
background-color: #c2e0ff;
color: #336699;
}
h1 {
padding: 2em 2em 2em 5%;
color: white;
background: #336699;
text-align: center;
letter-spacing: 3px;
}
h2 { text-decoration: underline; }
pre {
margin: 0 5%;
padding: 0.5em;
}
pre.example,pre.verbatim {
padding-bottom: 1em;
border: solid #c2e0ff;
background: #f0faff;
border-width: 1px 1px 1px 5px;
margin: 1em auto;
width: 90%;
}
div.node {
margin: 0 -5% 0 -2%;
padding: 0.5em 0.5em;
margin-top: 0.5em;
margin-bottom: 0.5em;
font-weight: bold;
}
dd, li {
padding-top: 0.1em;
padding-bottom: 0.1em;
}
div.float {
margin-bottom: 0.5em;
text-align: center;
}
table {
text-align: left;
margin-left:auto;
margin-right:auto;
border-spacing: 7px;
width: 50%;
}
th {
padding: 0;
color: #336699;
background-color: #c2e0ff;
border: solid #000000;
border-width: 0px;
margin: 1em auto;
text-align: center;
margin-left:auto;
margin-right:auto;
}
td {
padding: 0;
border: solid #000000;
background-color: #f0faff;
border-width: 0px;
margin: 1em auto;
text-align: left;
margin-left:auto;
margin-right:auto;
padding-left: 1em;
}
dl {
text-align: left;
margin-left:auto;
margin-right:auto;
width: 50%;
padding-left: 1em;
border: solid #c2e0ff;
background: #f0faff;
border-width: 5px 1px 1px 1px;
margin: 1em auto;
}
-->
</style>
</head>
<body lang="en">
<a name="Selecting-an-appropriate-authentication-method"></a>
<div class="header">
<p>
Previous: <a href="Shared_002dkey-and-anonymous-authentication.html#Shared_002dkey-and-anonymous-authentication" accesskey="p" rel="prev">Shared-key and anonymous authentication</a>, Up: <a href="Authentication-methods.html#Authentication-methods" accesskey="u" rel="up">Authentication methods</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Function-and-Data-Index.html#Function-and-Data-Index" title="Index" rel="index">Index</a>]</p>
</div>
<hr>
<a name="Selecting-an-appropriate-authentication-method-1"></a>
<h3 class="section">4.4 Selecting an appropriate authentication method</h3>
<p>This section provides some guidance on how to use the available authentication
methods in <acronym>GnuTLS</acronym> in various scenarios.
</p>
<a name="Two-peers-with-an-out_002dof_002dband-channel"></a>
<h4 class="subsection">4.4.1 Two peers with an out-of-band channel</h4>
<p>Let’s consider two peers who need to communicate over an untrusted channel
(the Internet), but have an out-of-band channel available. The latter
channel is considered safe from eavesdropping and message modification and thus
can be used for an initial bootstrapping of the protocol. The options
available are:
</p><ul>
<li> Pre-shared keys (see <a href="PSK-authentication.html#PSK-authentication">PSK authentication</a>). The server and a
client communicate a shared randomly generated key over the trusted
channel and use it to negotiate further sessions over the untrusted channel.
</li><li> Passwords (see <a href="SRP-authentication.html#SRP-authentication">SRP authentication</a>). The client communicates
to the server its username and password of choice and uses it to
negotiate further sessions over the untrusted channel.
</li><li> Public keys (see <a href="Certificate-authentication.html#Certificate-authentication">Certificate authentication</a>). The client
and the server exchange their public keys (or fingerprints of them)
over the trusted channel.
On future sessions over the untrusted channel they verify the key
being the same (similar to <a href="Verifying-a-certificate-using-trust-on-first-use-authentication.html#Verifying-a-certificate-using-trust-on-first-use-authentication">Verifying a certificate using trust on first use authentication</a>).
</li></ul>
<p>Provided that the out-of-band channel is trusted all of the above provide
a similar level of protection. An out-of-band channel may be the initial
bootstrapping of a user’s PC in a corporate environment, in-person
communication, communication over an alternative network (e.g. the phone
network), etc.
</p>
<a name="Two-peers-without-an-out_002dof_002dband-channel"></a>
<h4 class="subsection">4.4.2 Two peers without an out-of-band channel</h4>
<p>When an out-of-band channel is not available a peer cannot be reliably
authenticated. What can be done, however, is to allow some form of
registration of users connecting for the first time and ensure that their
keys remain the same after that initial connection. This is termed
key continuity or trust on first use (TOFU).
</p>
<p>The available option is to use public key authentication (see <a href="Certificate-authentication.html#Certificate-authentication">Certificate authentication</a>).
The client and the server store each other’s public keys (or fingerprints of them)
and associate them with their identity.
On future sessions over the untrusted channel they verify the keys
being the same (see <a href="Verifying-a-certificate-using-trust-on-first-use-authentication.html#Verifying-a-certificate-using-trust-on-first-use-authentication">Verifying a certificate using trust on first use authentication</a>).
</p>
<p>To mitigate the uncertainty of the information exchanged in the first
connection other channels over the Internet may be used, e.g., <acronym>DNSSEC</acronym>
(see <a href="Verifying-a-certificate-using-DANE.html#Verifying-a-certificate-using-DANE">Verifying a certificate using DANE</a>).
</p>
<a name="Two-peers-and-a-trusted-third-party"></a>
<h4 class="subsection">4.4.3 Two peers and a trusted third party</h4>
<p>When a trusted third party is available (or a certificate authority)
the most suitable option is to use
certificate authentication (see <a href="Certificate-authentication.html#Certificate-authentication">Certificate authentication</a>).
The client and the server obtain certificates that associate their identity
and public keys using a digital signature by the trusted party and use
them to on the subsequent communications with each other.
Each party verifies the peer’s certificate using the trusted third party’s
signature. The parameters of the third party’s signature are present
in its certificate which must be available to all communicating parties.
</p>
<p>While the above is the typical authentication method for servers in the
Internet by using the commercial CAs, the users that act as clients in the
protocol rarely possess such certificates. In that case a hybrid method
can be used where the server is authenticated by the client using the
commercial CAs and the client is authenticated based on some information
the client provided over the initial server-authenticated channel. The
available options are:
</p><ul>
<li> Passwords (see <a href="SRP-authentication.html#SRP-authentication">SRP authentication</a>). The client communicates
to the server its username and password of choice on the initial
server-authenticated connection and uses it to negotiate further sessions.
This is possible because the SRP protocol allows for the server to be
authenticated using a certificate and the client using the
password.
</li><li> Public keys (see <a href="Certificate-authentication.html#Certificate-authentication">Certificate authentication</a>). The client
sends its public key to the server (or a fingerprint of it) over the
initial server-authenticated connection.
On future sessions the client verifies the server using the third party
certificate and the server verifies that the client’s public key remained
the same (see <a href="Verifying-a-certificate-using-trust-on-first-use-authentication.html#Verifying-a-certificate-using-trust-on-first-use-authentication">Verifying a certificate using trust on first use authentication</a>).
</li></ul>
<hr>
<div class="header">
<p>
Previous: <a href="Shared_002dkey-and-anonymous-authentication.html#Shared_002dkey-and-anonymous-authentication" accesskey="p" rel="prev">Shared-key and anonymous authentication</a>, Up: <a href="Authentication-methods.html#Authentication-methods" accesskey="u" rel="up">Authentication methods</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Function-and-Data-Index.html#Function-and-Data-Index" title="Index" rel="index">Index</a>]</p>
</div>
</body>
</html>
|
