1. IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-09-0139-00-0sec
Title: TGa_Proposal_EAP_FRM_Comments
Date Submitted: Sept 02, 2009
Presented at IEEE a Teleconference Sept. 2009
Authors or Source(s):
Rafael Marin-Lopez (UMU), Fernando Pereñiguez(UMU), Fernando Bernal (UMU), Antonio F. Gomez (UMU)
Abstract: Answers to questions related with EAP-FRM. xx

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 xx

3. Comments about EAP-FRMxx

4. Removing P bit
If EAP lower-layer can indicate whether it is a pre-authentication or normal authentication, P bit in EAP-FRM is not needed.
P bit is used in case EAP lower-layer does not support proactive operation.
In any case, we do not have any problem to remove it xx

5. Removing User-Id
If user id is carried in each re-authentication protocol encapsulated in EAP-FRM payload, then why User-Id TLV is needed? For example, ERP defines keyName-NAI TLV.
EAP-FRM is designed to transport any FRP. In consequence, we need a way to provide AAA routing information in a generic way. Usually a NAI (as happens with EAP-Response/Id) is used.
If we choose a particular FRP in the context of a (e.g ERP-based FRP) the keyName-NAI TLV is enough. xx

6. Auth TLV and IK (I)
Normally each re-authentication protocol provides integrity protection. Why are Auth TLV and IK needed at EAP-FRM?
The reason is similar to the previous one . EAP-FRM is used to tranport any FRP . However, AUTH TLV (which uses IK) is something which is particular to EAP-FRM method and independent of the FRP. In fact, this AUTH TLV can be generated by the authenticator only when it receives the rMSK (or any other key material). xx

7. Auth TLV and IK (II) MN Candidate Authenticator (MIH PoS)
EAP-Request/FRM([P],FRP-Payload[IRS*])
EAP- Response/FRM ([P],
FRP-Payload[IR*])
EAP-Request/FRM ([P],FRP-Payload[FR*])
RADIUS Access-Request FRP-Id[ERP], FRP-payload-Attr[IR*])
RADIUS Access-Accept (FRP-Id[ERP], FRP-Payload-Attr[FR*],rMSK)
EAP- Response/FRM ([P],Context-Binding[
MN-MAC-Addr, CPoS-MAC-Addr], Auth)
EAP- Success () MN
(EAP Peer)
Candidate Authenticator (MIH PoS)
(EAP Auth.)
ER/AAA Server
Serving Authenticator xx

8. Default FRP There should be at least one mandatory supported FRP-Type.
If people agree, we could consider an ERP-based FRP as default FRP. xx

9. Why MSK’?
Why MSK needs to be derived from MSK’ instead of using MSK’ itself as MSK?
After performing EAP-FRM with a particular FRP, the authenticator receives a (r)MSK . If we finally need a IK to protect certain information in EAP-FRM exchange it has to be derived from the received (r)MSK. Thus, we believe it is not proper to use (r)MSK as root for IK derivation and then export it as the MSK. xx