1. IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-09-0142-00-0sec
Title: Answers to comments
Date Submitted: Sept 12, 2009
Authors or Source(s): Subir Das (Telcordia Technologies Inc.)
Re: Session #34, Big Island, Hawaii, USA
Abstract:
This document attempts to answer the comments that are received against proposal sec

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 outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual < and in Understanding Patent Issues During IEEE Standards Development
IEEE 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
sec

3. Comment #1
Section You mention there is a list of PoA link addresses and a list of MN link addresses. Having that, how are keys derived? I mean for each MN link address we derive a key beforehand per each PoS link address or how?. Also, you mention only link address and I would say it could be an AR the media specific authenticator so IP address should be considered. - Another comment is if we are using .21 IS the MN could know the PoA link layer addresses under that candidate PoS no?
Answer
Section 3.4 describes the key generation algorithm whereby POA link address and MN link addresses are used
MS-PMK =KDF(MI-PMK, “MS-PMK” | MN_LINK_ID | POA_LINK_ID | length)]
Keys are generated after successful authentication
The POA-Link-Addr-List and MN-Link-Addr_List are represented as LIST(Link_ID) and the link end point in IEEE is L2 end point
Yes, MN can know the POA link layer address via IS
sec

4. Comment #2 Figure 5 Answer
Are last pro-auth request and response (at least) integrity protected?. I guess this is related to IC TLV. But I think I failed to see how the IC TLV is generated and what key is used. Another comment is: could the candidate authenticator initiate the pre-authentication instead of serving?
Answer
Initial pro-auth request and response messages are not integrity protected
Yes, you are right that IC TLV description is missing. Added them in sec and also IC TLV is defined (reference slide #36)
Yes, candidate authenticator can initiate the pre-authentication
sec

5. Comment #3 Figure 13 Answer
how is it supposed to work pull mechanism? One option is that the media target MSA makes a fast re-authentication to obtain a key in a pull fashion.  That is , the EAP authenticator is the target MSA the mobile is the EAP peer, and the MIH authenticator is acting as EAP server for this re-authentication. (Note that if EAP-FRM is used the MIH authenticator is acting as key distribution server since it is not involved in the EAP signaling). In this case the MSA won't need to accept a key in push fashion, only in pull way, which is the most common method in current MSAs.
Answer
Yes, the model of having MIA-KH an EAP server, MSA-KH as pass through authenticator and MN as EAP peer, the pull mechanism would work
For push things seem to be complex since it needs media support
sec

6. Comment #4 Page 38 Answer How is IC TLV generated?.
IC TLV is a TLV of type OCTET_STRING carrying within an MIH proactive authentication message. Please refer to sec, slide #36
sec