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]

 
RFC 6803           Camellia Encryption for Kerberos 5      November 2012



.  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.


.  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 type