RE: [STDS-802-21] Heavily revised call flow example
Hi, Yoshi,
Yoshihiro Ohba wrote:
> Hi Pete,
>
> (2012/08/25 3:23), Peter McCann wrote:
>> Yoshi said that MNID and MNnetworkAccessId are not the same.
>>
>>> From where does the SPoS get the MNID to send to TPoS?
>>>
>>> From where does the TPoS get the MNnetworkAccessId to send
>> back to SPoS?
Anyone care to answer that question? This is what I am most
concerned about.
>> I am confused about how MIRK and MSRK relate to the access
>> authentication. Does access authentication take place over
>> MIH_LL_Transfer, possibly in multiple round-trips, using MSRK as the
>> MN-AAA Shared Secret?
>
> Yes.
Ok. Does this involve running an EAP exchange over MIH_LL_Transfer?
>> Would this happen after the call
>> flow that you have drawn?
>
> No.
If not then, then when? After handover has taken place?
-Pete
>
> Yoshihiro Ohba
>
>>
>> -Pete
>>
>>
>> Charles E. Perkins wrote:
>>>
>>> Hello folks,
>>>
>>> Here is a replacement for the first signaling diagram in existing
>>> Annex N. Please review it for understandability and accuracy. I
>>> have changed a lot of things. Foremost, I clarified the algorithm
>>> for distributing MNmsrk. What the diagram shows is that MNmsrk is
>>> computed from MNmirk.
>>>
>>> More specifically:
>>>
>>> T_pos extracts MNmirk in message received from S_pos.
>>>
>>> T_pos computes MNmsrk from MNmirk
>>>
>>> T_pos distributes MNmsrk to T_poa
>>>
>>> T_pos returns MNnetworkaccessID to S_pos
>>>
>>> S_pos sends MNnetworkaccessID and MNmirk to MN
>>>
>>> MN computes MNmsrk from MNmirk using same well-known
>>> algorithm used by T_pos.
>>>
>>> I know this is a possible way to make the preauthentication.
>>> I reckon it is compatible with the intention of the rest of the
>>> document in the way that functionality and naming are designed for
>>> S_pos, T_pos, T_pos, etc. -- but I'd really appreciate separate
>>> verification of that.
>>>
>>> I also redrew the signaling diagram to better display what I think
>>> was intended, and supplying parameters according to the above
>>> algorithm for distributing MNmsrk etc.
>>>
>>> I hope the example is:
>>> - accurate
>>> - clear
>>> - consistent with previous 802.21(c) design
>>>
>>> The algorithm for computing MNmsrk from MNmirk *could* be media-
>>> specific. I can design a media-independent algorithm to be used in
>>> other cases when no media-specific algorithm has been mandated, but
>>> somehow it seems likely that a media-specific key such as MNmsrk
>>> would be computed by a media-specific algorithm. Notably, if it is
>>> required to compute MNmsrk without regard to the value of MNmirk,
>>> then the above method is incomplete or maybe even broken.
>>>
>>> Your comments will be very much appreciated. If I have this
>>> correctly, I will try to complete the document revision tomorrow.
>>> Visio does work. I am not going to spend much time on the long Annex
>>> containing the use cases for handovers between WiFi and WiMAX, etc.,
>>> at least not before getting this revision to a consistent state worthy
>>> of consideration by the 802.21 task group.
>>>
>>>
>>> Regards,
>>> Charlie P.
>>