GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7343

Internet Engineering Task Force (IETF) J. Laganier Request for Comments: 7343 Luminate Wireless, Inc. Obsoletes: 4843 F. Dupont Category: Standards Track Internet Systems Consortium ISSN: 2070-1721 September 2014

                         An IPv6 Prefix for
Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)

Abstract

 This document specifies an updated Overlay Routable Cryptographic
 Hash Identifiers (ORCHID) format that obsoletes that in RFC 4843.
 These identifiers are intended to be used as endpoint identifiers at
 applications and Application Programming Interfaces (APIs) and not as
 identifiers for network location at the IP layer, i.e., locators.
 They are designed to appear as application-layer entities and at the
 existing IPv6 APIs, but they should not appear in actual IPv6
 headers.  To make them more like regular IPv6 addresses, they are
 expected to be routable at an overlay level.  Consequently, while
 they are considered non-routable addresses from the IPv6-layer
 perspective, all existing IPv6 applications are expected to be able
 to use them in a manner compatible with current IPv6 addresses.
 The Overlay Routable Cryptographic Hash Identifiers originally
 defined in RFC 4843 lacked a mechanism for cryptographic algorithm
 agility.  The updated ORCHID format specified in this document
 removes this limitation by encoding, in the identifier itself, an
 index to the suite of cryptographic algorithms in use.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7343.

Laganier & Dupont Standards Track [Page 1] RFC 7343 ORCHIDv2 September 2014

Copyright Notice

 Copyright (c) 2014 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.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   1.1.  Rationale and Intent  . . . . . . . . . . . . . . . . . .   3
   1.2.  ORCHID Properties . . . . . . . . . . . . . . . . . . . .   4
   1.3.  Expected Use of ORCHIDs . . . . . . . . . . . . . . . . .   5
   1.4.  Action Plan . . . . . . . . . . . . . . . . . . . . . . .   5
   1.5.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
 2.  Cryptographic Hash Identifier Construction  . . . . . . . . .   5
 3.  Routing and Forwarding Considerations . . . . . . . . . . . .   7
 4.  Design Choices  . . . . . . . . . . . . . . . . . . . . . . .   8
 5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
 6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
 7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  11
 8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
 9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
   9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
   9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
 Appendix A.  Collision Considerations . . . . . . . . . . . . . .  13
 Appendix B.  Changes from RFC 4843  . . . . . . . . . . . . . . .  13

1. Introduction

 This document introduces Overlay Routable Cryptographic Hash
 Identifiers (ORCHID), a new class of identifiers that are like IP
 addresses.  These identifiers are intended to be globally unique in a
 statistical sense (see Appendix A), non-routable at the IP layer, and
 routable at some overlay layer.  The identifiers are securely bound,
 via a secure hash function, to the concatenation of an input
 bitstring and a context tag.  Typically, but not necessarily, the
 input bitstring will include a suitably encoded public cryptographic
 key.

Laganier & Dupont Standards Track [Page 2] RFC 7343 ORCHIDv2 September 2014

1.1. Rationale and Intent

 These identifiers are expected to be used at the existing IPv6
 Application Programming Interfaces (APIs) and application protocols
 between consenting hosts.  They may be defined and used in different
 contexts, suitable for different overlay protocols.  Examples of
 these include Host Identity Tags (HITs) in the Host Identity Protocol
 (HIP) [HIPv2] and Temporary Mobile Identifiers (TMIs) for Mobile IPv6
 Privacy Extension [PRIVACYTEXT].
 As these identifiers are expected to be used along with IPv6
 addresses at both applications and APIs, coordination is desired to
 make sure that an ORCHID is not inappropriately taken for a regular
 IPv6 address and vice versa.  In practice, allocation of a separate
 prefix for ORCHIDs seems to suffice, making them compatible with IPv6
 addresses at the upper layers while simultaneously making it trivial
 to prevent their use at the IP layer.
 While being technically possible to use ORCHIDs between consenting
 hosts without any coordination with the IETF and the IANA, the IETF
 would consider such practice potentially dangerous.  A specific
 danger would be realized if the IETF community later decided to use
 the ORCHID prefix for some different purpose.  In that case, hosts
 using the ORCHID prefix would be, for practical purposes, unable to
 use the prefix for the other new purpose.  That would lead to partial
 balkanization of the Internet, similar to what has happened as a
 result of historical hijackings of IPv4 addresses that are not RFC
 1918 [RFC1918] for private use.
 The whole need for the proposed allocation grows from the desire to
 be able to use ORCHIDs with existing applications and APIs.  This
 desire leads to the potential conflict, mentioned above.  Resolving
 the conflict requires the proposed allocation.
 One can argue that the desire to use these kinds of identifiers via
 existing APIs is architecturally wrong, and there is some truth in
 that argument.  Indeed, it would be more desirable to introduce a new
 API and update all applications to use identifiers, rather than
 locators, via that new API.  That is exactly what we expect to happen
 in the long run.
 However, given the current state of the Internet, we do not consider
 it viable to introduce any changes that, at once, require
 applications to be rewritten and host stacks to be updated.  Rather
 than that, we believe in piece-wise architectural changes that
 require only one of the existing assets to be touched.  ORCHIDs are
 designed to address this situation: to allow people to implement with
 protocol stack extensions, such as secure overlay routing, HIP, or

