Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Heavily revised call flow example



(2012/08/24 7:37), 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

MNmirk is not always carried.  According to 8.6.3.25, "An MNmirk and a
SALifetime are carried if and only if non-EAP-based MIRK is used and
the encrypted Ktmgw has not been distributed to the 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
> 

I think the new figures mixed up with primitives and messages.
Messages should not use ".request" like primitive notations with
"dot"(.) signs. For example, step 2 should be "MIH_Transfer request"
instead of "MIH_Transfer.request".


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

This is basically a technical proposal.  We need more time to
discuss technical changes.

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

I really suggest separately discuss editorial changes and
technical changes, and focus on editorial changes
for the revision you plan to submit tomorrow.

Yoshihiro Ohba


> 
> Regards,
> Charlie P.