Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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.
>>>>>
>>>
>>>
>>>
>>>
> 
> 
> 
>