Comments on Secure Key Distribution contribution and SRHO document
Dear Charles, all,
please find inline comments to your questions attached to your last
email of .21c. The ones explicitly addressed to the Secure Key
Distribution contribution have been crosschecked with Rafael and
Yoshihiro.
I will try to do an update of our document and upload it to mentor today.
BR
Antonio
>> 6.5.1 Information Element ---> 6.5.1 Information Elements
>> defined --> as defined for
>>Table 1:
>>IE_NET_CAPABILITIES
>>This is a good idea. Is it expected to have a
>>separate document per access network media type?
[AO]: The different capabilities are defined in table F13 on .21 spec
and in table A1 in SRHO doc. They are high level capabilities
supported by the network, such as Security, Emergency Services etc..
>>IE_SFF_TUNN_MGMT_PRTO
>>What are the likely possibilities? Is GRE the default?
[AO]: Also defined on table A.1, right now it says only IP
>>MIHF_ID: is it a FQDN?
[AO] MIHF_ID is defined in table F3.11 of current .21 spec. I am
copying the definition here:
"The MIHF Identifier: MIHF_ID is a network access identifier (NAI).
NAI shall be unique as per IETF RFC 4282. If L3 communication is used
and MIHF entity resides in the network node, then MIHF_ID is the fully
qualified domain name or NAI-encoded IP address (IP4_ADDR or IP6_ADDR)
of the entity that hosts the MIH Services. If L2 communication is used
then MIHF_ID is the NAI-encoded link- layer address (LINK_ADDR) of the
entity that hosts the MIH ser- vices. In an NAI-encoded IP address or
link-layer address, each octet of binary-encoded IP4_ADDR, IP6_ADDR
and LINK_ADDR data is encoded in the username part of the NAI as ““\””
followed by the octet value. A multicast MIHF identifier is defined as
an MIHF ID of zero length. When an MIH protocol message with multicast
MIHF ID is transmitted over the L2 data plane, a group MAC address
(01-80-C2- 00-00-0E) shall be used (see IEEE P802.1aj/D2.2). The
maximum length is 253 octets.""
So, it can be a FQDN, but it does not need to.
>> SFF_ID: is it a FQDN?
[AO]: As defined in table F3.16 of .21c document, it is either an IP
address or an MIHF_ID. Hence same comment as before applies.
>>7.4.29.1.3 When generated
>> ... should it be to start pre-registration at tPoS?
[AO]: No in my opinion, the registration process with PoSs in .21 is
handled through other kind of mechanisms, this is not the purpose of
the primitive.
>>"must rely" --> "must relay"
[AO]: Agree
>>8.6.3.26 MIH_N2N_LL_Auth request:
>> "Section (must be section)"
[AO]: ok
>>Should instances of SFF be changed (to something related to "Mobility Gateway")?
>> idea: "MIMG" for Media-Independent Mobility Gateway
[AO]: Must be discussed, I think it is a good idea, since SFF is the
specific name for WiMAX, is not it?
>>Section 9.2:
>> The MIRK and the MIHF identifier of the MN that holds the MIRK are
>> used as the symmetric key credentials for a symmetric key based EAP
>> method
>>Does it have to be EAP? What happens if 802.21c passes the key as part of
>>the LL_TRANSFER_REQ?
[YO, RM, AO]: As far as I understand, the key hierarchy defined in
802.21a security framework is based on EAP. So yes, it has to be EAP.
>>Section 9.2.2.1:
>> Is the XOR-based delivery and derivation suggested previously
>> a feasible alternative?
[YO, RM, AO]: Since the 802.21a key derivation algorithm derives
multiple keys from
a single root key, the XOR-based key derivation cannot be used as long
as the solution is based on 802.21a.
>>Section 9.2.2.2
>> What is the origin of the algorithmic formulae on page 24?
[YO, RM, AO]: It is based on 802.21a key derivation algorithm. We
only changed the
key label to differentiate from other child keys that have the same
root key.
>> Compromising SPoS only compromised the key for MN on TPoS, not
>> any other data on TPoS.
[YO, RM, AO]: If sPoS is compromised, the MIRK transferred to the tPoS and all
child keys derived from the MIRK will be compromised. This is a
well-known issue so called "domino effect", and the issue is already
mentioned in 9.2.2.2 of DCN 21-12-0020-03.
[AO]: Next comments are from sections that I did not touch, will let
the editor and contributors work on them
>>Section 11.4.2
>> Need more precise citation for ANDSF
>> "If the target POA’s are legacy POA’s lacking MICF support, the M-GW will
>> need other communication mechanism in order to proxy between the MN and
>> the target POA."
>>Wouldn't any such "other" mechanism qualify for "MICF support"?
>>Figure 9.7:
>>(1) First sentence is declarative. (?)
>>As a more general point, can 802.21(c) support a SPoS MIGW function by
>>which the network identifies a candidate target network? If so, then we
>>could have the following sequence:
>>- MN requests handover by sending Handover Request message to source MIGW
>> = parameter specifies appropriate RAT(s)
>> = optional parameters for policy constraints
>>- source MIGW consults location database, inserts appropriate IEs to MN's
>> Handover Request message
>>- Upon reply by target PoS/MIGW, source MIGW appends appropriate information
>> about target PoS/PoA to Handover Response message destined for MN
[AO]: Tend to agree, although I do not think this diagram expect to be
a general diagram covering all possibilities
>>"target radio is of" --> "target radio has"
>>"POA" --> "PoA" [?? (a global change)]
>>Proposal: change instances of ANDSF to be ALDB (Access Location Database)
>>except in places where the 3GPP module is explicitly intended.
>>Section 11.6.4.1
>>--> A good example of where OSFF (or SPoS or "source MIGW") should be allowed
>> to identify the target network on behalf of the MN, in contrast to the
>> statement:
>> "If the MN does not know the IP address of the target 3GPP eNB,
>> it will need at least something, such as the link-layer address,
>> to identify the target 3GPP eNB."
[AO]: I think the sPoS should be able to select the target network,
this is something the .21 base spec allows and should be possible also
in .21c
>>Various figures, e.g., Figure 9.24:
>>Signaling is shown between the MN and the source network
>> before the handover. OK.
>>Signaling is shown between the MN and the target network
>> after the handover. OK.
>>Signaling is shown between the MN and the network infrastructure
>> DURING handover. For a single radio MN, how can this be??
>> Should these be labeled "When Initiating Handover"...?
>>Section 11.7.:
>> Reviewed and generally seems good, but terminology probably
>> needs to be updated. I'll try to submit a revised figure very soon.
>>Annex N.6 also reviewed. Seems pretty good. I'll review again to ensure
>> consistency of detail.
[AO]: OK thanks
>>An example is needed for particular network utilization, along the lines
>>of particular examples in, for example, sections 11.
[AO]: Agree, but first lets define how to do the HO with .21c..
BR
Antonio
--
Antonio de la Oliva
Visiting Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax: +34 91 624 8749