Re: [STDS-802-21] Heavily revised call flow example
Hi Peter,
(2012/08/28 22:57), Peter McCann wrote:
(snip)
>>> If not then, then when? After handover has taken place?
>>
>> Access authentication happens proactively, specifically when EAP is
>> exchanged over MIH_LL_Transfer.
>
> But this has to happen after Charlie's callflow runs, and the MSRK is
> generated and distributed to the TPoS and MN, right?
Yes, it has to happen after the call flow in Charlie's figure.
BTW, Annex N of 802.21c draft has four figures, and the 2nd and 4th
ones depict proactive authentication over MIH_LL_Transfer.
Yoshihiro Ohba
>
> -Pete
>
>>
>> Yoshihiro Ohba
>>
>>
>>>
>>> -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.
>>>>>
>>>
>>>
>>>
>>>
>
>
>
>