1
2
3Network Working Group                                       S. Josefsson
4Internet-Draft                                          February 2, 2003
5Expires: August 3, 2003
6
7
8                      A Kerberos 5 SASL Mechanism
9                   draft-josefsson-sasl-kerberos5-01
10
11Status of this Memo
12
13   This document is an Internet-Draft and is in full conformance with
14   all provisions of Section 10 of RFC2026.
15
16   Internet-Drafts are working documents of the Internet Engineering
17   Task Force (IETF), its areas, and its working groups.  Note that
18   other groups may also distribute working documents as
19   Internet-Drafts.
20
21   Internet-Drafts are draft documents valid for a maximum of six months
22   and may be updated, replaced, or obsoleted by other documents at any
23   time.  It is inappropriate to use Internet-Drafts as reference
24   material or to cite them other than as "work in progress."
25
26   The list of current Internet-Drafts can be accessed at http://
27   www.ietf.org/ietf/1id-abstracts.txt.
28
29   The list of Internet-Draft Shadow Directories can be accessed at
30   http://www.ietf.org/shadow.html.
31
32   This Internet-Draft will expire on August 3, 2003.
33
34Copyright Notice
35
36   Copyright (C) The Internet Society (2003).  All Rights Reserved.
37
38Abstract
39
40   This document specifies a Simple Authentication and Security Layer
41   (SASL) [3] mechanism for Kerberos 5 Client/Server Authentication [1],
42   with optional initial Authentication Service (AS) and/or
43   Ticket-Granting-Service (TGS) exchanges.
44
45
46
47
48
49
50
51
52
53
54
55Josefsson                Expires August 3, 2003                 [Page 1]
56
57Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
58
59
60Table of Contents
61
62   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
63   2.  Document Changes . . . . . . . . . . . . . . . . . . . . . . .  3
64   3.  Kerberos Version 5 Mechanism . . . . . . . . . . . . . . . . .  3
65   4.  Theory Of Operation  . . . . . . . . . . . . . . . . . . . . .  6
66   4.1 Infrastructure Mode  . . . . . . . . . . . . . . . . . . . . .  6
67   4.2 Proxied Infrastructure Mode  . . . . . . . . . . . . . . . . .  6
68   4.3 Non-Infrastructure Mode  . . . . . . . . . . . . . . . . . . .  7
69   5.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
70   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
71       Normative References . . . . . . . . . . . . . . . . . . . . . 17
72       Informative References . . . . . . . . . . . . . . . . . . . . 17
73       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
74       Intellectual Property and Copyright Statements . . . . . . . . 19
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
111Josefsson                Expires August 3, 2003                 [Page 2]
112
113Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
114
115
1161. Introduction
117
118   Kerberos 5 provides client and optional server authentication,
119   usually employing symmetric encryption and a trusted (symmetric) key
120   distribution center.  Specifying Kerberos 5 authentication for each
121   network protocol where there is a need to use Kerberos 5 is a tedious
122   task.  However, as many protocols already specify support for the
123   SASL framework, by specifying a Kerberos 5 SASL mechanism, support
124   for Kerberos 5 in many protocols is accomplished.  Even for protocols
125   that do not support SASL, specifying SASL support (and thereby
126   implicitly Kerberos 5) is often advantageous over specifying Kerberos
127   5 support directly.  The advantages include better flexibility if or
128   when new Kerberos versions are released, and perhaps more commonly,
129   when circumstances demand that other authentication methods
130   (supported by SASL) should be used.
131
132   It should be mentioned that Kerberos 5 authentication via SASL is
133   already possible, by using the Generic Security Service Application
134   Program Interface [6] framework.  However, GSSAPI adds some amount of
135   overhead, both in terms of code complexity, code size and additional
136   network round trips.  More importantly, GSSAPI do not support the
137   authentication steps (AS and TGS).  These are some of the motivation
138   behind this "slimmer" Kerberos 5 SASL mechanism.
139
1402. Document Changes
141
142   Modification since -00:
143
144   * The way data is encoded in the
145     AP-REQ.Authenticator.authorization-data field is corrected and
146     elaborated.
147
148   * The incorrect sentence about including application data in the
149     AP-REP is removed.
150
151   * The "Theory of operation" section now includes three modes;
152     Infrastructure, Proxied Infrastructure, and Non-Infrastructure
153     modes.
154
155   * The example section now contains a complete dump from an
156     implementation.
157
158
1593. Kerberos Version 5 Mechanism
160
161   The mechanism name associated with Kerberos version 5 is
162   "KERBEROS_V5".  The exchange consists of one initial server packet
163   (containing some parameters and a challenge, described below), and
164
165
166
167Josefsson                Expires August 3, 2003                 [Page 3]
168
169Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
170
171
172   then an unfixed number of messages containing Kerberos 5 packets,
173   with the last exchange being an AP-REQ, and optional AP-REP, for the
174   desired SASL service on a format described below.
175
176   The normal packet exchange, after the required initial server packet,
177   are one optional AS-REQ and AS-REP exchange, one optional TGS-REQ and
178   TGS-REP exchange and then the AP-REQ packet and optional AP-REP
179   reply.  The only steps that are required by this SASL mechanism is
180   the initial server packet and the final AP-REQ and optional AP-REP
181   exchange.  The AP-REP is sent when and only when mutual
182   authentication is required.  The AP-REQ is for the SASL service that
183   is requested.  The AP-REQ must contain authenticated application data
184   on a format described below.  The AS and TGS exchanges is usually
185   used by clients to acquire the proper tickets required for the AP
186   phase.  It is not expected that any other Kerberos 5 packets will be
187   exchanged, but this mechanism do not disallow such packets in order
188   to make it possible to use this SASL mechanism with future Kerberos
189   extensions.
190
191   As discussed above, the client is allowed to send any valid Kerberos
192   5 message and the server should handle any message, subject to local
193   policy restrictions.  If the server do not understand the meaning of
194   a packet or do not wish to respond to it (e.g., it cannot proxy a
195   TGS-REQ), it SHOULD respond with a empty response and await further
196   packets.  Reasons for aborting the authentication phase instead of
197   sending an empty response includes if the number of received packets
198   exceeds a pre-defined limit.  AS-REQ and TGS-REQ packets destined for
199   non-local Kerberos Key Distribution Centers (KDCs) is proxied to the
200   correct server by the SASL server.  No provisions are made in the
201   protocol to allow the client to specify the addresses of the KDCs,
202   instead the SASL server is required to discover this information
203   (usually by static configuration or by using DNS).  It is legitimate
204   for the SASL server to abort the authentication phase with an error
205   saying that the indicated realm was not found or is restricted by
206   policy (i.e., a policy that only permits local KDC requests is
207   permitted).
208
209   Since it is expected that clients may not yet have IP addresses when
210   they invoke this SASL mechanism (invoking this mechanism may be one
211   step in acquiring an IP address), clients commonly leave the address
212   fields in the AS-REQ empty.
213
214   The initial server packet should contain one octet containing a bit
215   mask of supported security layers, four octets indicating the maximum
216   cipher-text buffer size the server is able to receive (or 0 if no
217   security layers are supported) in network byte order, and then 16
218   octets containing random data (see [4] on how random data might be
219   generated).
220
221
222
223Josefsson                Expires August 3, 2003                 [Page 4]
224
225Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
226
227
228   The last exchange must be an AP-REQ for the desired SASL service,
229   optionally followed by an AP-REP.  The SASL service is translated
230   into a Kerberos principal and realm as follows: The first element of
231   the principal is the service name specified in the protocol that uses
232   SASL.  The second element is the address of the SASL server, usually
233   expressed as a hostname.  The SASL realm should be the Kerberos realm
234   of the server.  The checksum value in the "cksum" field in the
235   Authenticator in the AP-REQ is computed on a string where the first
236   octet indicate the desired security layer requested by the client (a
237   bitmask with one bit set, which must also be set in the security
238   layer bitmask offered by the server), the next four octets indicate
239   the maximum cipher-text buffer size the client is able to receive in
240   network byte order (or 0 if a security layer is not indicated by the
241   first octet), followed by the entire initial server packet, in turn
242   followed by the desired authorization identity (which can be empty to
243   indicate that the authorization identity should be the same as the
244   authentication identity in the Kerberos ticket stored in the AP-REQ).
245   This same string is also to be included in the authorization-data
246   field of the Authenticator, with an ad-type of -1.
247
248   Upon decrypting and verifying the ticket and authenticator (i.e.,
249   standard AP-REQ processing), the server extracts the
250   authorization-data value from the Authenticator and checks that the
251   checksum in the authenticator is correct.  It then proceeds to check
252   that the server security layer bit mask, server maximum cipher-text
253   buffer size, and the random data equals the data provided in the
254   initial server challenge.  The server verify that the client selected
255   a security layer that was offered, and that the client maximum buffer
256   is 0 if no security layer was chosen.  The server must also verify
257   that the principal identified in the Kerberos ticket is authorized to
258   connect to the service as the authorization identity specified by the
259   client (or, if absent, the username denoted by the ticket principal).
260   Unless the client requested mutual authentication, the authentication
261   process is complete.
262
263   If the client requested mutual authentication, the server constructs
264   an AP-REP according to Kerberos 5.
265
266   The security layers and their corresponding bit-masks are as follows:
267
268         Bit 0 No security layer
269         Bit 1 Integrity (KRB-SAFE) protection
270         Bit 2 Privacy (KRB-PRIV) protection
271         Bit 3 Mutual authentication is required (AP option MUTUAL-
272               REQUIRED must also be present).
273
274   Other bit-masks may be defined in the future; bits which are not
275   understood must be negotiated off.
276
277
278
279Josefsson                Expires August 3, 2003                 [Page 5]
280
281Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
282
283
2844. Theory Of Operation
285
286   This section describes, for illustration only, three common scenarios
287   where this mechanism can be used.
288
2894.1 Infrastructure Mode
290
291   Normally a SASL server is an application server such as a mail
292   system.  The server is configured to belong to at least one Kerberos
293   5 realm, and the server shares a symmetric key with the Kerberos 5
294   Key Distribution Center in that realm.  The server cannot perform the
295   initial Kerberos AS and TGS operation itself, but a KDC is needed for
296   that operation.  Once the user acquired credentials the server is
297   able to carry out the AP-REQ/AP-REP phase using its symmetric key.
298   The steps are as follows:
299
300   0) Server sends initial token.
301
302   * Client acquires a ticket for the server using an out-of-band request
303     to the KDC. Client generates the AP-REQ using the ticket for the
304     server.
305
306   1) Client sends AP-REQ to the server.
307
308   * Server parses AP-REQ, and if required the AP-REP is generated.
309
310   2) [Optional] Server sends AP-REP to the client.
311
312   * [Optional] Client parses AP-REP.
313
314   As can be seen, round-trip wise this is optimal, possibly bar the
315   initial token, although in IMAP it does not cause an additional
316   round-trip, and other protocols may be similar.
317
3184.2 Proxied Infrastructure Mode
319
320   If the client for some reason cannot carry out the communication with
321   the KDC itself, or for some other reason the server is in a better
322   position than the client to communicate with the KDC, the server can
323   proxy that part of the exchange via the server using the SASL
324   framework.  The server effectively acts as a proxy.  Note that the
325   packets that are sent are identical to those in the first example,
326   they are only routed differently.  The steps are as follows:
327
328
329
330
331
332
333
334
335Josefsson                Expires August 3, 2003                 [Page 6]
336
337Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
338
339
340   0) Server sends initial token.
341
342   * Client constructs AS-REQ using username and realm supplied by user,
343     in order to acquire a ticket granting ticket.
344
345   1) Client sends AS-REQ to server.
346
347   * Server finds address of KDC and forwards the AS-REQ to and waits for
348     the AS-REP response from the KDC.
349
350   2) Server sends AS-REP to client.
351
352   * Client parses AS-REP and constructs a TGS-REQ using the ticket
353     granting ticket encryption key, in order to acquire a ticket for the
354     server.
355
356   3) Client sends TGS-REQ to server.
357
358   * Server finds address of KDC and forwards the TGS-REQ to and waits
359     for the TGS-REP response from the KDC.
360
361   4) Server sends TGS-REP to client.
362
363   * Client parses TGS-REP and generates the AP-REQ using the session
364     encryption key.
365
366   5) Client sends AP-REQ to server.
367
368   * Server parses AP-REQ and if required the AP-REP is generated.
369
370   6) [Optional] Server sends AP-REP.
371
372   * [Optional] Client parses AP-REP.
373
374   If efficiency as a concern, and the client have no other use of a
375   ticket granting ticket for the realm, step 3 and 4 can be skipped by
376   asking for a ticket for the server directly in the AS-REQ.
377
378   Note that the client in subsequent connections may try to re-use the
379   ticket negotiated if it is still valid.
380
3814.3 Non-Infrastructure Mode
382
383   Kerberos 5 is usually a distributed security system, but we wish to
384   point out that this Kerberos 5 SASL mechanism may be used in a
385   standalone SASL server to provide the security advantages that the
386   Kerberos 5 Authentication Service (AS) provides over other methods.
387
388
389
390
391Josefsson                Expires August 3, 2003                 [Page 7]
392
393Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
394
395
396   Specifically, the SASL server may use a legacy password database such
397   as a CRAM-MD5 clear text password file to generate Kerberos 5
398   principals "on the fly".  Authentication may thus proceed as follows:
399
400   0) Server sends initial token.
401
402   * Client constructs AS-REQ using username supplied by user, in order
403     to acquire a ticket for the server directly.  The realm can be
404     predetermined by administrators, or simply the hostname of the
405     server.
406
407   1) Client sends AS-REQ to server.
408
409   * Server parses AS-REQ and generates AS-REP based on password in
410     database. The AS-REQ embeds a ticket for the server.
411
412   2) Server sends AS-REP to client.
413
414   * Client parses AS-REP and extracts the ticket and generates an AP-REQ
415     using the session encryption key.
416
417   3) Client sends AP-REQ to server.
418
419   * Server parses AP-REQ and if required, generates the AP-REP.
420
421   4) [Optional] Server sends AP-REP to client.
422
423   * [Optional] Client parses AP-REP.
424
425   This may be extended further, i.e.  by using the password and
426   Kerberos 5 pre-authentication in step 1.
427
428   Note that the client in subsequent connections may try to re-use the
429   ticket negotiated if it is still valid.
430
4315. Example
432
433   The following is one Kerberos version 5 login scenario for the IMAP4
434   protocol, in the non-infrastructure mode.  Note that the line breaks
435   are for editorial clarity.
436
437
438
439
440
441
442
443
444
445
446
447Josefsson                Expires August 3, 2003                 [Page 8]
448
449Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
450
451
452        S: * OK IMAP4rev1 server
453        C: . AUTHENTICATE KERBEROS_V5
454        S: + CQAAAADp6+ONC2vcprRbmH2J95Gh
455        C: an4wfKEDAgEFogMCAQqkcDBuoAcDBQAAAAAAoRAwDqADAgEAoQcwBRsDamFzog
456           sbCWxvY2FsaG9zdKMcMBqgAwIBAKETMBEbBGltYXAbCWxvY2FsaG9zdKURGA8y
457           MDAzMDIwMjE2NDE0M1qnBgIEVAbYn6gLMAkCARECARACAQM=
458        S: + a4IBzDCCAcigAwIBBaEDAgELowsbCWxvY2FsaG9zdKQQMA6gAwIBAKEHMAUb
459           A2phc6WB5GGB4TCB3qADAgEFoQsbCWxvY2FsaG9zdKIcMBqgAwIBAaETMBEbBG
460           ltYXAbCWxvY2FsaG9zdKOBqzCBqKADAgESooGgBIGdeBv2/NG1EgTMMMcHaVY3
461           f2w6y+bA56cVP8Toh+A3XFvTw8JFqAJVFGDm3MBrrSFOYcN8/8WY8T1cm0jq68
462           TcsiMh8y9KbWyeLJZedCVLLIfP1JgsSbBkZ7NLBFYCEEKvoGz2lMAuyJSh4+zT
463           L/NbcoIJq2ynCS965JKWWXl4rcBZPKBn5YUoU71dRK4/+HFrBoHejr6UHwVKd/
464           y0TaaBtTCBsqADAgERooGqBIGnYP7dngXFL2/hUWEs5PxGwlmvpWzGHWyh2QJ7
465           52eFj1tUpU3qT1NGgfVq2BVVWGDSVTO1vgDrkKCSDQwzkrqfwoZh4t6tt5tAPn
466           MCx2VDGyOu4Uv4PUsw4+uEevqkQRczpCsZT+y7pX7CxWHtytT3vLXNA6sANGnu
467           O7v7gTO+MGxzNvhVgMlujT2dkVgvCviVgJNuVef1VLVJWYM/zc4tuPaPaWToZJ
468           c=
469        C: boIBvjCCAbqgAwIBBaEDAgEOogcDBQAEAAAAo4HkYYHhMIHeoAMCAQWhCxsJbG
470           9jYWxob3N0ohwwGqADAgEBoRMwERsEaW1hcBsJbG9jYWxob3N0o4GrMIGooAMC
471           ARKigaAEgZ14G/b80bUSBMwwxwdpVjd/bDrL5sDnpxU/xOiH4DdcW9PDwkWoAl
472           UUYObcwGutIU5hw3z/xZjxPVybSOrrxNyyIyHzL0ptbJ4sll50JUssh8/UmCxJ
473           sGRns0sEVgIQQq+gbPaUwC7IlKHj7NMv81tyggmrbKcJL3rkkpZZeXitwFk8oG
474           flhShTvV1Erj/4cWsGgd6OvpQfBUp3/LRNpIG9MIG6oAMCARGhAwIBAaKBrQSB
475           qjE+doGGFMaz8g+nKl45qG5BPxzql0jXI5YMS+JqDeNBJIKasB0v9wMzXP9t8L
476           62PLsanqpow5bxAUtl/Dc8hqvc0cB+cC1P8RTgb0upMqzxTristf7goWRhQgTJ
477           OOwKJp/ZftZOkSdTHBQZL8StYuYe/6RkKkgnkUMK10VSec/YamG+5s37GvoRPG
478           Hu126PTyjXs3EziFqf6HT9Da/NJnDClFL8+nnlVFVt
479        S: + b2IwYKADAgEFoQMCAQ+iVDBSoAMCARGhAwIBAKJGBESTDM1z2PF5cUYOBmOW
480           IouXfHWtQzYzj1JFsJMV/CHMTmBrJavImHjR24f9WyCNOvmJMAWeHHOV9Jtpj6
481           rFt/ytas4U0g==
482        C:
483        S: . OK AUTHENTICATE KERBEROS_V5 authentication successful
484
485   The service requested is "imap/localhost" in the realm "localhost".
486   The password used was "foo", yielding an aes256-cts-hmac-sha1-96
487   encryption key of
488   0x6aefbaf05423cbc0fb44a41cc221783d7f52b764cca41fe2a05ad6d3bc7a67ea.
489
490   The first packet specify that mutual authentication and no integrity
491   or privacy layer (hence a zero maximum buffer size) and some random
492   data.
493
494   The second packet contains the AS-REQ, expanded as follows:
495
496
497
498
499
500
501
502
503Josefsson                Expires August 3, 2003                 [Page 9]
504
505Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
506
507
508   name:KDC-REQ  type:SEQUENCE
509     name:pvno  type:INTEGER  value:0x05
510     name:msg-type  type:INTEGER  value:0x0a
511     name:req-body  type:SEQUENCE
512       name:kdc-options  type:BIT_STR  value(32):00000000
513       name:cname  type:SEQUENCE
514         name:name-type  type:INTEGER  value:0x00
515         name:name-string  type:SEQ_OF
516           name:NULL  type:GENERALSTRING
517           name:?1  type:GENERALSTRING  value:6a6173
518       name:realm  type:GENERALSTRING  value:6c6f63616c686f7374
519       name:sname  type:SEQUENCE
520         name:name-type  type:INTEGER  value:0x00
521         name:name-string  type:SEQ_OF
522           name:NULL  type:GENERALSTRING
523           name:?1  type:GENERALSTRING  value:696d6170
524           name:?2  type:GENERALSTRING  value:6c6f63616c686f7374
525       name:till  type:TIME  value:20030202164143Z
526       name:nonce  type:INTEGER  value:0x5406d89f
527       name:etype  type:SEQ_OF
528         name:NULL  type:INTEGER
529         name:?1  type:INTEGER  value:0x11
530         name:?2  type:INTEGER  value:0x10
531         name:?3  type:INTEGER  value:0x03
532   -----BEGIN SHISHI KDC-REQ-----
533   an4wfKEDAgEFogMCAQqkcDBuoAcDBQAAAAAAoRAwDqADAgEAoQcwBRsDamFzogsb
534   CWxvY2FsaG9zdKMcMBqgAwIBAKETMBEbBGltYXAbCWxvY2FsaG9zdKURGA8yMDAz
535   MDIwMjE2NDE0M1qnBgIEVAbYn6gLMAkCARECARACAQM=
536   -----END SHISHI KDC-REQ-----
537
538   The third packet contains the AS-REP, expanded as follows:
539
540   name:KDC-REP  type:SEQUENCE
541     name:pvno  type:INTEGER  value:0x05
542     name:msg-type  type:INTEGER  value:0x0b
543     name:crealm  type:GENERALSTRING  value:6c6f63616c686f7374
544     name:cname  type:SEQUENCE
545       name:name-type  type:INTEGER  value:0x00
546       name:name-string  type:SEQ_OF
547         name:NULL  type:GENERALSTRING
548         name:?1  type:GENERALSTRING  value:6a6173
549     name:ticket  type:SEQUENCE
550       name:tkt-vno  type:INTEGER  value:0x05
551       name:realm  type:GENERALSTRING  value:6c6f63616c686f7374
552       name:sname  type:SEQUENCE
553         name:name-type  type:INTEGER  value:0x01
554         name:name-string  type:SEQ_OF
555           name:NULL  type:GENERALSTRING
556
557
558
559Josefsson                Expires August 3, 2003                [Page 10]
560
561Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
562
563
564           name:?1  type:GENERALSTRING  value:696d6170
565           name:?2  type:GENERALSTRING  value:6c6f63616c686f7374
566       name:enc-part  type:SEQUENCE
567         name:etype  type:INTEGER  value:0x12
568         name:cipher  type:OCT_STR  value:781bf6fcd1b51204cc30c7076956377
569         f6c3acbe6c0e7a7153fc4e887e0375c5bd3c3c245a802551460e6dcc06bad214
570         e61c37cffc598f13d5c9b48eaebc4dcb22321f32f4a6d6c9e2c965e74254b2c8
571         7cfd4982c49b06467b34b0456021042afa06cf694c02ec894a1e3ecd32ff35b7
572         28209ab6ca7092f7ae49296597978adc0593ca067e5852853bd5d44ae3ff8716
573         b0681de8ebe941f054a77fcb44d
574     name:enc-part  type:SEQUENCE
575       name:etype  type:INTEGER  value:0x11
576       name:cipher  type:OCT_STR  value:60fedd9e05c52f6fe151612ce4fc46c25
577       9afa56cc61d6ca1d9027be767858f5b54a54dea4f534681f56ad815555860d2553
578       3b5be00eb90a0920d0c3392ba9fc28661e2deadb79b403e7302c765431b23aee14
579       bf83d4b30e3eb847afaa4411733a42b194fecbba57ec2c561edcad4f7bcb5cd03a
580       b003469ee3bbbfb8133be306c7336f85580c96e8d3d9d91582f0af89580936e55e
581       7f554b54959833fcdce2db8f68f6964e86497
582   -----BEGIN SHISHI KDC-REP-----
583   a4IBzDCCAcigAwIBBaEDAgELowsbCWxvY2FsaG9zdKQQMA6gAwIBAKEHMAUbA2ph
584   c6WB5GGB4TCB3qADAgEFoQsbCWxvY2FsaG9zdKIcMBqgAwIBAaETMBEbBGltYXAb
585   CWxvY2FsaG9zdKOBqzCBqKADAgESooGgBIGdeBv2/NG1EgTMMMcHaVY3f2w6y+bA
586   56cVP8Toh+A3XFvTw8JFqAJVFGDm3MBrrSFOYcN8/8WY8T1cm0jq68TcsiMh8y9K
587   bWyeLJZedCVLLIfP1JgsSbBkZ7NLBFYCEEKvoGz2lMAuyJSh4+zTL/NbcoIJq2yn
588   CS965JKWWXl4rcBZPKBn5YUoU71dRK4/+HFrBoHejr6UHwVKd/y0TaaBtTCBsqAD
589   AgERooGqBIGnYP7dngXFL2/hUWEs5PxGwlmvpWzGHWyh2QJ752eFj1tUpU3qT1NG
590   gfVq2BVVWGDSVTO1vgDrkKCSDQwzkrqfwoZh4t6tt5tAPnMCx2VDGyOu4Uv4PUsw
591   4+uEevqkQRczpCsZT+y7pX7CxWHtytT3vLXNA6sANGnuO7v7gTO+MGxzNvhVgMlu
592   jT2dkVgvCviVgJNuVef1VLVJWYM/zc4tuPaPaWToZJc=
593   -----END SHISHI KDC-REP-----
594
595   After extracting the AS-REP, the EncASRepPart and Ticket are as
596   follows:
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615Josefsson                Expires August 3, 2003                [Page 11]
616
617Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
618
619
620   name:EncKDCRepPart  type:SEQUENCE
621     name:key  type:SEQUENCE
622       name:keytype  type:INTEGER  value:0x11
623       name:keyvalue  type:OCT_STR  value:517fe065071c845c425b5b18c4236618
624     name:last-req  type:SEQ_OF
625       name:NULL  type:SEQUENCE
626         name:lr-type  type:INTEGER
627         name:lr-value  type:TIME
628     name:nonce  type:INTEGER  value:0x5406d89f
629     name:flags  type:BIT_STR  value(3):20
630     name:authtime  type:TIME  value:20030202162503Z
631     name:endtime  type:TIME  value:20030202164143Z
632     name:srealm  type:GENERALSTRING  value:6c6f63616c686f7374
633     name:sname  type:SEQUENCE
634       name:name-type  type:INTEGER  value:0x01
635       name:name-string  type:SEQ_OF
636         name:NULL  type:GENERALSTRING
637         name:?1  type:GENERALSTRING  value:696d6170
638         name:?2  type:GENERALSTRING  value:6c6f63616c686f7374
639   -----BEGIN SHISHI EncKDCRepPart-----
640   MIGAoBswGaADAgERoRIEEFF/4GUHHIRcQltbGMQjZhihAjAAogYCBFQG2J+kBAMC
641   BSClERgPMjAwMzAyMDIxNjI1MDNapxEYDzIwMDMwMjAyMTY0MTQzWqkLGwlsb2Nh
642   bGhvc3SqHDAaoAMCAQGhEzARGwRpbWFwGwlsb2NhbGhvc3Q=
643   -----END SHISHI EncKDCRepPart-----
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671Josefsson                Expires August 3, 2003                [Page 12]
672
673Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
674
675
676   name:Ticket  type:SEQUENCE
677     name:tkt-vno  type:INTEGER  value:0x05
678     name:realm  type:GENERALSTRING  value:6c6f63616c686f7374
679     name:sname  type:SEQUENCE
680       name:name-type  type:INTEGER  value:0x01
681       name:name-string  type:SEQ_OF
682         name:NULL  type:GENERALSTRING
683         name:?1  type:GENERALSTRING  value:696d6170
684         name:?2  type:GENERALSTRING  value:6c6f63616c686f7374
685     name:enc-part  type:SEQUENCE
686       name:etype  type:INTEGER  value:0x12
687       name:cipher  type:OCT_STR  value:781bf6fcd1b51204cc30c7076956377f6
688       c3acbe6c0e7a7153fc4e887e0375c5bd3c3c245a802551460e6dcc06bad214e61c
689       37cffc598f13d5c9b48eaebc4dcb22321f32f4a6d6c9e2c965e74254b2c87cfd49
690       82c49b06467b34b0456021042afa06cf694c02ec894a1e3ecd32ff35b728209ab6
691       ca7092f7ae49296597978adc0593ca067e5852853bd5d44ae3ff8716b0681de8eb
692       e941f054a77fcb44d
693   -----BEGIN SHISHI Ticket-----
694   YYHhMIHeoAMCAQWhCxsJbG9jYWxob3N0ohwwGqADAgEBoRMwERsEaW1hcBsJbG9j
695   YWxob3N0o4GrMIGooAMCARKigaAEgZ14G/b80bUSBMwwxwdpVjd/bDrL5sDnpxU/
696   xOiH4DdcW9PDwkWoAlUUYObcwGutIU5hw3z/xZjxPVybSOrrxNyyIyHzL0ptbJ4s
697   ll50JUssh8/UmCxJsGRns0sEVgIQQq+gbPaUwC7IlKHj7NMv81tyggmrbKcJL3rk
698   kpZZeXitwFk8oGflhShTvV1Erj/4cWsGgd6OvpQfBUp3/LRN
699   -----END SHISHI Ticket-----
700
701   The third packet contains the AP-REQ, expanded as follows:
702
703   name:AP-REQ  type:SEQUENCE
704     name:pvno  type:INTEGER  value:0x05
705     name:msg-type  type:INTEGER  value:0x0e
706     name:ap-options  type:BIT_STR  value(32):04000000
707     name:ticket  type:SEQUENCE
708       name:tkt-vno  type:INTEGER  value:0x05
709       name:realm  type:GENERALSTRING  value:6c6f63616c686f7374
710       name:sname  type:SEQUENCE
711         name:name-type  type:INTEGER  value:0x01
712         name:name-string  type:SEQ_OF
713           name:NULL  type:GENERALSTRING
714           name:?1  type:GENERALSTRING  value:696d6170
715           name:?2  type:GENERALSTRING  value:6c6f63616c686f7374
716       name:enc-part  type:SEQUENCE
717         name:etype  type:INTEGER  value:0x12
718         name:cipher  type:OCT_STR  value:781bf6fcd1b51204cc30c7076956377
719         f6c3acbe6c0e7a7153fc4e887e0375c5bd3c3c245a802551460e6dcc06bad214
720         e61c37cffc598f13d5c9b48eaebc4dcb22321f32f4a6d6c9e2c965e74254b2c8
721         7cfd4982c49b06467b34b0456021042afa06cf694c02ec894a1e3ecd32ff35b7
722         28209ab6ca7092f7ae49296597978adc0593ca067e5852853bd5d44ae3ff8716
723         b0681de8ebe941f054a77fcb44d
724
725
726
727Josefsson                Expires August 3, 2003                [Page 13]
728
729Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
730
731
732     name:authenticator  type:SEQUENCE
733       name:etype  type:INTEGER  value:0x11
734       name:kvno  type:INTEGER  value:0x01
735       name:cipher  type:OCT_STR  value:313e76818614c6b3f20fa72a5e39a86e4
736       13f1cea9748d723960c4be26a0de34124829ab01d2ff703335cff6df0beb63cbb1
737       a9eaa68c396f1014b65fc373c86abdcd1c07e702d4ff114e06f4ba932acf14eb8a
738       cb5fee0a164614204c938ec0a269fd97ed64e9127531c14192fc4ad62e61effa46
739       42a482791430ad7455279cfd86a61bee6cdfb1afa113c61eed76e8f4f28d7b3713
740       3885a9fe874fd0dafcd2670c29452fcfa79e554556d
741   -----BEGIN SHISHI AP-REQ-----
742   boIBvjCCAbqgAwIBBaEDAgEOogcDBQAEAAAAo4HkYYHhMIHeoAMCAQWhCxsJbG9j
743   YWxob3N0ohwwGqADAgEBoRMwERsEaW1hcBsJbG9jYWxob3N0o4GrMIGooAMCARKi
744   gaAEgZ14G/b80bUSBMwwxwdpVjd/bDrL5sDnpxU/xOiH4DdcW9PDwkWoAlUUYObc
745   wGutIU5hw3z/xZjxPVybSOrrxNyyIyHzL0ptbJ4sll50JUssh8/UmCxJsGRns0sE
746   VgIQQq+gbPaUwC7IlKHj7NMv81tyggmrbKcJL3rkkpZZeXitwFk8oGflhShTvV1E
747   rj/4cWsGgd6OvpQfBUp3/LRNpIG9MIG6oAMCARGhAwIBAaKBrQSBqjE+doGGFMaz
748   8g+nKl45qG5BPxzql0jXI5YMS+JqDeNBJIKasB0v9wMzXP9t8L62PLsanqpow5bx
749   AUtl/Dc8hqvc0cB+cC1P8RTgb0upMqzxTristf7goWRhQgTJOOwKJp/ZftZOkSdT
750   HBQZL8StYuYe/6RkKkgnkUMK10VSec/YamG+5s37GvoRPGHu126PTyjXs3EziFqf
751   6HT9Da/NJnDClFL8+nnlVFVt
752   -----END SHISHI AP-REQ-----
753
754   After extracting the AP-REP, the Authenticator is as follows:
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783Josefsson                Expires August 3, 2003                [Page 14]
784
785Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
786
787
788   name:Authenticator  type:SEQUENCE
789     name:authenticator-vno  type:INTEGER  value:0x05
790     name:crealm  type:GENERALSTRING  value:6c6f63616c686f7374
791     name:cname  type:SEQUENCE
792       name:name-type  type:INTEGER  value:0x01
793       name:name-string  type:SEQ_OF
794         name:NULL  type:GENERALSTRING
795         name:?1  type:GENERALSTRING  value:6a6173
796     name:cksum  type:SEQUENCE
797       name:cksumtype  type:INTEGER  value:0x0a
798       name:checksum  type:OCT_STR  value:15843a44f4f5f71746cc32e8
799     name:cusec  type:INTEGER  value:0x07480d
800     name:ctime  type:TIME  value:20030202162507Z
801     name:authorization-data  type:SEQ_OF
802       name:NULL  type:SEQUENCE
803         name:ad-type  type:INTEGER
804         name:ad-data  type:OCT_STR
805       name:?1  type:SEQUENCE
806         name:ad-type  type:INTEGER  value:0xff
807         name:ad-data  type:OCT_STR  value:09000000000900000000e9ebe38d0b
808         6bdca6b45b987d89f791a1
809   -----BEGIN SHISHI Authenticator-----
810   YoGDMIGAoAMCAQWhCxsJbG9jYWxob3N0ohAwDqADAgEBoQcwBRsDamFzoxcwFaAD
811   AgEKoQ4EDBWEOkT09fcXRswy6KQFAgMHSA2lERgPMjAwMzAyMDIxNjI1MDdaqCcw
812   JTAjoAMCAf+hHAQaCQAAAAAJAAAAAOnr440La9ymtFuYfYn3kaE=
813   -----END SHISHI Authenticator-----
814
815   The fourth packet contains the AP-REP, expanded as follows:
816
817   name:AP-REP  type:SEQUENCE
818     name:pvno  type:INTEGER  value:0x05
819     name:msg-type  type:INTEGER  value:0x0f
820     name:enc-part  type:SEQUENCE
821       name:etype  type:INTEGER  value:0x11
822       name:kvno  type:INTEGER  value:0x00
823       name:cipher  type:OCT_STR  value:930ccd73d8f17971460e066396228b977
824       c75ad4336338f5245b09315fc21cc4e606b25abc89878d1db87fd5b208d3af9893
825       0059e1c7395f49b698faac5b7fcad6ace14d2
826   -----BEGIN SHISHI AP-REP-----
827   b2IwYKADAgEFoQMCAQ+iVDBSoAMCARGhAwIBAKJGBESTDM1z2PF5cUYOBmOWIouX
828   fHWtQzYzj1JFsJMV/CHMTmBrJavImHjR24f9WyCNOvmJMAWeHHOV9Jtpj6rFt/yt
829   as4U0g==
830   -----END SHISHI AP-REP-----
831
832   After extracting the AP-REP, the EncAPRepPart is as follows:
833
834
835
836
837
838
839Josefsson                Expires August 3, 2003                [Page 15]
840
841Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
842
843
844   name:EncAPRepPart  type:SEQUENCE
845     name:ctime  type:TIME  value:20030202162507Z
846     name:cusec  type:INTEGER  value:0x07480d
847   -----BEGIN SHISHI EncAPRepPart-----
848   exwwGqARGA8yMDAzMDIwMjE2MjUwN1qhBQIDB0gN
849   -----END SHISHI EncAPRepPart-----
850
851
8526. Security Considerations
853
854   The authentication phase is believed to be no less secure than the
855   Client/Server Authentication exchange described in the Kerberos 5
856   protocol.
857
858   If no security layer is negotiated, the connection is subject to
859   active man-in-the-middle attackers that hijack the connection after
860   authentication has been completed.
861
862   When security layers are used, it is believed that the communication
863   channel negotiated by this specification is no less secure than the
864   KRB_SAFE and KRB_PRIV primitives.  In other words, it is believed
865   that if an attack that breaches integrity or privacy of this
866   mechanism, the same attack also applies to the Kerberos 5
867   specification, and vice versa.
868
869   Server implementations should be aware that the proxy function can be
870   abused, and MAY implement precaution against this if it is considered
871   a threat.  Useful precautions include limiting the size and number of
872   packets forwarded, and to abort the SASL exchange when the limit is
873   reached.
874
875   Server implementations should make sure the method to look up KDC for
876   the client indicated realm does not cause security problems.  In
877   particular, trusting unprotected DNS lookups to find the KDC of a
878   realm may be considered as dangerous by a server.
879
880   The forward-compatibility behavior of returning empty responses to
881   unsupported commands may be abused as a covert channel.
882
883   The reason for the client to send, in the Authenticator checksum
884   field, not only the server random number but the entire initial
885   server packet with the security layer bitmask and maximum cipher-text
886   buffer size accepted by server, is to prevent an attacker from
887   downgrading the security layer and preference for mutual
888   authentication ultimately selected.  The random number ties the
889   client and server to the same network session, prevent
890   man-in-the-middle attacks assuming a Kerberos 5 security layer is
891   chosen and that the Kerberos 5 security layer is secure.
892
893
894
895Josefsson                Expires August 3, 2003                [Page 16]
896
897Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
898
899
900   Generating AS-REP using a legacy password database requires
901   calculating the string2key operation.  This may be a costly operation
902   (in particular for the recent AES ciphers), so servers should either
903   pre-calculate and store the key once or take precautions against
904   opening itself up to a Denial Of Service attack which exhausts CPU
905   power on the server.
906
907   The security considerations of Kerberos 5 and SASL are inherited.
908   Some immediate consequences of this follows (this is an inconclusive
909   summary):
910
911   Note that some of the Kerberos 5 encryption types are considered
912   weak, implementations must decide which algorithms are trusted.
913
914   Note that the encryption types indicated in AS-REQ/TGS-REQ are not
915   integrity protected, so an attacker may downgrade the encryption keys
916   ultimately used.
917
918   Note that Kerberos 5 do not authorize users, it only authenticate
919   users.  Applications using this mechanism must thus perform checks,
920   not described in detail in this document, to make sure the
921   authenticated user is authorized to the service she is requesting.
922
923   Note that the SASL framework is subject to "downgrade" attacks where
924   an attacker forces a weaker SASL mechanism to be used.  The use of,
925   e.g., TLS [5] can be used to mitigate this.
926
927   Note that clients should use the server name exactly as the user
928   specified, or at least abstain from canonicalizing the server name
929   with insecure mechanisms such as unprotected DNS.
930
931Normative References
932
933   [1]  Kohl, J. and B. Neuman, "The Kerberos Network Authentication
934        Service (V5)", RFC 1510, September 1993.
935
936   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
937        Levels", BCP 14, RFC 2119, March 1997.
938
939   [3]  Myers, J., "Simple Authentication and Security Layer (SASL)",
940        RFC 2222, October 1997.
941
942Informative References
943
944   [4]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
945        Recommendations for Security", RFC 1750, December 1994.
946
947   [5]  Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
948
949
950
951Josefsson                Expires August 3, 2003                [Page 17]
952
953Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
954
955
956        P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
957        1999.
958
959   [6]  Linn, J., "Generic Security Service Application Program
960        Interface Version 2, Update 1", RFC 2743, January 2000.
961
962
963Author's Address
964
965   Simon Josefsson
966   Drottningholmsv. 70
967   Stockholm  112 42
968   Sweden
969
970   EMail: simon@josefsson.org
971
972Acknowledgments
973
974   Text and ideas was borrowed from the Kerberos version 4 SASL
975   mechanism in RFC 2222.  Lawrence Greenfield suggested adding a
976   security consideration about server name canonicalization.
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007Josefsson                Expires August 3, 2003                [Page 18]
1008
1009Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
1010
1011
1012Intellectual Property Statement
1013
1014   The IETF takes no position regarding the validity or scope of any
1015   intellectual property or other rights that might be claimed to
1016   pertain to the implementation or use of the technology described in
1017   this document or the extent to which any license under such rights
1018   might or might not be available; neither does it represent that it
1019   has made any effort to identify any such rights.  Information on the
1020   IETF's procedures with respect to rights in standards-track and
1021   standards-related documentation can be found in BCP-11.  Copies of
1022   claims of rights made available for publication and any assurances of
1023   licenses to be made available, or the result of an attempt made to
1024   obtain a general license or permission for the use of such
1025   proprietary rights by implementors or users of this specification can
1026   be obtained from the IETF Secretariat.
1027
1028   The IETF invites any interested party to bring to its attention any
1029   copyrights, patents or patent applications, or other proprietary
1030   rights which may cover technology that may be required to practice
1031   this standard.  Please address the information to the IETF Executive
1032   Director.
1033
1034
1035Full Copyright Statement
1036
1037   Copyright (C) The Internet Society (2003).  All Rights Reserved.
1038
1039   This document and translations of it may be copied and furnished to
1040   others, and derivative works that comment on or otherwise explain it
1041   or assist in its implementation may be prepared, copied, published
1042   and distributed, in whole or in part, without restriction of any
1043   kind, provided that the above copyright notice and this paragraph are
1044   included on all such copies and derivative works.  However, this
1045   document itself may not be modified in any way, such as by removing
1046   the copyright notice or references to the Internet Society or other
1047   Internet organizations, except as needed for the purpose of
1048   developing Internet standards in which case the procedures for
1049   copyrights defined in the Internet Standards process must be
1050   followed, or as required to translate it into languages other than
1051   English.
1052
1053   The limited permissions granted above are perpetual and will not be
1054   revoked by the Internet Society or its successors or assignees.
1055
1056   This document and the information contained herein is provided on an
1057   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1058   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1059   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1060
1061
1062
1063Josefsson                Expires August 3, 2003                [Page 19]
1064
1065Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
1066
1067
1068   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1069   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1070
1071
1072Acknowledgement
1073
1074   Funding for the RFC Editor function is currently provided by the
1075   Internet Society.
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119Josefsson                Expires August 3, 2003                [Page 20]
1120
1121