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

> Would this happen after the call
> flow that you have drawn?

No.

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