IEEE MEDIA INDEPENDENT HANDOVER DCN: sec

Slides:



Advertisements
Similar presentations
1 IEEE MEDIA INDEPENDENT HANDOVER DCN: sec Title: ERP proposal Date Submitted: October 11, 2011 Authors or Source(s): Fernando Bernal-Hidalgo,
Advertisements

1 IEEE MEDIA INDEPENDENT HANDOVER DCN: sec Title: Message Flow Date Submitted: March 1, 2011 Authors or Source(s): Fernando Bernal-Hidalgo,
1 IEEE MEDIA INDEPENDENT HANDOVER DCN: sec Title: ERP proposal Date Submitted: October 13, 2011 Authors or Source(s): Fernando Bernal-Hidalgo,
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN: srho
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER DCN: xxx
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER DCN: srho Title: Proactive Pull Key Distribution for IEEE c Date Submitted: November 4, 2011.
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: xx-00-sec
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN: xxx
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: xx-00-sec
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: MuGM
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: xxx
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN: xx-00-sec
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: xxx
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN: xxxx
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: xx-00-sec
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER DCN: xx-00-sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: xx-00-sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Group management in MIHF Date Submitted: November 4, 2011 Presented at IEEE session #47 in Atlanta.
IEEE MEDIA INDEPENDENT HANDOVER DCN: xx-00-sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Your Title Here
21-06-xxx-LocInfo_in_IS_request
IEEE MEDIA INDEPENDENT HANDOVER DCN: xx-00-sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: mugm
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
Presentation transcript:

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 802.21a 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. 21-04-00xx-00-0021

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 <http://standards.ieee.org/guides/opman/sect6.html#6.3> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html>  21-04-00xx-00-0021

Comments about EAP-FRM 21-04-00xx-00-0021

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 21-04-00xx-00-0021

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 802.21a (e.g ERP-based FRP) the keyName-NAI TLV is enough. 21-04-00xx-00-0021

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). 21-04-00xx-00-0021

Auth TLV and IK (II) MN Candidate Authenticator (MIH PoS) EAP-Request/FRM([P],FRP-Payload[IRS*]) EAP- Response/FRM ([P], User-Id[EMSKname@domain], FRP-Payload[IR*]) EAP-Request/FRM ([P],FRP-Payload[FR*]) RADIUS Access-Request (User-Name[EMSKname@domain],FRM-Flags[P], 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 21-04-00xx-00-0021

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. 21-04-00xx-00-0021

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. 21-04-00xx-00-0021