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
|
<pre>Network Working Group T. Ts'o
Request for Comments: 2942 VA Linux Systems
Category: Standards Track September 2000
<span class="h1">Telnet Authentication: Kerberos Version 5</span>
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This document describes how Kerberos Version 5 [<a href="#ref-1" title=""The Kerberos Network Authentication System (V5)"">1</a>] is used with the
telnet protocol. It describes an telnet authentication suboption to
be used with the telnet authentication option [<a href="#ref-2" title=""Telnet Authentication Option"">2</a>]. This mechanism
can also used to provide keying material to provide data
confidentiality services in conjunction with the telnet encryption
option [<a href="#ref-3" title=""Telnet Data Encryption Option"">3</a>].
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Command Names and Codes</span>
Authentication Types
KERBEROS_V5 2
Sub-option Commands
AUTH 0
REJECT 1
ACCEPT 2
RESPONSE 3
FORWARD 4
FORWARD_ACCEPT 5
FORWARD_REJECT 6
<span class="grey">Ts'o Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2942">RFC 2942</a> Telnet Authentication: Kerberos Version 5 September 2000</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Command Meanings</span>
IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <Kerberos V5
KRB_AP_REQ message> IAC SE
This is used to pass the Kerberos V5 [<a href="#ref-1" title=""The Kerberos Network Authentication System (V5)"">1</a>] KRB_AP_REQ message to the
remote side of the connection. The first octet of the
<authentication-type-pair> value is KERBEROS_V5, to indicate that
Version 5 of Kerberos is being used. The Kerberos V5
authenticator in the KRB_AP_REQ message must contain a Kerberos V5
checksum of the two-byte authentication type pair. This checksum
must be verified by the server to assure that the authentication
type pair was correctly negotiated. The Kerberos V5 authenticator
must also include the optional subkey field, which shall be filled
in with a randomly chosen key. This key shall be used for
encryption purposes if encryption is negotiated, and shall be used
as the negotiated session key (i.e., used as keyid 0) for the
purposes of the telnet encryption option; if the subkey is not
filled in, then the ticket session key will be used instead.
If data confidentiality services is desired the ENCRYPT_US-
ING_TELOPT flag must be set in the authentication-type-pair as
specified in [<a href="#ref-2" title=""Telnet Authentication Option"">2</a>].
IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE
This command indicates that the authentication was successful.
If the AUTH_HOW_MUTUAL bit is set in the second octet of the
authentication-type-pair, the RESPONSE command must be sent before
the ACCEPT command is sent.
IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT
<optional reason for rejection> IAC SE
This command indicates that the authentication was not successful,
and if there is any more data in the sub-option, it is an ASCII
text message of the reason for the rejection.
IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE
<KRB_AP_REP message> IAC SE
This command is used to perform mutual authentication. It is only
used when the AUTH_HOW_MUTUAL bit is set in the second octet of
the authentication-type-pair. After an AUTH command is verified,
a RESPONSE command is sent which contains a Kerberos V5 KRB_AP_REP
message to perform the mutual authentication.
<span class="grey">Ts'o Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2942">RFC 2942</a> Telnet Authentication: Kerberos Version 5 September 2000</span>
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD <KRB_CRED
message> IAC SE
This command is used to forward kerberos credentials for use by
the remote session. The credentials are passed as a Kerberos V5
KRB_CRED message which includes, among other things, the forwarded
Kerberos ticket and a session key associated with the ticket.
Part of the KRB_CRED message is encrypted in the key previously
exchanged for the telnet session by the AUTH suboption.
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_ACCEPT IAC
SE
This command indicates that the credential forwarding was
successful.
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT
<optional reason for rejection> IAC SE
This command indicates that the credential forwarding was not
successful, and if there is any more data in the suboption, it is
an ASCII text message of the reason for the rejection.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Implementation Rules</span>
If the second octet of the authentication-type-pair has the AUTH_WHO
bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial
AUTH command, and the server responds with either ACCEPT or REJECT.
In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the
server will send a RESPONSE before it sends the ACCEPT.
If the second octet of the authentication-type-pair has the AUTH_WHO
bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial
AUTH command, and the client responds with either ACCEPT or REJECT.
In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the
client will send a RESPONSE before it sends the ACCEPT.
The Kerberos principal used by the server will generally be of the
form "host/<hostname>@realm". That is, the first component of the
Kerberos principal is "host"; the second component is the fully
qualified lower-case hostname of the server; and the realm is the
Kerberos realm to which the server belongs.
Any Telnet IAC characters that occur in the KRB_AP_REQ or KRB_AP_REP
messages, the KRB_CRED structure, or the optional rejection text
string must be doubled as specified in [<a href="#ref-4" title=""Telnet Option Specifications"">4</a>]. Otherwise the following
byte might be mis-interpreted as a Telnet command.
<span class="grey">Ts'o Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2942">RFC 2942</a> Telnet Authentication: Kerberos Version 5 September 2000</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Examples</span>
User "joe" may wish to log in as user "pete" on machine "foo". If
"pete" has set things up on "foo" to allow "joe" access to his
account, then the client would send IAC SB AUTHENTICATION NAME "pete"
IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH <KRB_AP_REQ_MESSAGE>
IAC SE
The server would then authenticate the user as "joe" from the
KRB_AP_REQ_MESSAGE, and if the KRB_AP_REQ_MESSAGE was accepted by
Kerberos, and if "pete" has allowed "joe" to use his account, the
server would then continue the authentication sequence by sending a
RESPONSE (to do mutual authentication, if it was requested) followed
by the ACCEPT.
If forwarding has been requested, the client then sends IAC SB
AUTHENTICATION IS KERBEROS_V5 CLIENT|MUTUAL FORWARD <KRB_CRED
structure with credentials to be forwarded> IAC SE. If the server
succeeds in reading the forwarded credentials, the server sends
FORWARD_ACCEPT else, a FORWARD_REJECT is sent back.
Client Server
IAC DO AUTHENTICATION
IAC WILL AUTHENTICATION
[ The server is now free to request authentication information.
]
IAC SB AUTHENTICATION SEND
KERBEROS_V5 CLIENT|MUTUAL
KERBEROS_V5 CLIENT|ONE_WAY IAC
SE
[ The server has requested mutual Version 5 Kerberos
authentication. If mutual authentication is not supported,
then the server is willing to do one-way authentication.
The client will now respond with the name of the user that it
wants to log in as, and the Kerberos ticket. ]
IAC SB AUTHENTICATION NAME
"pete" IAC SE
IAC SB AUTHENTICATION IS
KERBEROS_V5 CLIENT|MUTUAL AUTH
<KRB_AP_REQ message> IAC SE
[ Since mutual authentication is desired, the server sends across
a RESPONSE to prove that it really is the right server. ]
<span class="grey">Ts'o Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2942">RFC 2942</a> Telnet Authentication: Kerberos Version 5 September 2000</span>
IAC SB AUTHENTICATION REPLY
KERBEROS_V5 CLIENT|MUTUAL
RESPONSE <KRB_AP_REP message>
IAC SE
[ The server responds with an ACCEPT command to state that the
authentication was successful. ]
IAC SB AUTHENTICATION REPLY
KERBEROS_V5 CLIENT|MUTUAL ACCEPT
IAC SE
[ If so requested, the client now sends the FORWARD command to
forward credentials to the remote site. ]
IAC SB AUTHENTICATION IS KER-
BEROS_V5 CLIENT|MUTUAL
FORWARD <KRB_CRED message> IAC
SE
[ The server responds with a FORWARD_ACCEPT command to state that
the credential forwarding was successful. ]
IAC SB AUTHENTICATION REPLY
KERBEROS_V5 CLIENT|MUTUAL
FORWARD_ACCEPT IAC SE
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
The selection of the random session key in the Kerberos V5
authenticator is critical, since this key will be used for encrypting
the telnet data stream if encryption is enabled. It is strongly
advised that the random key selection be done using cryptographic
techniques that involve the Kerberos ticket's session key. For
example, using the current time, encrypting it with the ticket
session key, and then correcting for key parity is a strong way to
generate a subsession key, since the ticket session key is assumed to
be never disclosed to an attacker.
Care should be taken before forwarding a user's Kerberos credentials
to the remote server. If the remote server is not trustworthy, this
could result in the user's credentials being compromised. Hence, the
user interface should not forward credentials by default; it would be
far safer to either require the user to explicitly request
credentials forwarding for each connection, or to have a trusted list
of hosts for which credentials forwarding is enabled, but to not
enable credentials forwarding by default for all machines.
<span class="grey">Ts'o Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2942">RFC 2942</a> Telnet Authentication: Kerberos Version 5 September 2000</span>
The IAC SB AUTHENTICATION NAME name IAC SE message is unprotected in
this protocol. Its contents should be verified by a secure method
after authentication completes before it is used.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
The authentication type KERBEROS_V5 and its associated suboption
values are registered with IANA. Any suboption values used to extend
the protocol as described in this document must be registered with
IANA before use. IANA is instructed not to issue new suboption
values without submission of documentation of their use.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgments</span>
This document was originally written by Dave Borman of Cray Research,
Inc. Theodore Ts'o of MIT revised it to reflect the latest
implementation experience. Cliff Neuman and Prasad Upasani of USC's
Information Sciences Institute developed the credential forwarding
support.
In addition, the contributions of the Telnet Working Group are also
gratefully acknowledged.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
[<a id="ref-1">1</a>] Kohl, J. and B. Neuman, "The Kerberos Network Authentication
System (V5)", <a href="./rfc1510">RFC 1510</a>, September 1993.
[<a id="ref-2">2</a>] Ts'o, T. and J. Altman, "Telnet Authentication Option", <a href="./rfc2941">RFC 2941</a>,
September 2000.
[<a id="ref-3">3</a>] Ts'o, T., "Telnet Data Encryption Option", <a href="./rfc2946">RFC 2946</a>, September
2000.
[<a id="ref-4">4</a>] Postel, J. and J. Reynolds, "Telnet Option Specifications", STD
8, <a href="./rfc855">RFC 855</a>, May 1983.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Editor's Address</span>
Theodore Ts'o
VA Linux Systems
43 Pleasant St.
Medford, MA 02155
Phone: (781) 391-3464
EMail: tytso@mit.edu
<span class="grey">Ts'o Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc2942">RFC 2942</a> Telnet Authentication: Kerberos Version 5 September 2000</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ts'o Standards Track [Page 7]
</pre>
|
