summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6803.txt
blob: 7e2765979b74779b63db0283ed587a032538a10e (plain) (blame)
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
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
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
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
Internet Engineering Task Force (IETF)                         G. Hudson
Request for Comments: 6803                       MIT Kerberos Consortium
Category: Informational                                    November 2012
ISSN: 2070-1721


                   Camellia Encryption for Kerberos 5

Abstract

   This document specifies two encryption types and two corresponding
   checksum types for the Kerberos cryptosystem framework defined in RFC
   3961.  The new types use the Camellia block cipher in CBC mode with
   ciphertext stealing and the CMAC algorithm for integrity protection.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6803.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.






Hudson                        Informational                     [Page 1]
^L
RFC 6803           Camellia Encryption for Kerberos 5      November 2012


1.  Introduction

   The Camellia block cipher, described in [RFC3713], has a 128-bit
   block size and a 128-bit, 192-bit, or 256-bit key size, similar to
   AES.  This document specifies Kerberos encryption and checksum types
   for Camellia using 128-bit or 256-bit keys.  The new types conform to
   the framework specified in [RFC3961] but do not use the simplified
   profile.

   Like the simplified profile, the new types use key derivation to
   produce keys for encryption, integrity protection, and checksum
   operations.  Instead of the key derivation function described in
   [RFC3961], Section 5.1, the new types use a key derivation function
   from the family specified in [SP800-108].

   The new types use the CMAC algorithm for integrity protection and
   checksum operations.  As a consequence, they do not rely on a hash
   algorithm except when generating keys from strings.

   Like the AES encryption types [RFC3962], the new encryption types use
   CBC mode with ciphertext stealing [RFC3962] to avoid the need for
   padding.  They also use the same PBKDF2 algorithm for key generation
   from strings, with a modification to the salt string to ensure that
   different keys are generated for Camellia and AES encryption types.

2.  Protocol Key Representation

   The Camellia key space is dense, so we use random octet strings
   directly as keys.  The first bit of the Camellia bit string is the
   high bit of the first byte of the random octet string.

3.  Key Derivation

   We use a key derivation function from the family specified in
   [SP800-108], Section 5.2, "KDF in Feedback Mode".  The PRF parameter
   of the key derivation function is CMAC with Camellia-128 or
   Camellia-256 as the underlying block cipher; this PRF has an output
   size of 128 bits.  A block counter is used with a length of 4 bytes,
   represented in big-endian order.  The length of the output key in
   bits (denoted as k) is also represented as a 4-byte string in big-
   endian order.  The label input to the KDF is the usage constant
   supplied to the key derivation function, and the context is unused.
   In the following summary, | indicates concatenation.  The random-to-
   key function is the identity function, as defined in Section 6.  The
   k-truncate function is defined in [RFC3961], Section 5.1.






Hudson                        Informational                     [Page 2]
^L
RFC 6803           Camellia Encryption for Kerberos 5      November 2012


   n = ceiling(k / 128)
   K(0) = zeros
   K(i) = CMAC(key, K(i-1) | i | constant | 0x00 | k)
   DR(key, constant) = k-truncate(K(1) | K(2) | ... | K(n))
   KDF-FEEDBACK-CMAC(key, constant) = random-to-key(DR(key, constant))

   The constants used for key derivation are the same as those used in
   the simplified profile.

4.  Key Generation from Strings

   We use a variation on the key generation algorithm specified in
   [RFC3962], Section 4.

   First, to ensure that different long-term keys are used with Camellia
   and AES, we prepend the enctype name to the salt string, separated by
   a null byte.  The enctype name is "camellia128-cts-cmac" or
   "camellia256-cts-cmac" (without the quotes).

   Second, the final key derivation step uses the algorithm described in
   Section 3 instead of the key derivation algorithm used by the
   simplified profile.

   Third, if no string-to-key parameters are specified, the default
   number of iterations is raised to 32768.

   saltp = enctype-name | 0x00 | salt
   tkey = random-to-key(PBKDF2-HMAC-SHA1(passphrase, saltp,
                                         iter_count, keylength))
   key = KDF-FEEDBACK-CMAC(tkey, "kerberos")

5.  CMAC Checksum Algorithm

   For integrity protection and checksums, we use the CMAC function
   defined in [SP800-38B], with Camellia-128 or Camellia-256 as the
   underlying block cipher.  The output length (Tlen) is 128 bits for
   both key sizes.