Laganier & Dupont Standards Track [Page 3] RFC 7343 ORCHIDv2 September 2014

 Mobile IP privacy extensions, without requiring them to update their
 applications.  The goal is to facilitate large-scale deployments with
 minimum user effort.
 For example, at the time of this writing, there already exist HIP
 implementations that run fully in user space, using the operating
 system to divert a certain part of the IPv6 address space to a user-
 level daemon for HIP processing.  In practical terms, these
 implementations are already using a certain IPv6 prefix for
 differentiating HIP identifiers from IPv6 addresses, allowing them
 both to be used by the existing applications via the existing APIs.
 The Overlay Routable Cryptographic Hash Identifiers originally
 defined in [RFC4843] lacked a mechanism for cryptographic algorithm
 agility.  The updated ORCHID format specified in this document
 removes this limitation by encoding, in the identifier itself, an
 index to the suite of cryptographic algorithms in use.
 Because the updated ORCHIDv2 format is not backward compatible, IANA
 has allocated a new 28-bit prefix out of the IANA IPv6 Special
 Purpose Address Block, namely 2001:0000::/23, as per [RFC6890].  The
 prefix that was temporarily allocated for the experimental ORCHID was
 returned to IANA in March 2014 [RFC4843].

1.2. ORCHID Properties

 ORCHIDs are designed to have the following properties:
 o  Statistical uniqueness (see also Appendix A).
 o  Secure binding to the input parameters used in their generation
    (i.e., the Context Identifier and a bitstring).
 o  Aggregation under a single IPv6 prefix.  Note that this is only
    needed due to the coordination need as indicated above.  Without
    such coordination need, the ORCHID namespace could potentially be
    completely flat.
 o  Non-routability at the IP layer, by design.
 o  Routability at some overlay layer, making them, from an
    application point of view, semantically similar to IPv6 addresses.
 As mentioned above, ORCHIDs are intended to be generated and used in
 different contexts, as suitable for different mechanisms and
 protocols.  The Context Identifier is meant to be used to
 differentiate between the different contexts; see Appendix A for a

Laganier & Dupont Standards Track [Page 4] RFC 7343 ORCHIDv2 September 2014

 discussion of the related API issues implementation issues and
 Section 4 for the design choices explaining why the Context
 Identifiers are used.

1.3. Expected Use of ORCHIDs

 Examples of identifiers and protocols that are expected to adopt the
 ORCHID format include Host Identity Tags (HITs) in the Host Identity
 Protocol [HIPv2] and the Temporary Mobile Identifiers (TMIs) in the
 Simple Privacy Extension for Mobile IPv6 [PRIVACYTEXT].  The format
 is designed to be extensible to allow other experimental proposals to
 share the same namespace.

1.4. Action Plan

 This document requests IANA to allocate a prefix out of the IPv6
 addressing space for Overlay Routable Cryptographic Hash Identifiers.

1.5. Terminology

 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. Cryptographic Hash Identifier Construction

 An ORCHID is generated using the ORCHID Generation Algorithm (OGA).
 The algorithm takes a bitstring and a Context Identifier as input and
 produces an ORCHID as output.  The hash function used in the ORCHID
 Generation Algorithm is defined for each OGA identifier by the
 specification for the respective usage context (e.g., HIPv2).

Laganier & Dupont Standards Track [Page 5] RFC 7343 ORCHIDv2 September 2014

Input := any bitstring OGA ID := 4-bit Orchid Generation Algorithm identifier Hash Input := Context ID | Input Hash := Hash_function( Hash Input ) ORCHID := Prefix | OGA ID | Encode_96( Hash )

where:

