| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hello Yoshi, Thanks very much for your response to my questions. I have follow up below. I need to fashion text so that others who read the document are less likely to encounter the same misunderstandings that I have had. I'll try to do that soon! But first, to emphasize one thing: I was not attempting to make a technical change to the spec. I was trying to clarify what was there so that it would conform to my understanding of what I thought it was supposed to already be saying. We should have a teleconference soon so that, if my understanding of the current spec is that far wrong, I can find out whether the current spec supports the proposal that I thought was already being supported -- namely using SPoS to distribute Kmgw to both TPoS and MN. > (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. " I thought that the figure was supposed to illustrate the non-EAP-based MIRK case. Now I have to go back and see how the same figure could illustrate both cases. In order to do this, I have to fully understand the EAP-based MIRK case, and I will look for the specification describing that. I guess it may be in 802.21a. >> 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". This points to another of my basic misunderstandings. I will review your earlier email and the appropriate parts of the base spec to correct this. >> 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. Do you mean to say that my proposal for deriving the media-specific key from the media-independent key was not properly discussed within 802.21c? I thought that we did have the discussion. I also thought that it was a quite natural design. >> 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. I fully agree with your suggestion, and want to re-emphasize that I had hoped that my clarifications would fit that description. I'll try to be very careful to do so, but as I can see I need to gain some better understanding of what was already intended. Regards, Charlie P. |