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,

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.


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


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

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