1. IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-10-0026-00-sec
Title: Specifications for Security TLVs
Date Submitted: March 8, 2011
Present at IEEE March meeting
Authors: Lily Chen (NIST) and Yoshihiro Ohba (Toshiba)
Abstract: This document proposes a resolution on comment #193 and #194 in letter ballot 5a to add specifications on security TLVs for ciphersuites AES-CBC & HMAC-SHA1-96, Null & HMAC-SHA1-96, and Null & CMAC-AES.
xx-00-sec 1

2. IEEE 802.21 presentation release statements
This document has been prepared to assist the IEEE 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
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
xx-00-sec 2

3. What is the issue?
In D02, security TLV for EAP-generated MIH SA is only specified for the default cipher suite AES_CCM.
The security TLV shall be specified also for other ciphersuites, especially AES-CBC plus HMAC-SHA1-96.
This is important because we need to specify the order of encryption and authentication, the IV length, and the MIC length.

4. MIH PDU Protection by AES-CBC Plus HMAC-SHA1-96
Suggested text
Select a 128 bits (16 bytes) initiate vector (IV0, IV1, IV2, …, IV15).
Pad the plaintext P to a length of a multiple of 128 bits (16 octets) so that it can be presented in n blocks P0, P1, …, Pn, each of which is 128 bits.
Apply AES CBC on P0, P1, …, Pn to obtain ciphertext C0, C1, …, Cn*.
Input M=IV**||C0 ||C1||…||Cn to HMAC-SHA1, padding may be needed to make the length to be a multiple of 512 bits.
Obtain output H (160 bits). The most significant 96 bits of H is the MIC.
* It can use a cipher stealing method. In that case, the ciphertext may include a partial block.
**Suggest to add IV to the data to get integrity protection.

5. Security TLVs for AES-CBC plus HMAC-SHA1-96
IV + Ciphertext
( n octets)
MIC
(12 octets)
ENCR_BLOCK
INTG_BLOCK
Assumption: IV is contained in ENCR_BLOCK as suggested by LB5a Cmt #43

6. MIH PDU Protection by HMAC-SHA1-96
Suggested text
Pad the plaintext P to a length of a multiple of 512 bits (64 octets).
Input the padded plaintext to HMAC-SHA1-96.
Obtain output H (160 bits = 20 octets). The most significant 96 bits (12 octets) of H is the MIC.

7. Security TLVs for HMAC-SHA1-96
Plaintext
( |P|* octets)
MIC
(12 octets)
ENCR_BLOCK
INTG_BLOCK
* The length of plaintext in octets
Assumption: Plaintext is contained in ENCR_BLOCK as suggested by LB5a Cmt #43

8. MIH PDU Protection by CMAC-AES
Suggested text
Input M to CMAC-AES. CMAC-AES handles M in any length (the padding is specified as a part of the algorithm.
Obtain output H (128 bits). The most significant 96 bits (12 octets) of H is the MIC.

9. Security TLVs for CMAC-AES
Plaintext
( |M|* octets)
MIC
(12 octets)
ENCR_BLOCK
INTG_BLOCK
* The length of plaintext in octets
Assumption: Plaintext is contained in ENCR_BLOCK as suggested by LB5a Cmt #43

10. Change TLV for AES-CCM (Figure 41) to
SN + Ciphertext
(10 + |P|* octets)
MIC
(12 octets)
ENCR_BLOCK
INTG_BLOCK
* The length of plaintext P in octets