| : Denotes concatenation of bitstrings

Input : A bitstring that is unique or statistically unique

                 within a given context.  The bitstring is intended
                 to be associated with the to-be-created ORCHID in
                 the given context.

Context ID : A randomly generated value defining the expected

                 usage context for the particular ORCHID and the
                 hash function to be used for generation of ORCHIDs
                 in this context.  These values are allocated out of
                 the namespace introduced for Cryptographically
                 Generated Addresses (CGA) Type Tags (see RFC 3972 and
                 http://www.iana.org/assignments/cga-message-types).

OGA ID : A 4-bit-long identifier for the Hash_function

                 in use within the specific usage context.

Hash_function : The one-way hash function (i.e., hash function

                 with preimage resistance and second-preimage
                 resistance) to be used as identified by the
                 value for the OGA ID according document
                 defining the context usage identified by the
                 Context ID.  For example, version 2 of the
                 HIP specification defines truncated SHA1 [RFC3174] as
                 the hash function to be used to generate
                 ORCHIDv2 in the HIPv2 protocol when the
                 OGA ID is 3 [HIPv2].

Encode_96( ) : An extraction function in which output is obtained

                 by extracting the middle 96-bit-long bitstring
                 from the argument bitstring.

Prefix : A constant 28-bit-long bitstring value

                 (2001:20::/28).
 To form an ORCHID, two pieces of input data are needed.  The first
 piece can be any bitstring, but it is typically expected to contain a
 public cryptographic key and some other data.  The second piece is a

Laganier & Dupont Standards Track [Page 6] RFC 7343 ORCHIDv2 September 2014

 Context Identifier, which is a 128-bit-long datum, allocated as
 specified in Section 6.  Each specific ORCHIDv2 application (such as
 HIP HITs or MIP6 TMIs) is expected to allocate their own, specific
 Context Identifier.
 The input bitstring and Context Identifier are concatenated to form
 an input datum, which is then fed to the cryptographic hash function
 to be used for the value of the OGA identifier according to the
 document defining the context usage identified by the Context ID.
 The result of the hash function is processed by an encoding function,
 resulting in a 96-bit-long value.  This value is prepended with the
 concatenation of the 28-bit ORCHID prefix and the 4-bit OGA ID.  The
 result is the ORCHID, a 128-bit-long bitstring that can be used at
 the IPv6 APIs in hosts participating to the particular experiment.
 The ORCHID prefix is allocated under the IPv6 global unicast address
 block.  Hence, ORCHIDs are indistinguishable from IPv6 global unicast
 addresses.  However, it should be noted that ORCHIDs do not conform
 with the IPv6 global unicast address format defined in Section 2.5.4
 of [RFC4291] since they do not have a 64-bit Interface ID formatted
 as described in Section 2.5.1. of [RFC4291].

3. Routing and Forwarding Considerations

 ORCHIDs are designed to serve as location-independent endpoint
 identifiers rather than IP-layer locators.  Therefore, routers MAY be
 configured not to forward any packets containing an ORCHID as a
 source or a destination address.  If the destination address is an
 ORCHID but the source address is a valid unicast source address,
 routers MAY be configured to generate an ICMP Destination
 Unreachable, Administratively Prohibited message.
 ORCHIDs are not designed for use in IPv6 routing protocols, since
 such routing protocols are based on the architectural definition of
 IPv6 addresses.  Future non-IPv6 routing systems, such as overlay
 routing systems, may be designed based on ORCHIDs.  Any such ORCHID-
 based routing system is out of scope of this document.
 Router software MUST NOT include any special handling code for
 ORCHIDs.  In other words, the non-routability property of ORCHIDs, if
 implemented, is to be implemented via configuration rather than by
 hardwired software code, e.g., the ORCHID prefix can be blocked by a
 simple configuration rule such as an Access Control List entry.

Laganier & Dupont Standards Track [Page 7] RFC 7343 ORCHIDv2 September 2014

4. Design Choices

 The design of this namespace faces two competing forces:
 o  As many bits as possible should be preserved for the hash result.
 o  It should be possible to share the namespace between multiple
    mechanisms.
 The desire to have a long hash result requires that the prefix be as
 short as possible and use few (if any) bits for additional encoding.
 The present design takes this desire to the maximum: all the bits
 beyond the prefix and the ORCHID Generation Algorithm Identifier are
 used as hash output.  This leaves no bits in the ORCHID itself
 available for identifying the context; however, the 4 bits used to
 encode the ORCHID Generation Algorithm Identifier provides
 cryptographic agility with respect to the hash function in use for a
 given context (see Section 5).
 The desire to allow multiple mechanisms to share the namespace has
 been resolved by including the Context Identifier in the hash
 function input.  While this does not allow the mechanism to be
 directly inferred from an ORCHID, it allows one to verify that a
 given input bitstring and ORCHID belong to a given context, with high
 probability (but also see Section 5).

5. Security Considerations

 ORCHIDs are designed to be securely bound to the Context ID and the
 bitstring used as the input parameters during their generation.  To
 provide this property, the ORCHID Generation Algorithm relies on the
 second-preimage resistance (a.k.a. one-way) property of the hash
 function used in the generation [RFC4270].  To have this property and
 to avoid collisions, it is important that the allocated prefix is as
 short as possible, leaving as many bits as possible for the hash
 output.
 For a given Context ID, all mechanisms using ORCHIDs MUST use exactly
 the same mechanism for generating an ORCHID from the input bitstring.
 Allowing different mechanisms, without explicitly encoding the
 mechanism in the Context ID or the ORCHID itself, would allow
 so-called bidding-down attacks.  That is, if multiple different hash
 functions were allowed to construct ORCHIDs valid for the same
 Context ID, and if one of the hash functions became insecure, that
 would allow attacks against even those ORCHIDs valid for the same
 Context ID that had been constructed using the other, still secure
 hash functions.

Laganier & Dupont Standards Track [Page 8] RFC 7343 ORCHIDv2 September 2014

 An identifier for the hash function to be used for the ORCHID
 generation is encoded in the ORCHID itself, while the semantic for
 the values taken by this identifier are defined separately for each
 Context ID.  Therefore, the present design allows the use of
 different hash functions per given Context ID for constructing
 ORCHIDs from input bitstrings.  The intent is that the protocol or
 application using an ORCHIDv2 allocates a Context ID for that use and
 defines, within the scope of that Context ID, the registry for the
 ORCHID Generation Algorithm (OGA) ID.  The rationale for this is to
 allow different applications to use different hash functions that
 best satisfy their specific requirements, such that the relatively
 small OGA ID namespace (4 bits wide, i.e., 16 different values) does
 not get exhausted too quickly.  If more secure hash functions are
 later needed, newer values for the ORCHID Generation Algorithm can be
 defined for the given Context ID.
 In order to preserve a low enough probability of collisions (see
 Appendix A), each method MUST utilize a mechanism that makes sure
 that the distinct input bitstrings are either unique or statistically
 unique within that context.  There are several possible methods to
 ensure this; for example, one can include into the input bitstring a
 globally maintained counter value, a pseudorandom number of
 sufficient entropy (minimum 96 bits), or a randomly generated public
 cryptographic key.  The Context ID makes sure that input bitstrings
 from different contexts never overlap.  These together make sure that
 the probability of collisions is determined only by the probability
 of natural collisions in the hash space and is not increased by a
 possibility of colliding input bitstrings.
 The generation of an ORCHIDv2 identifier from an input bitstring
 involves truncation of a hash output to construct a fixed-size
 identifier in a fashion similar to the scheme specified in "Naming
 Things with Hashes" [RFC6920].  Accordingly, the Security
 Considerations of [RFC6920] pertaining to truncation of the hash
 output during identifier generation are also applicable to ORCHIDv2
 generation.

Laganier & Dupont Standards Track [Page 9] RFC 7343 ORCHIDv2 September 2014

6. IANA Considerations

 Because the updated ORCHIDv2 format is not backward compatible with
 the earlier one, IANA has allocated a new 28-bit prefix out of the
 IANA IPv6 Special Purpose Address Block, namely 2001:0000::/23, as
 per [RFC6890].  The prefix that was temporarily allocated for the
 experimental ORCHID was returned to IANA in March 2014 [RFC4843].
 The registry information for the allocation is as follows:
 o  Address Block: 2001:20::/28
 o  Name: ORCHIDv2
 o  RFC: RFC 7343
 o  Allocation Date: 2014-07
 o  Termination Date: N/A
 o  Source: True
 o  Destination: True
 o  Forwardable: True
 o  Global: True
 o  Reserved-by-Protocol: False
 The Context Identifier (or Context ID) is a randomly generated value
 defining the usage context of an ORCHID and the hash function to be
 used for generation of ORCHIDs in this context.  This document
 defines no specific value.  The Context ID shares the namespace
 introduced for CGA Type Tags.  Hence, defining new values follows the
 rules of Section 8 of [RFC3972], i.e., First Come, First Served.
 However, no IANA actions are required.

Laganier & Dupont Standards Track [Page 10] RFC 7343 ORCHIDv2 September 2014

7. Contributors

 Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an
 earlier, experimental version of this specification [RFC4843].

8. Acknowledgments

 Special thanks to Geoff Huston for his sharp but constructive
 critique during the development of this memo.  Tom Henderson helped
 to clarify a number of issues.  This document has also been improved
 by reviews, comments, and discussions originating from the IPv6,
 Internet Area, and IETF communities.

9. References

9.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
            RFC 3972, March 2005.

9.2. Informative References

 [HIPv2]    Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
            "Host Identity Protocol Version 2 (HIPv2)", Work in
            Progress, July 2014.
 [PRIVACYTEXT]
            Dupont, F., "A Simple Privacy Extension for Mobile IPv6",
            Work in Progress, July 2006.
 [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
            E. Lear, "Address Allocation for Private Internets", BCP
            5, RFC 1918, February 1996.
 [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
            (SHA1)", RFC 3174, September 2001.
 [RFC4270]  Hoffman, P. and B. Schneier, "Attacks on Cryptographic
            Hashes in Internet Protocols", RFC 4270, November 2005.
 [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
            Architecture", RFC 4291, February 2006.

Laganier & Dupont Standards Track [Page 11] RFC 7343 ORCHIDv2 September 2014

 [RFC4843]  Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix
            for Overlay Routable Cryptographic Hash Identifiers
            (ORCHID)", RFC 4843, April 2007.
 [RFC6890]  Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,
            "Special-Purpose IP Address Registries", BCP 153, RFC
            6890, April 2013.
 [RFC6920]  Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
            Keranen, A., and P. Hallam-Baker, "Naming Things with
            Hashes", RFC 6920, April 2013.

Laganier & Dupont Standards Track [Page 12] RFC 7343 ORCHIDv2 September 2014

Appendix A. Collision Considerations

 As noted earlier, the aim is that so long as keys are not reused,
 ORCHIDs be globally unique in a statistical sense.  That is, given
 the ORCHID referring to a given entity, the probability of the same
 ORCHID being used to refer to another entity elsewhere in the
 Internet must be sufficiently low so that it can be ignored for most
 practical purposes.  We believe that the presented design meets this
 goal (see Section 4).
 As mentioned above, ORCHIDs are expected to be used at the legacy
 IPv6 APIs between consenting hosts.  The Context ID is intended to
 differentiate between the various experiments, or contexts, sharing
 the ORCHID namespace.  However, the Context ID is not present in the
 ORCHID itself but is only in front of the input bitstring as an input
 to the hash function.  While this may lead to certain implementation-
 related complications, we believe that the trade-off of allowing the
 hash result part of an ORCHID being longer more than pays off the
 cost.
 Because ORCHIDs are not routable at the IP layer, in order to send
 packets using ORCHIDs at the API level, the sending host must have
 additional overlay state within the stack to determine which
 parameters (e.g., what locators) to use in the outgoing packet.  An
 underlying assumption here, and a matter of fact in the proposals
 that the authors are aware of, is that there is an overlay protocol
 for setting up and maintaining this additional state.  It is assumed
 that the state-setup protocol carries the input bitstring and that
 the resulting ORCHID-related state in the stack can be associated
 back with the appropriate context and state-setup protocol.

Appendix B. Changes from RFC 4843

 o  Updated HIP references to revised HIP specifications.
 o  The Overlay Routable Cryptographic Hash Identifiers originally
    defined in [RFC4843] lacked a mechanism for cryptographic
    algorithm agility.  The updated ORCHID format specified in this
    document removes this limitation by encoding, in the identifier
    itself, an index to the suite of cryptographic algorithms in use.
 o  Moved the "Collision Considerations" section into an appendix and
    removed unnecessary discussions.
 o  Removed the discussion on overlay routing.

Laganier & Dupont Standards Track [Page 13] RFC 7343 ORCHIDv2 September 2014

Authors' Addresses

 Julien Laganier
 Luminate Wireless, Inc.
 Cupertino, CA
 USA
 EMail: julien.ietf@gmail.com
 Francis Dupont
 Internet Systems Consortium
 EMail: fdupont@isc.org

Laganier & Dupont Standards Track [Page 14]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7343.txt · Last modified: 2014/09/19 19:05 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki