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