| HIP | R. Moskowitz |
| Internet-Draft | X. Xu |
| Intended status: Standards Track | Huawei |
| Expires: February 4, 2017 | August 3, 2016 |
Hierarchical HITs for HIPv2
draft-moskowitz-hierarchical-hip-00.txt
This document describes using a hierarchical HIT to facilitate large deployments in mobile networks.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 4, 2017.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document expands on HIPv2 [RFC7401] to describe the structure of a hierarchical HIT, the Registry services to support this hierarchy, and given a hierarchical HIT, how a peer is found in the network.
A separate document will further expand on the registry service and how a device can advertise its availability and services provided.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
For HIP to be successfully used in mobile networks, it must support an Identity per person, or upwards to 10 billion Identities. Perhaps a Distributed Hash Table [I-D.irtf-hiprg-dht] can scale this large. There is still the operational challenges in establishing such a world-wide DHT implementation and how RVS [I-D.ietf-hip-rfc5204-bis] works with such a large population.
Even though the probability of collisions with 7B HITs in a 96 bit flat address space is 3.9E-10, it is still real. How are collisions managed? It is also possible with weak key uniqueness, as has been shown in deployed TLS certificates, results in a much greater probability of collisions. Thus resolution of collisions needs to be a feature in a globally mobile network.
An RVS provider may only what to provide discovery services to HIP clients it knows and trusts. A flat HIT space does not provide any intrinsic functionality to support this. A hierarchical HIT space can be mapped to the RVS provider.
The Hierarchical HIT is a small but important enhancement over the flat HIT space. It represents the HI in only a 64 bit hash and uses the other 32 bits to create a hierarchical administration organization for HIT domains. Hierarchical HITs are ORCHIDs [RFC7343]. The change in construction rules are in Section 4.1.4.
A Hierarchical HIT is built from the following fields:
The Hierarchy ID (HID) provides the structure to organize HITs into administrative domains. HIDs are further divided into 2 fields:
The RAA is a 14 bit field (16,384 RAAs) assigned sequentially by a numbers management organization, perhaps ICANN. An RAA must provide a set of services to allocate HDAs to organizations. It must have a public policy on what is necessary to obtain an HDA. The RAA need not maintain any HIP related services. It must maintain a DNS zone for discovering HID RVS servers.
This DNS zone may be a reverse PTR for its RAA. Assume that the RAA is 100. The PTR record is constructed at a 2 bit grouping:
1.3.1.0.0.0.0.arpa IN PTR raa.bar.com.
The HDA is an 18 bit field (262,144 HDAs per RAA) assigned sequentially by an RAA. An HDA should maintain a set of RVS servers that its client HIP-enabled customers use. How this is done and scales to the potentially millions of customers is outside the scope of this document. This service should be discoverable through the DNS zone maintained by the HDA's RAA.
An RAA may assign a block of values to an individual organization. This is completely up to the individual RAA's published policy for delegation.
HID related services should be discoverable via DNS. For example the RVS for a HID could be found via the following. Assume that the RAA is 100 and the HDA is 50. The PTR record is constructed at a 2 bit grouping:
2.0.3.0.0.0.0.0.0.1.3.1.0.0.0.0.arpa IN PTR rvs.foo.com.
ORCHIDv2 has a number of inputs including a context, some header bits, the hash algorithm, and the public key. The output is a 96 bit value. Hierarchical HIT makes the following changes. The HID is added as part of the header bits and the output is a 64 bit value, derived the same way as the 96 bit hash.
Hierarchical HIT uses the same context as all other HIPv2 HIT Suites as they are clearly separated by the distinct HIT Suite ID.
The 64 bit hash size does have an increased risk of collisions over the 96 bit hash size used for the other HIT Suites. There is a 0.01% probability of a collision in a population of 66 million. The probability goes up to 1% for a population of 663 million. See Appendix A for the collision probability formula.
This risk, however, is within a single HDA. Further, all HDAs are expected to provide a registration process for reverse lookup validation. This registration process would reject a collision, forcing the client to generate a new HI and thus hierarchical HIT and reapplying to the registration process.
The HIP parameters carry information that is necessary for establishing and maintaining a HIP association. For example, the peer's public keys as well as the signaling for negotiating ciphers and payload handling are encapsulated in HIP parameters. Additional information, meaningful for end hosts or middleboxes, may also be included in HIP parameters. The specification of the HIP parameters and their mapping to HIP packets and packet types is flexible to allow HIP extensions to define new parameters and new protocol behavior.
The HIT_SUITE_LIST parameter contains a list of the supported HIT suite IDs of the Responder. Based on the HIT_SUITE_LIST, the Initiator can determine which source HIT Suite IDs are supported by the Responder. The HIT_SUITE_LIST parameter is defined in Section 5.2.10 of [RFC7401].
The following HIT Suite IDs are defined for Hierarchical HITs, and the relationship between the four-bit ID value used in the OGA ID field and the eight-bit encoding within the HIT_SUITE_LIST ID field is clarified:
HIT Suite Four-bit ID Eight-bit encoding ECDSA/hier/SHA-256 4 0x40
Note that the Hierarchical HIP HIT Suite ID allows the peers to use the hierarchical RVS discovery and authentication services to validate the peer and discover available services. The Responder SHOULD respond with a HIP hierarchical HIT suite ID when the HIT of the Initiator is a HIP hierarchical HIT.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Client Information /
/ /
/ +-------------------------------+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [TBD-IANA]
Length length in octets, excluding Type, Length, and
Padding
Client The information required by the HDA in the format
Information required by the HDA.
This parameter contains client information to include in the HIT registration. The specific content and format is set by the HDA.
Hierarchical HIT registration SHOULD be performed using the HIP Registration Extension [I-D.ietf-hip-rfc5203-bis]. The client either uses an X.509 certificate [I-D.ietf-hip-rfc6253-bis], or use a PSK, as defined in Appendix A of HIP-DEX [I-D.ietf-hip-dex], to validate the registration.
The Registration should include additional client information. This information may be contained within the X.509 certificate and/or is carried in the CLIENT_INFO parameter, see Section 5.2. The Registrar can include its requirements in the R1 packet, and the client provide its information in the I2 packet. This parameter may be encrypted within the ENCRYPTED parameter. If the CLIENT_INFO contains Personal Identifying Information (PII), then it MUST be placed into the ENCRYPTED parameter.
The content and internal format of the CLIENT_INFO parameter is set by the HDA's policy and is outside the scope of this document. Examples of client information can by phone number, IMEI, and ICCID.
This requires the HIP client to possess a client certificate trusted by the HDA/Registrar. Registration will either succeed or fail.
This requires the HIP client and the HDA/Registrar to share a PSK. The PSK may already exist prior to starting the registration and just be used within the registration. A PSK out-of-band exchange may be triggered by performing the registration without any authentication.
If no client authentication is included in the I2 packet, the registration fails with "No Authentication provided". If the I2 packet included the proper HDA required client information, the HDA can use it to set up a side channel for an out-of-band delivery of a PSK. And example of this would be to send an SMS message with the PSK. Once the client possesses the PSK, it can rerun the registration at which point the HI and HIT duplicate checks are performed.
The Registration Type used in the REG_REQUEST is:
Number Registration Type
------ -----------------
2 HIT Registration
The Registration may fail. In fact, with PSK, this may be the response to expect an SMS message with the PSK to use in a second registration request. Failure Types used in the REG_FAIL are:
Failure Type Reason
------------ -----------------------
[TBD-IANA] Hierarchical HIT Already Registered
[TBD-IANA] HI Already Registered
[TBD-IANA] Previously Registered HI with different device information
[TBD-IANA] No Authentication provided
[TBD-IANA] Invalid Authentication
[TBD-IANA] Invalid Authentication, new PSK sent via SMS
If the failure type is "Hierarchical HIT Already Registered", the client's HI is hashing to an existing HIT and must generate a new HI and hierarchical HIT and reregister. If the failure is "HI Already Registered", the client should assume it is registered. If the failure is "Previously Registered HI with different device information", either the client managed to generate a duplicate HI, probably indicating a weak key generation algorithm, or the client was previously registered on a different device. Resolving this conflict will be left to the HDA's policy.
All HIP clients with hierarchical HITs maintain an RVS connection with their HDA's RVS server(s). How the HDA scales this service up to a potential population in the millions is out of scope of this document. Lifetime management of these connections is also out of scope.
A service Initiator uses some service to discover the HIT of the service Responder. The Initiator uses the hierarchical information in the HIT to find the Responder's RVS. An I1 is sent to that RVS which forwards it to the Responder.
The potential Responder uses the HIT in the I1 to query the Initiator's RVS about the Initiator. The nature of information, and method of communication are determined by the Initiator's HDA and the Responder's (and or HDA's) relationship with it. Based on the Responder's local policy, this information will be used to determine if the contact is to be accepted. If accepted, the Responder may proceed sending an R1 to the Initiator. It may alternatively initiate some non-HIP process.
It should be noted that this R1 may contain a REG_INFO list for the Initiator to validate that the Responder does offer the desired service.
The following change to the "Host Identity Protocol (HIP) Parameters" registries has been made:
Introducing the RAA management organization may be the largest hurdle for hierarchical HITs. Thus it would be best if this were adopted by an organization already in the business of allocating numbers within either the Internet or the Mobile, cellular, infrastructure.
One consideration would be to reserve the first N RAA values to map to the existing DNS TLDs. For example, these TLDs can be organized in an ascending order and numbered accordingly. Thus the 2 character TLDs will be a lower number than the 3 character TLDs. After that, it could be a first come, first numbered assignment process.
There are potential risks with the hierarchical HIT, the Registry service, and the discovery of potential peer using its hierarchical HIT.
The two risks with hierarchical HITs is the use of an invalid HID and forced HIT collisions. Use of the hhit.arpa. DNS zone is a strong protection against invalid HIDs. Querying an HDA's RVS for a HIT under the HDA protects against talking to unregistered clients. The Registry service has direct protection against forced or accidental HIT hash collisions.
By using the HIP Registration Extension, the Registry service is protected from direct attacks. This service does rely on either the integrity of a PKI service or an out-of-band PSK delivery process. Thus the risk to the Registry service is highly related to the trust in these authentication setup services. Further, the duplicate HI resolution process may require human interaction with related social engineering risks.
Finally the peer discovery process relies on trusting the finding the proper HDA for the peer and its forwarding the I1 to the proper Responder. A rogue RVS, impersonating the RVS for the HIT, could redirect the I1 to a client that has forced a collision with the HIT and the Initiator would be none the wiser. The only defense against this is if the Initiator has some other source for the Responder HI and validate the HI in the R1.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [I-D.ietf-hip-dex] | Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", Internet-Draft draft-ietf-hip-dex-03, June 2016. |
| [I-D.ietf-hip-rfc5203-bis] | Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", Internet-Draft draft-ietf-hip-rfc5203-bis-10, January 2016. |
| [I-D.ietf-hip-rfc5204-bis] | Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", Internet-Draft draft-ietf-hip-rfc5204-bis-07, December 2015. |
| [I-D.ietf-hip-rfc6253-bis] | Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", Internet-Draft draft-ietf-hip-rfc6253-bis-09, July 2016. |
| [I-D.irtf-hiprg-dht] | Ahrenholz, J., "Host Identity Protocol Distributed Hash Table Interface", Internet-Draft draft-irtf-hiprg-dht-05, December 2011. |
| [RFC7343] | Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 2014. |
| [RFC7401] | Moskowitz, R., Heer, T., Jokela, P. and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015. |
The accepted formula for calculating the probability of a collision is:
p = 1 - e^{-k^2/(2n)}
P Collision Probability
n Total possible population
k Actual population