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



 
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.