RE: [STDS-802-21] Heavily revised call flow example
Hi, Yoshi,
Yoshihiro Ohba wrote:
> Hi Peter,
>
> Sorry for missing to answer some questions.
>
> Please see below.
>
> (2012/08/28 0:49), Peter McCann wrote:
>> 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?
>
> SPoS obtains MNID from MIH_LL_Transfer request message sent by the MN.
Ok, is this the NAI that was used for MIH authentication in the
first access network? Is it possible that this identifier was
previously generated by the SPoS during an MIH handover from a
previous SPoS?
>>>>> From where does the TPoS get the MNnetworkAccessId to send
>>>> back to SPoS?
>
> TPoS will assign it, as described in Annex P of 802.21c draft:
>
> "An MNnetworkaccessid attribute (of type NAI), which is optionally
> contained in MIH_LL_Transfer.response, MIH_LL_Transfer.confirm,
> MIH_N2N_LL_Transfer.response, and MIH_N2N_LL_Transfer.confirm
> primitives, is assigned by the target PoS to the MN such that the MN
> can use the value of this attribute as the EAP peer identity for
> subsequent reactive pull key distribution or optimized pull key
> distribution from the target PoS. The username part of the NAI
> carried in this attribute may contain the identifier of the MSRK used
> between the MN and the target PoS, and the realm part of the NAI may
> contain a Fully Qualified Domain Name of the target PoS."
Thanks, I understand now that this is a temporary NAI generated by
the target network.
>> 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?
>
> Yes.
>
>>
>>>> Would this happen after the call
>>>> flow that you have drawn?
>>>
>>> No.
>>
>> 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?
-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.
>>>>
>>
>>
>>
>>