6.  Encryption Algorithm Parameters

   The following parameters, required by [RFC3961], Section 3, apply to
   the encryption types camellia128-cts-cmac, which uses a 128-bit
   protocol key, and camellia256-cts-cmac, which uses a 256-bit protocol
   key.

   Protocol key format: as defined in Section 2.

   Specific key structure: three protocol format keys: { Kc, Ke, Ki }.



Hudson                        Informational                     [Page 3]
^L
RFC 6803           Camellia Encryption for Kerberos 5      November 2012


   Required checksum mechanism: as defined in Section 7.

   Key generation seed length: the key size (128 or 256 bits).

   String-to-key function: as defined in Section 4.

   Random-to-key function: identity function.

   Key-derivation function: as indicated below, with usage represented
   as 4 octets in big-endian order.

   String-to-key parameter format: 4 octets indicating a 32-bit
   iteration count in big-endian order.  Implementations may limit the
   count as specified in [RFC3962], Section 4.

   Default string-to-key parameters: 00 00 80 00.

   Kc = KDF-FEEDBACK-CMAC(base-key, usage | 0x99)
   Ke = KDF-FEEDBACK-CMAC(base-key, usage | 0xAA)
   Ki = KDF-FEEDBACK-CMAC(base-key, usage | 0x55)

   Cipher state: a 128-bit CBC initialization vector.

   Initial cipher state: all bits zero.

   Encryption function: as follows, where E() is Camellia encryption in
   CBC-CTS mode, with the next-to-last block used as the CBC-style ivec,
   or the last block if there is only one.

   conf = Random string of 128 bits
   (C, newstate) = E(Ke, conf | plaintext, oldstate)
   M = CMAC(Ki, conf | plaintext)
   ciphertext = C | M

   Decryption function: as follows, where D() is Camellia decryption in
   CBC-CTS mode, with the ivec treated as in E().  To separate the
   ciphertext into C and M components, use the final 16 bytes for M and
   all of the preceding bytes for C.

   (C, M) = ciphertext
   (P, newIV) = D(Ke, C, oldstate)
   if (M != CMAC(Ki, P)) report error
   newstate = newIV

   Pseudo-random function: as follows.

   Kp = KDF-FEEDBACK-CMAC(protocol-key, "prf")
   PRF = CMAC(Kp, octet-string)



Hudson                        Informational                     [Page 4]
^L
RFC 6803           Camellia Encryption for Kerberos 5      November 2012


7.  Checksum Parameters

   The following parameters, required by [RFC3961], Section 4, apply to
   the checksum types cmac-camellia128 and cmac-camellia256, which are
   the associated checksum for camellia128-cts-cmac and camellia256-cts-
   cmac, respectively.

   Associated cryptosystem: Camellia-128 or Camellia-256 as appropriate
   for the checksum type.

   get_mic: CMAC(Kc, message).

   verify_mic: get_mic and compare.

8.  Security Considerations

   Chapter 4 of [CRYPTOENG] discusses weaknesses of the CBC cipher mode.
   An attacker who can observe enough messages generated with the same
   key to encounter a collision in ciphertext blocks could recover the
   XOR of the plaintexts of the previous blocks.  Observing such a
   collision becomes likely as the number of blocks observed approaches
   2^64.  This consideration applies to all previously standardized
   Kerberos encryption types and all uses of CBC encryption with 128-bit
   block ciphers in other protocols.  Kerberos deployments can mitigate
   this concern by rolling over keys often enough to make observing 2^64
   messages unlikely.

   Because the new checksum types are deterministic, an attacker could
   pre-compute checksums for a known plain-text message in 2^64 randomly
   chosen protocol keys.  The attacker could then observe checksums
   legitimately computed in different keys until a collision with one of
   the pre-computed keys is observed; this becomes likely after the
   number of observed checksums approaches 2^64.  Observing such a
   collision allows the attacker to recover the protocol key.  This
   consideration applies to most previously standardized Kerberos
   checksum types and most uses of 128-bit checksums in other protocols.

   Kerberos deployments should not migrate to the Camellia encryption
   types simply because they are newer, but should use them only if
   business needs require the use of Camellia, or if a serious flaw is
   discovered in AES which does not apply to Camellia.

   The security considerations described in [RFC3962], Section 8,
   regarding the string-to-key algorithm also apply to the Camellia
   encryption types.






Hudson                        Informational                     [Page 5]
^L
RFC 6803           Camellia Encryption for Kerberos 5      November 2012


   At the time of writing this document, there are no known weak keys
   for Camellia, and no security problem has been found on Camellia (see
   [NESSIE], [CRYPTREC], and [LNCS5867]).

9.  IANA Considerations

   IANA has assigned the following numbers from the Encryption Type
   Numbers and Checksum Type Numbers registries defined in [RFC3961],
   Section 11.

                             Encryption types

               +-------+----------------------+-----------+
               | etype | encryption type      | Reference |
               +-------+----------------------+-----------+
               | 25    | camellia128-cts-cmac | [RFC6803] |
               | 26    | camellia256-cts-cmac | [RFC6803] |
               +-------+----------------------+-----------+

                              Checksum types

     +---------------+------------------+---------------+-----------+
     | sumtype value | Checksum type    | checksum size | Reference |
     +---------------+------------------+---------------+-----------+
     | 17            | cmac-camellia128 | 16            | [RFC6803] |
     | 18            | cmac-camellia256 | 16            | [RFC6803] |
     +---------------+------------------+---------------+-----------+

10.  Test Vectors

   Sample results for string-to-key conversion:

   Iteration count = 1
   Pass phrase = "password"
   Salt = "ATHENA.MIT.EDUraeburn"
   128-bit Camellia key:
       57 D0 29 72 98 FF D9 D3 5D E5 A4 7F B4 BD E2 4B
   256-bit Camellia key:
       B9 D6 82 8B 20 56 B7 BE 65 6D 88 A1 23 B1 FA C6
       82 14 AC 2B 72 7E CF 5F 69 AF E0 C4 DF 2A 6D 2C











Hudson                        Informational                     [Page 6]
^L
RFC 6803           Camellia Encryption for Kerberos 5      November 2012


   Iteration count = 2
   Pass phrase = "password"
   Salt = "ATHENA.MIT.EDUraeburn"
   128-bit Camellia key:
       73 F1 B5 3A A0 F3 10 F9 3B 1D E8 CC AA 0C B1 52
   256-bit Camellia key:
       83 FC 58 66 E5 F8 F4 C6 F3 86 63 C6 5C 87 54 9F
       34 2B C4 7E D3 94 DC 9D 3C D4 D1 63 AD E3 75 E3

   Iteration count = 1200
   Pass phrase = "password"
   Salt = "ATHENA.MIT.EDUraeburn"
   128-bit Camellia key:
       8E 57 11 45 45 28 55 57 5F D9 16 E7 B0 44 87 AA
   256-bit Camellia key:
       77 F4 21 A6 F2 5E 13 83 95 E8 37 E5 D8 5D 38 5B
       4C 1B FD 77 2E 11 2C D9 20 8C E7 2A 53 0B 15 E6

   Iteration count = 5
   Pass phrase = "password"
   Salt=0x1234567878563412
   128-bit Camellia key:
       00 49 8F D9 16 BF C1 C2 B1 03 1C 17 08 01 B3 81
   256-bit Camellia key:
       11 08 3A 00 BD FE 6A 41 B2 F1 97 16 D6 20 2F 0A
       FA 94 28 9A FE 8B 27 A0 49 BD 28 B1 D7 6C 38 9A

   Iteration count = 1200
   Pass phrase = (64 characters)
     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
   Salt="pass phrase equals block size"
   128-bit Camellia key:
       8B F6 C3 EF 70 9B 98 1D BB 58 5D 08 68 43 BE 05
   256-bit Camellia key:
       11 9F E2 A1 CB 0B 1B E0 10 B9 06 7A 73 DB 63 ED
       46 65 B4 E5 3A 98 D1 78 03 5D CF E8 43 A6 B9 B0

   Iteration count = 1200
   Pass phrase = (65 characters)
     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
   Salt = "pass phrase exceeds block size"
   128-bit Camellia key:
       57 52 AC 8D 6A D1 CC FE 84 30 B3 12 87 1C 2F 74
   256-bit Camellia key:
       61 4D 5D FC 0B A6 D3 90 B4 12 B8 9A E4 D5 B0 88
       B6 12 B3 16 51 09 94 67 9D DB 43 83 C7 12 6D DF





Hudson                        Informational                     [Page 7]
^L
RFC 6803           Camellia Encryption for Kerberos 5      November 2012


   Iteration count = 50
   Pass phrase = g-clef (0xf09d849e)
   Salt = "EXAMPLE.COMpianist"
   128-bit Camellia key:
       CC 75 C7 FD 26 0F 1C 16 58 01 1F CC 0D 56 06 16
   256-bit Camellia key:
       16 3B 76 8C 6D B1 48 B4 EE C7 16 3D F5 AE D7 0E
       20 6B 68 CE C0 78 BC 06 9E D6 8A 7E D3 6B 1E CC

   Sample results for key derivation:

   128-bit Camellia key:
       57 D0 29 72 98 FF D9 D3 5D E5 A4 7F B4 BD E2 4B
   Kc value for key usage 2 (constant = 0x0000000299):
       D1 55 77 5A 20 9D 05 F0 2B 38 D4 2A 38 9E 5A 56
   Ke value for key usage 2 (constant = 0x00000002AA):
       64 DF 83 F8 5A 53 2F 17 57 7D 8C 37 03 57 96 AB
   Ki value for key usage 2 (constant = 0x0000000255):
       3E 4F BD F3 0F B8 25 9C 42 5C B6 C9 6F 1F 46 35

   256-bit Camellia key:
       B9 D6 82 8B 20 56 B7 BE 65 6D 88 A1 23 B1 FA C6
       82 14 AC 2B 72 7E CF 5F 69 AF E0 C4 DF 2A 6D 2C
   Kc value for key usage 2 (constant = 0x0000000299):
       E4 67 F9 A9 55 2B C7 D3 15 5A 62 20 AF 9C 19 22
       0E EE D4 FF 78 B0 D1 E6 A1 54 49 91 46 1A 9E 50
   Ke value for key usage 2 (constant = 0x00000002AA):
       41 2A EF C3 62 A7 28 5F C3 96 6C 6A 51 81 E7 60
       5A E6 75 23 5B 6D 54 9F BF C9 AB 66 30 A4 C6 04
   Ki value for key usage 2 (constant = 0x0000000255):
       FA 62 4F A0 E5 23 99 3F A3 88 AE FD C6 7E 67 EB
       CD 8C 08 E8 A0 24 6B 1D 73 B0 D1 DD 9F C5 82 B0

   Sample encryptions (all using the default cipher state):

   Plaintext: (empty)
   128-bit Camellia key:
       1D C4 6A 8D 76 3F 4F 93 74 2B CB A3 38 75 76 C3
   Random confounder:
       B6 98 22 A1 9A 6B 09 C0 EB C8 55 7D 1F 1B 6C 0A
   Ciphertext:
       C4 66 F1 87 10 69 92 1E DB 7C 6F DE 24 4A 52 DB
       0B A1 0E DC 19 7B DB 80 06 65 8C A3 CC CE 6E B8








Hudson                        Informational                     [Page 8]
^L
RFC 6803           Camellia Encryption for Kerberos 5      November 2012


   Plaintext: 1
   Random confounder:
       6F 2F C3 C2 A1 66 FD 88 98 96 7A 83 DE 95 96 D9
   128-bit Camellia key:
       50 27 BC 23 1D 0F 3A 9D 23 33 3F 1C A6 FD BE 7C
   Ciphertext:
       84 2D 21 FD 95 03 11 C0 DD 46 4A 3F 4B E8 D6 DA
       88 A5 6D 55 9C 9B 47 D3 F9 A8 50 67 AF 66 15 59
       B8

   Plaintext: 9 bytesss
   Random confounder:
       A5 B4 A7 1E 07 7A EE F9 3C 87 63 C1 8F DB 1F 10
   128-bit Camellia key:
       A1 BB 61 E8 05 F9 BA 6D DE 8F DB DD C0 5C DE A0
   Ciphertext:
       61 9F F0 72 E3 62 86 FF 0A 28 DE B3 A3 52 EC 0D
       0E DF 5C 51 60 D6 63 C9 01 75 8C CF 9D 1E D3 3D
       71 DB 8F 23 AA BF 83 48 A0

   Plaintext: 13 bytes byte
   Random confounder:
       19 FE E4 0D 81 0C 52 4B 5B 22 F0 18 74 C6 93 DA
   128-bit Camellia key:
       2C A2 7A 5F AF 55 32 24 45 06 43 4E 1C EF 66 76
   Ciphertext:
       B8 EC A3 16 7A E6 31 55 12 E5 9F 98 A7 C5 00 20
       5E 5F 63 FF 3B B3 89 AF 1C 41 A2 1D 64 0D 86 15
       C9 ED 3F BE B0 5A B6 AC B6 76 89 B5 EA

   Plaintext: 30 bytes bytes bytes bytes byt
   Random confounder:
       CA 7A 7A B4 BE 19 2D AB D6 03 50 6D B1 9C 39 E2
   128-bit Camellia key:
       78 24 F8 C1 6F 83 FF 35 4C 6B F7 51 5B 97 3F 43
   Ciphertext:
       A2 6A 39 05 A4 FF D5 81 6B 7B 1E 27 38 0D 08 09
       0C 8E C1 F3 04 49 6E 1A BD CD 2B DC D1 DF FC 66
       09 89 E1 17 A7 13 DD BB 57 A4 14 6C 15 87 CB A4
       35 66 65 59 1D 22 40 28 2F 58 42 B1 05 A5











Hudson                        Informational                     [Page 9]
^L
RFC 6803           Camellia Encryption for Kerberos 5      November 2012


   Plaintext: (empty)
   Random confounder:
       3C BB D2 B4 59 17 94 10 67 F9 65 99 BB 98 92 6C
   256-bit Camellia key:
       B6 1C 86 CC 4E 5D 27 57 54 5A D4 23 39 9F B7 03
       1E CA B9 13 CB B9 00 BD 7A 3C 6D D8 BF 92 01 5B
   Ciphertext:
       03 88 6D 03 31 0B 47 A6 D8 F0 6D 7B 94 D1 DD 83
       7E CC E3 15 EF 65 2A FF 62 08 59 D9 4A 25 92 66

   Plaintext: 1
   Random confounder:
       DE F4 87 FC EB E6 DE 63 46 D4 DA 45 21 BB A2 D2
   256-bit Camellia key:
       1B 97 FE 0A 19 0E 20 21 EB 30 75 3E 1B 6E 1E 77
       B0 75 4B 1D 68 46 10 35 58 64 10 49 63 46 38 33
   Ciphertext:
       2C 9C 15 70 13 3C 99 BF 6A 34 BC 1B 02 12 00 2F
       D1 94 33 87 49 DB 41 35 49 7A 34 7C FC D9 D1 8A
       12

   Plaintext: 9 bytesss
   Random confounder:
       AD 4F F9 04 D3 4E 55 53 84 B1 41 00 FC 46 5F 88
   256-bit Camellia key:
       32 16 4C 5B 43 4D 1D 15 38 E4 CF D9 BE 80 40 FE
       8C 4A C7 AC C4 B9 3D 33 14 D2 13 36 68 14 7A 05
   Ciphertext:
       9C 6D E7 5F 81 2D E7 ED 0D 28 B2 96 35 57 A1 15
       64 09 98 27 5B 0A F5 15 27 09 91 3F F5 2A 2A 9C
       8E 63 B8 72 F9 2E 64 C8 39

   Plaintext: 13 bytes byte
   Random confounder:
       CF 9B CA 6D F1 14 4E 0C 0A F9 B8 F3 4C 90 D5 14
   256-bit Camellia key:
       B0 38 B1 32 CD 8E 06 61 22 67 FA B7 17 00 66 D8
       8A EC CB A0 B7 44 BF C6 0D C8 9B CA 18 2D 07 15
   Ciphertext:
       EE EC 85 A9 81 3C DC 53 67 72 AB 9B 42 DE FC 57
       06 F7 26 E9 75 DD E0 5A 87 EB 54 06 EA 32 4C A1
       85 C9 98 6B 42 AA BE 79 4B 84 82 1B EE









