Internet-Draft Pars Mutaf Expires: March 8, 2007 Institut National des Telecommunications Evry, France September 8, 2006 Human-regenerable IPv6 interface identifiers and addresses Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 8, 2007. Copyright Notice Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Abstract This document defines the human-regenerable IPv6 interface identifiers and addresses. They can be used when the services e.g. DNS and/or Mobile IPv6 home agent are down or unreachable, or when there is no Internet infrastructure in range. Mutaf Expires March 8, 2007 [Page 1] Internet-Draft Human-regenerable IPv6 interface identifiers June 2006 1. Introduction This document defines the human-regenerable IPv6 interface identifiers and addresses. They are constructed from easily remembered or guessed character strings input by the user, such as human name or pseudonym. This type of IPv6 addresses can augment the reachability of a host in some ad hoc scenarios, upon Domain Names System [DNS] and/or Mobile IPv6 home agent [MIP6] failures, or when there is no Internet infrastructure in range. 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 [RFC2119]. 2. Usage This document refers to the type of IPv6 addresses where the leftmost 64 bits of a 128-bit address form the subnet prefix and the rightmost 64 bits of the address form the interface identifier [IP6ARCH]. Human-regenerable addresses are based on a construct called HUMID (HUman-regenerable interface ID). HUMIDs are constructed by computing a cryptographic hash of an easily remembered or guessed character string, such as a "human name". For example, a hand-held personal device e.g. cellular phone or personal digital assistant can be given the HUMID constructed from its user's first and last names. In some cases, pseudonyms or other simple strings may also be used, depending on user imagination and needs. On the same link, a host can easily contact another host at its HUMID (modulo human typing erroneous name). The link-local prefix is constant, well-known and specified in [IP6ARCH]. A hosts on the same link can be reachable at its IPv6 address constructed as follows: 10 bits 54 bits 64 bits +----------+-------------------------+----------------------------+ |1111111010| 0 | HUMID | +----------+-------------------------+----------------------------+ <--------link-local IPv6 prefix-----><-------interface ID --------> (completed by the host) (human-generated) The HUMID interface identifier is constructed using the name input by the user, and the prefix is completed by host. The HUMID can be based on the user's first and last name, for example. The resultant address is human-regenerable. Any user who knows the name, can regenerate the same IPv6 address and reach the host. Similarly, the link-local prefix will be completed by the host. 2.1 Example scenario This mode of operation is best explained with an example scenario: At host configuration time, Alice is asked to enter her name (first name and last name) to her portable IPv6 device (a phone or personal digital assistant) equipped with ad-hoc mode wireless interface e.g. 802.11. The string is input to a cryptographic hash function, and the result is used as an interface ID (denoted HUMID). The HUMID is appended to the well-known link-local address prefix. The resultant IPv6 address is human-regenerable. Mutaf Expires March 8, 2007 [Page 2] Internet-Draft Human-regenerable IPv6 interface identifiers June 2006 Bernard, also equipped with a portable device operating in 802.11 ad-hoc mode, comes within wireless range of Alice. Bernard knows Alice's first and last names and can reconstruct Alice's IPv6 address in exactly the same manner and reach her. This may be the only way to reach Alice for example, if one of the services e.g. DNS or MIPv6 home agent is unreachable, or there is no Internet infrastructure in range. The procedure is stateless. Alice and Bernard do not need to pre-share their addresses. The HUMID can be constructed from scratch. This method can be prefered for its scalability. Another advantage is that the procedure is still applicable if this is the first time Alice and Bernard meet each other with their current devices. Or, Bernard can borrow a third (unknown) user's device and try to contact Alice where she is likely to be located (in a disaster scenario, for example). 2.2 Searching in multiple subnets Global-scope subnet prefixes (as defined in [IP6ARCH]) may also be used in some cases. This may help reachability to other subnets in the Internet. In some cases, Bernard may have obtained a list of subnet prefixes where Alice is likely to be located. Bernard's host may have obtained or learned the list of subnet prefixes that cover the geographical region, for example. Bernard may try to locate and contact Alice sending packets to Alice's HUMID at different subnet prefixes. Techniques for learning/obtaining a set of subnet prefixes are not specified in this document. 3. Constructing a human-regenerable IPv6 address The choice of the character strings used to generate a human-regenerable IPv6 address is left to the user. However, this document recommends some human name disambiguation techniques. It also specifies specifies the hash function to use, and the handling of address duplications. 3.1 Human name disambiguation recommendations Different users may enter the same character string in different ways. For example, the following human names may be entered in different ways by different users as: a/ Sang-hun Han Sang hun Han Sanghun Han sanghun han b/ Ahmed El-Sayed Ahmed El Sayed Ahmed el-sayed Ahmed el sayed c/ John Smith john smith Mutaf Expires March 8, 2007 [Page 3] Internet-Draft Human-regenerable IPv6 interface identifiers June 2006 d/ Jean-Francois Le Roux Jean Francois Le Roux jean-francois le roux jean francois le roux Jean-Francois Leroux Jean Francois Leroux jean-francois leroux jean francois leroux A user cannot be reproached for entering the same name differently than other users. More than one name representations may be considered correct, especially in the computer world. One user may use a particular upper case character, but another user may not. A user may use a white space between two words, but another user may use a point or dash, etc. When input to a cryptographic hash function (as described in Section 3.2), these nuances will yield different outputs and foil the interoperability of human-regenerable identifiers addresses. This document therefore recommends the following techniques: Non-ASCII characters SHOULD be removed. Special characters that lead to doubtful concatenation (white space, dash, point, etc.) SHOULD be removed. A character SHOULD be removed by being replaced by the character on the right (if any). All upper case letters SHOULD be converted to their lower case counterpart. When these rules are applied to the above given examples, they all become (respectively): a/ sanghunhan b/ ahmedelsayed c/ johnsmith d/ jeanfrancoisleroux regardless of how they are entered by the user. This facilitates the successful matching of a HUMID generated by different users. String ending characters (such as '\0' in C language) may also lead to doubt. They SHOULD NOT be input to the hash function. 3.2 HUMID construction and collision handling In this document, a user input character string (possibly pre-formatted as above) is referred to as a NAME. A NAME can be a human name, pseudonym, keyword, or a short phrase. The following steps are required for HUMID construction: - A collision count MUST be concatenated at the end of a NAME. The collision count MUST be an 8-bit unsigned integer and MUST be initially set to 0. - NAME concatenated with the collision count MUST be input to the SHA-1 [SHA] hash function. The HUMID interface identifier is obtained by taking the leftmost 64 bits of the 160-bit SHA-1 hash value, and setting bit 6 (the left-most bit is numbered 0) to zero. This creates a HUMID with the universal/local bit indicating local significance only. Mutaf Expires March 8, 2007 [Page 4] Internet-Draft Human-regenerable IPv6 interface identifiers June 2006 - The 64-bit subnet prefix and the 64-bit HUMID are concatenated to form a 128-bit IPv6 address with the subnet prefix on the left and interface identifier on the right, as specified in [IP6ARCH]. The resultant IPv6 address MUST be tested for local uniqueness using the Duplicate Address Detection (DAD) mechanism specified in [SAA]. Each time an address collision is detected the collision count MUST incremented by 1, before retrying. Similarly, when attempting to contact a host at its human-regenerated address, the initiator SHOULD first try a target address with a collision count set to 0. Upon each failure, the collision count SHOULD be incremented by 1, before retrying. 4. Security considerations The use of a HUMID contradicts user privacy [PRIV]. Users who configure a HUMID should be beware that a HUMID may reveal the presence and/or location of a user to unwanted parties. The use of the cryptographic hash function, prevents a simple eavesdropper from capturing sensitive information. However, the threat is not completely defeated. An adversary may check the presence of a victim (known by his/her name) by sending a packet to his/her human-regenerable address. Sending a reply from the human-regenerable address will reveal the victim's presence and/or location. HUMIDs SHOULD be used in cases where augmented reachability outweighs the above threat. HUMIDs are by no means a proof of address ownership. For proof of address ownership a CGA [CGA] should be used. Human-regenerable addresses are not different from a regular IPv6 address. They can be impersonated. For example, sending a short message to a destination user's human-regenerated address is not secure. There is no guarantee that the message will be received by the intended destination. Human-regenerable address ownership of a responder can be verified during a voice session, since the initiator will recognize the responder's voice. The secure use of human-regenerable addresses is therefore better ensured with interactive voice communication. Other mechanisms may also be applicable for identity proof/check (for example, using certificates). However, this document does not specify them. 5. Conclusion Human-regenerable addresses can be used for augmented reachability in some ad-hoc scenarios, in case of infrastucture failure (preventing address recovery) or when there is no Internet infrastructure in range. This document recommended some human name disambiguation techniques, specified the hash function to use, and the handling of address duplications, in order to ensure successful matching of human-generated IPv6 addresses. Mutaf Expires March 8, 2007 [Page 5] Internet-Draft Human-regenerable IPv6 interface identifiers June 2006 References [IP6ARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [SAA] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", draft-ietf-ipv6-rfc2462bis-08 (work in progress), May 2005. [PRIV] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [SHA] National Institute of Standards and Technology, "Secure Hash Standard", Federal Information Processing Standards Publication FIPS PUB 180-1, April 1995, . [MIP6] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", RFC 3775, June 2004. [DNS] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1035, November 1987. Author's Address Pars Mutaf Institut National des Telecommunications Email: pars.mutaf@int-evry.fr This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Mutaf Expires March 8, 2007 [Page 6]