It is useful for 802.21c to be easy to understand.
The next scheduled teleconference for 802.21c is on August 29 at 9PM ET.
From: Charles E. Perkins [mailto:charles.perkins@xxxxxxxxxxxxx]
Sent: Friday, August 24, 2012 3:58 PM
To: STDS-802-21@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-21] Heavily revised call flow example
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.