Hudson                        Informational                    [Page 10]
^L
RFC 6803           Camellia Encryption for Kerberos 5      November 2012


   Plaintext: 30 bytes bytes bytes bytes byt
   Random confounder:
       64 4D EF 38 DA 35 00 72 75 87 8D 21 68 55 E2 28
   256-bit Camellia key:
       CC FC D3 49 BF 4C 66 77 E8 6E 4B 02 B8 EA B9 24
       A5 46 AC 73 1C F9 BF 69 89 B9 96 E7 D6 BF BB A7
   Ciphertext:
       0E 44 68 09 85 85 5F 2D 1F 18 12 52 9C A8 3B FD
       8E 34 9D E6 FD 9A DA 0B AA A0 48 D6 8E 26 5F EB
       F3 4A D1 25 5A 34 49 99 AD 37 14 68 87 A6 C6 84
       57 31 AC 7F 46 37 6A 05 04 CD 06 57 14 74

   Sample checksums:

   Plaintext: abcdefghijk
   Checksum type: cmac-camellia128
   128-bit Camellia key:
       1D C4 6A 8D 76 3F 4F 93 74 2B CB A3 38 75 76 C3
   Key usage: 7
   Checksum:
       11 78 E6 C5 C4 7A 8C 1A E0 C4 B9 C7 D4 EB 7B 6B

   Plaintext: ABCDEFGHIJKLMNOPQRSTUVWXYZ
   Checksum type: cmac-camellia128
   128-bit Camellia key:
       50 27 BC 23 1D 0F 3A 9D 23 33 3F 1C A6 FD BE 7C
   Key usage: 8
   Checksum:
       D1 B3 4F 70 04 A7 31 F2 3A 0C 00 BF 6C 3F 75 3A

   Plaintext: 123456789
   Checksum type: cmac-camellia256
   256-bit Camellia key:
       B6 1C 86 CC 4E 5D 27 57 54 5A D4 23 39 9F B7 03
       1E CA B9 13 CB B9 00 BD 7A 3C 6D D8 BF 92 01 5B
   Key usage: 9
   Checksum:
       87 A1 2C FD 2B 96 21 48 10 F0 1C 82 6E 77 44 B1

   Plaintext: !@#$%^&*()!@#$%^&*()!@#$%^&*()
   Checksum type: cmac-camellia256
   256-bit Camellia key:
       32 16 4C 5B 43 4D 1D 15 38 E4 CF D9 BE 80 40 FE
       8C 4A C7 AC C4 B9 3D 33 14 D2 13 36 68 14 7A 05
   Key usage: 10
   Checksum:
       3F A0 B4 23 55 E5 2B 18 91 87 29 4A A2 52 AB 64




Hudson                        Informational                    [Page 11]
^L
RFC 6803           Camellia Encryption for Kerberos 5      November 2012


11.  References

11.1.  Normative References

   [RFC3713]    Matsui, M., Nakajima, J., and S. Moriai, "A Description
                of the Camellia Encryption Algorithm", RFC 3713,
                April 2004.

   [RFC3961]    Raeburn, K., "Encryption and Checksum Specifications for
                Kerberos 5", RFC 3961, February 2005.

   [RFC3962]    Raeburn, K., "Advanced Encryption Standard (AES)
                Encryption for Kerberos 5", RFC 3962, February 2005.

   [SP800-108]  Chen, L., "Recommendation for Key Derivation Using
                Pseudorandom Functions", NIST Special Publication 800&
                nhby;108, October 2009.

   [SP800-38B]  Dworkin, M., "Recommendation for Block Cipher Modes of
                Operation: The CMAC Mode for Authentication", NIST
                Special Publication 800-38B, October 2009.

11.2.  Informative References

   [CRYPTOENG]  Schneier, B., "Cryptography Engineering", March 2010.

   [CRYPTREC]   Information-technology Promotion Agency (IPA), Japan,
                "Cryptography Research and Evaluation Committees",
                <http://www.ipa.go.jp/security/enc/CRYPTREC/
                index-e.html>.

   [LNCS5867]   Mala, H., Shakiba, M., Dakhilalian, M., and G.
                Bagherikaram, "New Results on Impossible Different
                Cryptanalysis of Reduced-Round Camellia-128", Lecture
                Notes in Computer Science, Vol. 5867, November 2009,
                <http://www.springerlink.com/content/e55783u422436g77/>.

   [NESSIE]     The NESSIE Project, "New European Schemes for
                Signatures, Integrity, and Encryption",
                <http://www.cosic.esat.kuleuven.be/nessie/>.











Hudson                        Informational                    [Page 12]
^L
RFC 6803           Camellia Encryption for Kerberos 5      November 2012


Appendix A.  Acknowledgements

   The author would like to thank Ken Raeburn, Satoru Kanno, Jeffrey
   Hutzelman, Nico Williams, Sam Hartman, and Tom Yu for their help in
   reviewing and providing feedback on this document.

Author's Address

   Greg Hudson
   MIT Kerberos Consortium

   EMail: ghudson@mit.edu







































Hudson                        Informational                    [Page 13]
^L