1. IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-13-0047-00-0000 Title: On padding method of AES-CBC Date Submitted: January, 17th, 2013 Presented at IEEE 802.21 session #55 in Orland Authors or Source(s): Yoshikazu Hanatani, Toru Kambayashi (Toshiba) Abstract: This is a material to discuss that 802.21m should specify a padding method of AES-CBC or not. 21-13-0047-00-00001

2. IEEE 802.21 presentation release statements This document has been prepared to assist the IEEE 802.21 Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.21. The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html> Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3 http://standards.ieee.org/board/pat/guide.html IEEE 802.21 presentation release statements This document has been prepared to assist the IEEE 802.21 Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.21. The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf> Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#6 http://standards.ieee.org/board/pat/faq.pdf 21-13-0047-00-00002

3. AES-CBC-128 21-13-0047-00-00003 AES Enc P1P1 P2P2 P3P3 C1C1 C2C2 C3C3 A length of plaintext must be a multiple of 16 octets. If a plaintext is not a multiple of 16 octets, we cannot encrypt the plaintext without a padding method. IV

4. Plaintext Various Padding Method ZeroByte padding PKCS#5 padding (RFC1423) ISO10126 padding SSL3 padding 21-13-0047-00-00004 Sender and Receiver need to share a padding method, but the padding method is not secret information. Padding Ciphertext Plaintext Padding Decryption using a symmetric key Remove padding part

5. Padding methods in IEEE 802.21a AES-CCM CCM mode provides a padding method. AES-CBC CBC mode in 21a does not clearly specify a padding method. 9.3.4.2.1: Encapsulation “b) Pad the plaintext, P, to a length of a multiple of 16 octets (128 bits) so that the padded plaintext can be represented as in n blocks P0, P1,.., Pn-1, each of which is 16 octets.” “d) … Here padding may be needed to make the input message length to be a multiple 64 octets (512 bits). The most significant 12 octets of the output of HMAC-SHA1 is the MIC.” 9.3.4.2.1: Decapsulation “c) …Here padding may be needed to make the input message length a multiple 64 octets (512 bits)….” “e) Remove the padding if it is applied to obtain the plaintext, P.” 21-13-0047-00-00005 Should we specify a padding method for AES-CBC?

6. On Reply attack resistance AES-CCM in IEEE 802.21a An initial vector (IV) is generated from a sequence number of SA and a part of MIH header. We can prevent a reply attack by checking the sequence number. AES-CBC in IEEE 802.21a The IV is randomly chosen. (Sec. 9.3.4.1) To prevent a reply attack, MN should hold all used IVs, and check them. 21-13-0047-00-00006 Can we achieve the reply attack resistance using AES-CBC? Some textbook denotes “CBC-mode is insecure if IVs are a constant number or counter numbers.”

7. Typo? ASCII code in “9.2.2 Key derivation and key hierarchy” is failed. ASCII code of “MISK” is described as “0x4D495354”, but it should be “0x4D49534B” 21-13-0047-00-00007