| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hello
folks,
I
have made great progress after the recent discussions. I have
some more
suggestions and additional questions. -
My current understanding about nomenclature is that
"internal signaling" in the signaling diagrams uses the '.'
(as in MIH_LL_Transfer.indication"), and inter-node
signaling does not (as in MIH_N2N_LL_Transfer Request). -
To emphasize this, I will use lower-case for the '.'-ed
"signaling"
and upper case for the actual inter-node signaling messages,
e.g "MIH_LL_Transfer.request" vs. "MIH_N2N_LL_Transfer
Request" -
Looking at Figures 14, 15, and 16 in document
"802.21-2008-Updated",
I find mention of, e.g., "REQUEST FRAME". I understand this to
mean <MIH protocol header> as in Figure 21, with Opcode
= 1.
There does not seem to be any explicit definition of the terms
"REQUEST FRAME" or "RESPONSE FRAME", nor any use of an
analogous "INDICATION FRAME". -
I have added another "fat bar" to the signaling diagram N.6.1
to
indicate the continuing process of preregistration. -
Note: must include TPoS PoS's address IE in description -
Having finally read section 10.2.1 in document 802.21a, I see
that
what I was calling MSRK should really have been called MSPMK.
MIRK
in 802.21c is the same as denoted MSK (rMSK) in Figure 47. The
goal in 802.21(c) should be to maintain compatibility with the
key derivation hierarchy in Figure 47. To this end, I propose:
= MSPMK be derivable from MIRK by the (already specified)
algorithm
which can be computed by both TPoS and MN.
= MISK be also computed from MIRK as specified in section
9.2.2
(presumably including MIAK, MIEK, MIIK as needed by TPoS/TPoA) -
In Figure 44, section 10.2.1,
is it intended that each of MSPMK_a and MSPMK_b are to be used
by
different candidate target PoSs? -
Which key will be used by MN for authentication with TPoA
during
handover execution? Is it MIAK or MSPMK? -
Is there any need for MSRK to be different than MSPMK in the
case
where there is only one candidate TPoS? In order to compute
MSPMK as specified, MN_LINK_ID is required. Can this be the
same
as MNnetworkaccessID? -
It is intended that MN may keep its security association with
TPoS
for the entire lifetime of the security association. I think
that
the terminology MIRK is preferable to 'K' as shown in Figure
47. -
Is the method in 802.21c for symmetric key distribution also
called
"bundled" proactive authentication? If so that term should be
referenced in the 802.21c SRHO document section 11.6 -
For the authentication specified in section 11.6, the MN can
rely
on SPoS to identify the TPoS. This requires some changes to
the
language in section 10.1.1.1. Also changes in section 9.2.1. -
Need to specify a new IE or TLV for the SPoS to use
when sending MIRK to TPoS and to MN. Also need IE to identify
radio access technology type, but this may already exist. -
General idea:
= SPoS sends the following to TPoS
* MN_ID to TPoS
* Nonces
* MIRK in a new IE or TLV
= TPoS derives MISK=(MIAK | MIIK | MIEK) and MSPMK
* sends MSPMK to TPoA in a media-specific container
* sends MIH_N2N_LL_transfer Response to SPoS
* sends MNnetworkaccessID to SPoS
= SPoS sends the following to MN
* TPoS_ID
* MNnetworkaccessID
* Nonces
* MIRK in a new IE or TLV ========================================================= In
a few minutes, I will send out a substantially updated
signaling diagram incorporating
some of the above ideas, with new descriptive text. Your
comments and suggestions are greatly appreciated. Regards, Charlie
P. |