Queen Defender of the faith

Saturday, January 5, 2013

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

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 type

No comments: