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



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?

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?  Would this happen after the call
flow that you have drawn?

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