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.