doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc7859.txt b/doc/rfc/rfc7859.txt
new file mode 100644
index 0000000..59f014e
--- /dev/null
+++ b/doc/rfc/rfc7859.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       C. Dearlove
+Request for Comments: 7859                                   BAE Systems
+Category: Experimental                                          May 2016
+ISSN: 2070-1721
+
+
+                     Identity-Based Signatures for
+            Mobile Ad Hoc Network (MANET) Routing Protocols
+
+Abstract
+
+   This document extends RFC 7182, which specifies a framework for (and
+   specific examples of) Integrity Check Values (ICVs) for packets and
+   messages using the generalized packet/message format specified in RFC
+   5444.  It does so by defining an additional cryptographic function
+   that allows the creation of an ICV that is an Identity-Based
+   Signature (IBS), defined according to the Elliptic Curve-Based
+   Certificateless Signatures for Identity-Based Encryption (ECCSI)
+   algorithm specified in RFC 6507.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  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).  Not
+   all documents approved by the IESG are a candidate for any level of
+   Internet Standard; see 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/rfc7859.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove                      Experimental                      [Page 1]
+
+RFC 7859                Identity-Based Signatures               May 2016
+
+
+Copyright Notice
+
+   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.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
+   3.  Applicability Statement . . . . . . . . . . . . . . . . . . .   5
+   4.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   5
+     4.1.  Cryptographic Function  . . . . . . . . . . . . . . . . .   5
+     4.2.  ECCSI Parameters  . . . . . . . . . . . . . . . . . . . .   6
+     4.3.  Identity  . . . . . . . . . . . . . . . . . . . . . . . .   7
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
+     6.1.  Experimental Status . . . . . . . . . . . . . . . . . . .   9
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
+     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
+   Appendix A.  Example  . . . . . . . . . . . . . . . . . . . . . .  12
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove                      Experimental                      [Page 2]
+
+RFC 7859                Identity-Based Signatures               May 2016
+
+
+1.  Introduction
+
+   [RFC7182] defines Integrity Check Value (ICV) TLVs for use in packets
+   and messages that use the generalized MANET packet/message format
+   defined in [RFC5444].  This specification extends the TLV definitions
+   therein by defining two new cryptographic function code points from
+   within the registries set up by [RFC7182].  This allows the use of an
+   Identity-Based Signature (IBS) as an ICV.  An IBS has an additional
+   property that is not shared by all of the previously specified ICVs;
+   it not only indicates that the protected packet or message is valid,
+   but also verifies the originator of the packet/message.
+
+   This specification assumes that each router (i.e., each originator of
+   [RFC5444] format packets/messages) has an identity that may be tied
+   to the packet or message.  The router may have more than one identity
+   but will only use one for each ICV TLV.  The cryptographic strength
+   of the IBS is not dependent on the choice of identity.
+
+   Two options for the choice of identity are supported (as reflected by
+   the two code points allocated).  In the first option, the identity
+   can be any octet sequence (up to 255 octets) included in the ICV TLV.
+   In the second option, the octet sequence is preceded by an address,
+   either the IP source address for a Packet TLV or the message
+   originator address for a Message TLV or an Address Block TLV.  In
+   particular, the second option allows just the address to be used as
+   an identity.
+
+   Identity-based signatures allow identification of the originator of
+   information in a packet or message.  They thus allow additional
+   security functions, such as revocation of an identity.  (A router
+   could also then remove all information recorded as from that revoked
+   originator; the Optimized Link State Routing Protocol Version 2
+   (OLSRv2) [RFC7181], an expected user of this specification, can do
+   this.)  When applied to messages (rather than packets), this can
+   significantly reduce the damage that a compromised router can inflict
+   on the network.
+
+   Identity-based signatures are based on forms of asymmetric (public
+   key) cryptography - Identity-Based Encryption (IBE).  Compared to
+   symmetric cryptographic methods (such as HMAC and AES), IBE and IBS
+   methods avoid requiring a shared secret key that results in a single
+   point of failure vulnerability.  Compared to more widely used
+   asymmetric (public key) cryptographic methods (such as RSA and
+   ECDSA), IBE and IBS methods have a major advantage and a major
+   disadvantage.
+
+   The advantage referred to is that each router can be configured once
+   (for its key lifetime) by a trusted authority, independently of all
+
+
+
+Dearlove                      Experimental                      [Page 3]
+
+RFC 7859                Identity-Based Signatures               May 2016
+
+
+   other routers.  Thus, a router can connect to the authority
+   (typically in a secure environment) to receive a private key or can
+   have a private key delivered securely (out of band) from the
+   authority.  During normal operation of the MANET, there is no need
+   for the trusted authority to be connected to the MANET or even to
+   still exist.  Additional routers can be authorized with no reference
+   to previously authorized routers (the trusted authority must still
+   exist in this case).  A router's public key is its identity, which
+   when tied to a packet or message (as is the case when using an
+   address as, or as part of, the identity) means that there is no need
+   for public key certificates or a certificate authority, and a router
+   need not retain key material for any other routers.
+
+   The disadvantage referred to is that the trusted authority has
+   complete authority, even more so than a conventional certificate
+   authority.  Routers cannot generate their own private keys, only the
+   trusted authority can do that.  Through the master secret held by the
+   trusted authority, it could impersonate any router (existing or not).
+   When used for IBE (not part of this specification), the trusted
+   authority can decrypt anything.  However, note that the shared secret
+   key options described in [RFC7182] also have this limitation.
+
+   There are alternative mathematical realizations of identity-based
+   signatures.  This specification uses one that has been previously
+   published as [RFC6507], known as Elliptic Curve-Based Certificateless
+   Signatures for Identity-Based Encryption (ECCSI).  Similar to other
+   IBE/IBS approaches, it is based on the use of elliptic curves.
+   Unlike some, it does not use "pairings" (bilinear maps from a product
+   of two elliptic curve groups to another group).  It thus may be
+   easier to implement and more efficient than some alternatives,
+   although with a greater signature size than some.  This specification
+   allows the use of any elliptic curve that may be used by [RFC6507].
+
+   The computational load imposed by ECCSI (and, perhaps more so by
+   other IBS methods) is not trivial, though it depends significantly on
+   the quality of implementation of the required elliptic curve and
+   other mathematical functions.  For a security level of 128 bits, the
+   ICV data length is 129 octets, which is longer than for alternative
+   ICVs specified in [RFC7182] (e.g., 32 octets for the similar strength
+   HMAC-SHA-256).  The signature format used could have been slightly
+   shortened (to 97 octets) by using a compressed representation of an
+   elliptic curve point, however, at the expense of some additional work
+   when verifying a signature and loss of direct compatibility with
+   [RFC6507], and implementations thereof.
+
+   The trusted authority is referred to in [RFC6507] as the Key
+   Management Service (KMS).  That term will be used in the rest of this
+   specification.
+
+
+
+Dearlove                      Experimental                      [Page 4]
+
+RFC 7859                Identity-Based Signatures               May 2016
+
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+   Additionally, this document uses the terminology of [RFC5444],
+   [RFC6507], and [RFC7182].
+
+3.  Applicability Statement
+
+   This specification adds an additional option to the framework
+   specified in [RFC7182] for use by packets and messages formatted as
+   described in [RFC5444].  It is applicable as described in [RFC7182]
+   and is subject to the additional comments in Section 6, particularly
+   regarding the role of the trusted authority (KMS).
+
+   Specific examples of protocols for which this specification is
+   suitable are Neighborhood Discovery Protocol (NHDP) [RFC6130] and
+   OLSRv2 [RFC7181].
+
+4.  Specification
+
+4.1.  Cryptographic Function
+
+   This specification defines a cryptographic function named ECCSI that
+   is implemented as specified as the "sign" function in Section 5.2.1
+   of [RFC6507].  To use that specification:
+
+   o  The ICV is not calculated as cryptographic-function(hash-
+      function(content)) as defined in [RFC7182] but (like the HMAC ICVs
+      defined in [RFC7182]) uses the hash function within the
+      cryptographic function.  The option "none" is not permitted for
+      hash-function, and the hash function must have a known fixed
+      length of N octets (as specified in Section 4.2).
+
+   o  M, used in [RFC6507], is "content" as specified in [RFC7182].
+
+   o  ID, used in [RFC6507], is as specified in Section 4.3.
+
+   o  Key Management Service Public Authentication Key (KPAK), Secret
+      Signing Key (SSK), and Public Validation Token (PVT), which are
+      provided by the KMS, are as specified in Sections 4.2 and 5.1.1 of
+      [RFC6507].
+
+
+
+
+
+
+Dearlove                      Experimental                      [Page 5]
+
+RFC 7859                Identity-Based Signatures               May 2016
+
+
+   The length of the signature is 4N+1 octets (as specified in
+   [RFC6507]) whose affine coordinate format (including an octet valued
+   0x04 to identify this) is used unchanged.
+
+   Verification of the ICV is not implemented by the receiver
+   recalculating the ICV and comparing with the received ICV, as it is
+   necessarily incapable of doing so.  Instead, the receiver evaluates
+   the "verify" function described in Section 5.2.2 of [RFC6507], which
+   may pass or fail.
+
+   To use that function M, KPAK, SSK, and PVT are as specified above,
+   while the Identifier (ID) is deduced from the received packet or
+   message (as specified in Section 4.3) using the <key-id> element in
+   the <ICV-value>.  This element need not match that used by the
+   receiver, and thus when using this cryptographic function, multiple
+   ICV TLVs differing only in their <key-id> or in the choice of
+   cryptographic function from the two defined in this specification
+   SHOULD NOT be used unless routers are administratively configured to
+   recognize which to verify.
+
+   Routers MAY be administratively configured to reject an ICV TLV using
+   ECCSI based on part or all of <key-id>: for example, if this encodes
+   a time after which this identity is no longer valid (as described in
+   Section 4.3).
+
+4.2.  ECCSI Parameters
+
+   Section 4.1 of [RFC6507] specifies parameters n, N, p, E, B, G, and
+   q.  The first of these, n, is specified as "A security parameter; the
+   size in bits of the prime p over which elliptic curve cryptography is
+   to be performed."  For typical security levels (e.g., 128, 192, and
+   256 bits), n must be at least twice the required bits of security;
+   see Section 5.6.1 of [NIST-SP-800-57].
+
+   Selection of an elliptic curve, and all related parameters, MUST be
+   made by administrative means, and known to all routers.  Following
+   [RFC6507], it is RECOMMENDED that the curves and base points defined
+   in Appendix D.1.2 of [NIST-FIPS-186-4] be used (note that n in that
+   document is q in [RFC6507]).  However, an alternative curve MAY be
+   used.
+
+   The parameter that is required by this specification is N, which is
+   defined as Ceiling(n/8).  The hash function used must create an
+   output of size N octets.  For example, for 128 bit security, with n =
+   256 and N = 32, the RECOMMENDED hash function is SHA-256.  The
+   signature (i.e., <ICV-data>) length is 4N+1 octets, i.e., 129 octets
+   for N = 32.
+
+
+
+
+Dearlove                      Experimental                      [Page 6]
+
+RFC 7859                Identity-Based Signatures               May 2016
+
+
+   Note that [RFC6507] actually refers to the predecessor to
+   [NIST-FIPS-186-4], but the latest version is specified here; there
+   are no significant differences in this regard.
+
+4.3.  Identity
+
+   There are two options for ID as used by [RFC6507], which are
+   indicated by there being two code points allocated for this
+   cryptographic function, see Section 5.
+
+   o  For the cryptographic function ECCSI, ID is the element <key-id>
+      defined in Section 12.1 of [RFC7182].  This MUST NOT be empty.
+
+   o  For the cryptographic function ECCSI-ADDR, ID is the concatenation
+      of an address (in network byte order) and the element <key-id>
+      defined in Section 12.1 of [RFC7182], where the latter MAY be
+      empty.
+
+      *  For a Packet TLV, this address is the IP source address of the
+         IP datagram in which this packet is included.
+
+      *  For a Message TLV or an Address Block TLV, this address is the
+         message originator address (the element <msg-orig-addr> defined
+         in [RFC5444]) if that address is present; if it is not present
+         and the message is known to have traveled only one hop, then
+         the IP source address of the IP datagram in which this message
+         is included is used.  Otherwise, no address is defined and the
+         message MUST be rejected.  (Note that HELLO messages specified
+         in NHDP [RFC6130] and used in OLSRv2 [RFC7181] always only
+         travel one hop; hence, their IP source address SHOULD be used
+         if no originator address is present.)
+
+   The element <key-id> MAY be (for the cryptographic function ECCSI-
+   ADDR) or include (for either cryptographic function) a representation
+   of the identity expiry time.  This MAY use one of the representations
+   of time defined for the TIMESTAMP TLV in [RFC7182].  A RECOMMENDED
+   approach is to use the cryptographic function ECCSI-ADDR with element
+   <key-id> containing the single octet representing the type of the
+   time, normally used as the TIMESTAMP TLV Type Extension (defined in
+   [RFC7182], Table 9), or any extension thereof, followed by the time
+   as so represented, normally used as the TIMESTAMP TLV Value.
+
+   Note that the identity is formatted as specified in [RFC6507] and
+   thus does not need a length field incorporated into it by this
+   specification.
+
+
+
+
+
+
+Dearlove                      Experimental                      [Page 7]
+
+RFC 7859                Identity-Based Signatures               May 2016
+
+
+5.  IANA Considerations
+
+   IANA has allocated the following two new values in the "Cryptographic
+   Functions" registry under "Mobile Ad Hoc NETwork Parameters" registry
+   and modified the unassigned range accordingly.
+
+   +-------+------------+----------------------------------+-----------+
+   | Value | Algorithm  |           Description            | Reference |
+   +-------+------------+----------------------------------+-----------+
+   |   7   |   ECCSI    |         ECCSI [RFC6507]          |  RFC 7859 |
+   |   8   | ECCSI-ADDR | ECCSI [RFC6507] with an address  |  RFC 7859 |
+   |       |            | (source or originator) joined to |           |
+   |       |            |             identity             |           |
+   | 9-251 |            |    Unassigned; Expert Review     |           |
+   +-------+------------+----------------------------------+-----------+
+
+                 Table 1: Cryptographic Function Registry
+
+6.  Security Considerations
+
+   This specification extends the security framework for MANET routing
+   protocols specified in [RFC7182] by adding cryptographic functions
+   (in two forms, according to how identity is specified).
+
+   This cryptographic function implements a form of IBS; a stronger form
+   of ICV that verifies not just that the received packet or message is
+   valid but that the packet or message originated at a router that was
+   assigned a private key for the specified identity.
+
+   It is recommended that the identity include an address unique to that
+   router: for a message, its originator address, and for a packet, the
+   corresponding IP packet source address.  If additional information is
+   included in the identity, this may be to indicate an expiry time for
+   signatures created using that identity.
+
+   In common with other forms of IBS, a feature of the form of IBS
+   (known as ECCSI) used in this specification is that it requires a
+   trusted KMS that issues all private keys and has complete
+   cryptographic information about all possible private keys.  However,
+   to set against that, the solution is scalable (as all routers can be
+   independently keyed) and does not need the KMS in the network.  If no
+   future keys will be required, then the KMS's master secret can be
+   destroyed.  As routers are individually keyed, key revocation (by
+   blacklist and/or time expiry of keys) is possible.
+
+   ECCSI is based on elliptic curve mathematics.  This specification
+   follows [RFC6507] in its recommendation of elliptic curves, but any
+   suitable (prime power) elliptic curve may be used; this must be
+
+
+
+Dearlove                      Experimental                      [Page 8]
+
+RFC 7859                Identity-Based Signatures               May 2016
+
+
+   administratively specified.  Implementation of this specification
+   will require an available implementation of suitable mathematical
+   functions.  Unlike some other forms of IBS, ECCSI requires only basic
+   elliptic curve operations; it does not require "pairings" (bilinear
+   functions of a product of two elliptic curve groups).  This increases
+   the available range of suitable mathematical libraries.
+
+6.1.  Experimental Status
+
+   The idea of using identity-based signatures for authentication of ad
+   hoc network signaling goes back at least as far as 2005 [Dearlove].
+   The specific implementation of an IBS used in this specification,
+   ECCSI, was published as an Internet Draft in 2010 before publication
+   as an Informational RFC [RFC6507].  ECCSI is now part of standards
+   such as [ETSI] for LTE Proximity-based Services.  An open-source
+   implementation of cryptographic software that includes ECCSI is
+   available, see [SecureChorus].
+
+   However, although this specification has been implemented for use in
+   an OLSRv2 [RFC7181] routed network, there are only limited reports of
+   such use.  There are also no reports of the use of ECCSI within the
+   IETF, other than in this specification.  There are no reports of
+   independent public scrutiny of the algorithm, although ECCSI is
+   reported [RFC6507] as being based on [ECDSA] with similar properties.
+
+   This specification is thus published as Experimental in order to
+   encourage its use and encourage reports on its use.  Once experiments
+   have been carried out and reported on (and when some public analysis
+   of the underlying cryptographic algorithms is available), it is
+   intended to advance this specification, with any changes identified
+   by such experimentation and analysis, to Standards Track.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
+              "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
+              Format", RFC 5444, DOI 10.17487/RFC5444, February 2009,
+              <http://www.rfc-editor.org/info/rfc5444>.
+
+
+
+
+
+
+Dearlove                      Experimental                      [Page 9]
+
+RFC 7859                Identity-Based Signatures               May 2016
+
+
+   [RFC6507]  Groves, M., "Elliptic Curve-Based Certificateless
+              Signatures for Identity-Based Encryption (ECCSI)",
+              RFC 6507, DOI 10.17487/RFC6507, February 2012,
+              <http://www.rfc-editor.org/info/rfc6507>.
+
+   [RFC7182]  Herberg, U., Clausen, T., and C. Dearlove, "Integrity
+              Check Value and Timestamp TLV Definitions for Mobile Ad
+              Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182,
+              April 2014, <http://www.rfc-editor.org/info/rfc7182>.
+
+7.2.  Informative References
+
+   [Dearlove] Dearlove, C., "OLSR Developments and Extensions",
+              Proceedings of the 2nd OLSR Interop and Workshop, July
+              2005, <http://interop.thomasclausen.org/Interop05/Papers/
+              Papers/paper-01.pdf>.
+
+   [ECDSA]    American National Standards Institute, "Public Key
+              Cryptography for the Financial Services Industry: The
+              Elliptic Curve Digital Signature Algorithm (ECDSA)",
+              ANSI X9.62-2005, November 2005.
+
+   [ETSI]     ETSI/3GPP, "Universal Mobile Telecommunications System
+              (UMTS); LTE; Proximity-based Services (ProSe); Security
+              aspects", ETSI TS 33.303, V13.2.0, Release 13, January
+              2016, <http://www.etsi.org/deliver/
+              etsi_ts/133300_133399/133303/13.02.00_60/
+              ts_133303v130200p.pdf>.
+
+   [NIST-FIPS-186-4]
+              National Institute of Standards and Technology, "Digital
+              Signature Standard (DSS)", FIPS 186-4,
+              DOI 10.6028/NIST.FIPS.186-4, July 2013.
+
+   [NIST-SP-800-57]
+              National Institute of Standards and Technology,
+              "Recommendation for Key Management - Part 1: General
+              (Revision 3)", NIST Special Publication 800-57, Part 1,
+              Revision 3, DOI 10.6028/NIST.SP.800-57pt1r4, July 2012.
+
+   [RFC5497]  Clausen, T. and C. Dearlove, "Representing Multi-Value
+              Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
+              DOI 10.17487/RFC5497, March 2009,
+              <http://www.rfc-editor.org/info/rfc5497>.
+
+
+
+
+
+
+
+Dearlove                      Experimental                     [Page 10]
+
+RFC 7859                Identity-Based Signatures               May 2016
+
+
+   [RFC6130]  Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
+              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
+              RFC 6130, DOI 10.17487/RFC6130, April 2011,
+              <http://www.rfc-editor.org/info/rfc6130>.
+
+   [RFC7181]  Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
+              "The Optimized Link State Routing Protocol Version 2",
+              RFC 7181, DOI 10.17487/RFC7181, April 2014,
+              <http://www.rfc-editor.org/info/rfc7181>.
+
+   [SecureChorus]
+              "Secure Chorus: Interoperable and secure enterprise
+              communications", <http://www.securechorus.com/>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove                      Experimental                     [Page 11]
+
+RFC 7859                Identity-Based Signatures               May 2016
+
+
+Appendix A.  Example
+
+   Appendix C of [RFC6130] contains this example of a HELLO message.
+   (Note that normally a TIMESTAMP ICV would also be added before the
+   ICV TLV, but for simplicity, that step has been omitted here.)
+
+      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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     HELLO     | MF=7  | MAL=3 |      Message Length = 45      |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Hop Limit = 1 | Hop Count = 0 |    Message Sequence Number    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Message TLV Block Length = 8  | VALIDITY_TIME |  MTLVF = 16   |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Value Len = 1 | Value (Time)  | INTERVAL_TIME |  MTLVF = 16   |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Value Len = 1 | Value (Time)  | Num Addrs = 5 |   ABF = 128   |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Head Len = 3  |                     Head                      |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Mid 0     |     Mid 1     |     Mid 2     |     Mid 3     |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Mid 4     | Address TLV Block Length = 14 |   LOCAL_IF    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  ATLVF = 80   |   Index = 0   | Value Len = 1 |    THIS_IF    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  LINK_STATUS  |   ATLV = 52   | Strt Indx = 1 | Stop Indx = 4 |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Value Len = 4 |     HEARD     |     HEARD     |   SYMMETRIC   |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     LOST      |
+     +-+-+-+-+-+-+-+-+
+
+   In order to provide an example of an ECCSI ICV Message TLV that may
+   be added to this message, the fields shown need to all have numerical
+   values, both by inserting defined numerical values (e.g., 0 for
+   HELLO) and by selecting example values where needed.  The latter
+   means that
+
+   o  The message sequence number will be zero.
+
+   o  The five addresses will be 192.0.2.1 to 192.0.2.5.
+
+   o  The message validity time will be six seconds and the message
+      interval time will be two seconds, each encoded with a constant
+      value C = 1/1024 seconds (as described in [RFC5497] and as
+      referenced from [RFC6130]).
+
+
+
+Dearlove                      Experimental                     [Page 12]
+
+RFC 7859                Identity-Based Signatures               May 2016
+
+
+   In addition, when calculating an ICV, the hop count and hop limit are
+   both set to zero.  This results in the message:
+
+      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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |0 0 0 0 0 0 0 0|0 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 0 1 1 0 1|
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 1|0 0 0 1 0 0 0 0|
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 0 0 0|0 0 0 1 0 0 0 0|
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |0 0 0 0 0 0 0 1|0 1 0 1 1 0 0 0|0 0 0 0 0 1 0 1|1 0 0 0 0 0 0 0|
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |0 0 0 0 0 0 1 1|1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 1|0 0 0 0 0 1 0 0|
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |0 0 0 0 0 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0|0 0 0 0 0 0 1 0|
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |0 1 0 1 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0|
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |0 0 0 0 0 0 1 1|0 0 1 1 0 1 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0|
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |0 0 0 0 0 1 0 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 1|
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |0 0 0 0 0 0 0 0|
+     +-+-+-+-+-+-+-+-+
+
+   Or, in hexadecimal form:
+
+      M         := 0x 0073002D  00000000  00080110  01640010
+                      01580580  03C00002  01020304  05000E02
+                      50000100  03340104  04020201  00
+
+   The ICV TLV that will be added will have cryptographic function
+   ECCSI-ADDR and hash function SHA-256.  This message has no originator
+   address, but it travels a single hop and its IP source address can be
+   used.  This will be assumed to be 192.0.2.0 with an empty <key-id>;
+   thus, the sender's identity will be (in hexadecimal form):
+
+      ID        := 0x  C0000200
+
+
+
+
+
+
+
+Dearlove                      Experimental                     [Page 13]
+
+RFC 7859                Identity-Based Signatures               May 2016
+
+
+   Parameters for [RFC6507] will thus be n = 256, N = 32.  The same
+   parameters and master key will be used as in Appendix A of [RFC6507],
+   i.e., the elliptic curve P-256, with parameters:
+
+      p         := 0x  FFFFFFFF 00000001 00000000 00000000
+                       00000000 FFFFFFFF FFFFFFFF FFFFFFFF
+
+      B         := 0x  5AC635D8 AA3A93E7 B3EBBD55 769886BC
+                       651D06B0 CC53B0F6 3BCE3C3E 27D2604B
+
+      q         := 0x  FFFFFFFF 00000000 FFFFFFFF FFFFFFFF
+                       BCE6FAAD A7179E84 F3B9CAC2 FC632551
+
+      G         := 0x  04
+                       6B17D1F2 E12C4247 F8BCE6E5 63A440F2
+                       77037D81 2DEB33A0 F4A13945 D898C296
+                       4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16
+                       2BCE3357 6B315ECE CBB64068 37BF51F5
+
+      KSAK      := 0x  12345;
+
+      KPAK      := 0x  04
+                       50D4670B DE75244F 28D2838A 0D25558A
+                       7A72686D 4522D4C8 273FB644 2AEBFA93
+                       DBDD3755 1AFD263B 5DFD617F 3960C65A
+                       8C298850 FF99F203 66DCE7D4 367217F4
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove                      Experimental                     [Page 14]
+
+RFC 7859                Identity-Based Signatures               May 2016
+
+
+   The remaining steps to creating a private key for the ID use the same
+   "random" value v as Appendix A of [RFC6507] and are:
+
+      v         := 0x  23456
+
+      PVT       := 0x  04
+                       758A1427 79BE89E8 29E71984 CB40EF75
+                       8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9
+                       A79D2476 92F4EDA3 A6BDAB77 D6AA6474
+                       A464AE49 34663C52 65BA7018 BA091F79
+
+      HS        := hash( 0x 04
+                            6B17D1F2 E12C4247 F8BCE6E5 63A440F2
+                            77037D81 2DEB33A0 F4A13945 D898C296
+                            4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16
+                            2BCE3357 6B315ECE CBB64068 37BF51F5
+                            04
+                            50D4670B DE75244F 28D2838A 0D25558A
+                            7A72686D 4522D4C8 273FB644 2AEBFA93
+                            DBDD3755 1AFD263B 5DFD617F 3960C65A
+                            8C298850 FF99F203 66DCE7D4 367217F4
+                            C0000200
+                            04
+                            758A1427 79BE89E8 29E71984 CB40EF75
+                            8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9
+                            A79D2476 92F4EDA3 A6BDAB77 D6AA6474
+                            A464AE49 34663C52 65BA7018 BA091F79 )
+
+                 = 0x  F64FFD76 D2EC3E87 BA670866 C0832B80
+                       B740C2BA 016034C8 1A6F5E5B 5F9AD8F3
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove                      Experimental                     [Page 15]
+
+RFC 7859                Identity-Based Signatures               May 2016
+
+
+   The remaining steps to creating a signature for M use the same
+   "random" value j as Appendix A of [RFC6507] and are:
+
+      j         := 0x  34567
+
+      J         := 0x  04
+                       269D4C8F DEB66A74 E4EF8C0D 5DCC597D
+                       DFE6029C 2AFFC493 6008CD2C C1045D81
+                       6DDA6A13 10F4B067 BD5DABDA D741B7CE
+                       F36457E1 96B1BFA9 7FD5F8FB B3926ADB
+
+      r         := 0x  269D4C8F DEB66A74 E4EF8C0D 5DCC597D
+                       DFE6029C 2AFFC493 6008CD2C C1045D81
+
+      HE        := hash( 0x
+                         F64FFD76 D2EC3E87 BA670866 C0832B80
+                         B740C2BA 016034C8 1A6F5E5B 5F9AD8F3
+                         269D4C8F DEB66A74 E4EF8C0D 5DCC597D
+                         DFE6029C 2AFFC493 6008CD2C C1045D81
+                         0073002D 00000000 00080110 01640010
+                         01580580 03C00002 01020304 05000E02
+                         50000100 03340104 04020201 00       )
+
+                 = 0x  FE236B30 CF72E060 28E229ED 5751D796
+                       91DED33C 24D2F661 28EA0804 30D8A832
+
+      s'        := 0x  C8C739D5 FB3EFB75 221CB818 8CAAB86A
+                       2E2669CF 209EA622 7D7072BA A83C2509
+
+      s         := 0x  C8C739D5 FB3EFB75 221CB818 8CAAB86A
+                       2E2669CF 209EA622 7D7072BA A83C2509
+
+      Signature := 0x  269D4C8F DEB66A74 E4EF8C0D 5DCC597D
+                       DFE6029C 2AFFC493 6008CD2C C1045D81
+                       C8C739D5 FB3EFB75 221CB818 8CAAB86A
+                       2E2669CF 209EA622 7D7072BA A83C2509
+                       04
+                       758A1427 79BE89E8 29E71984 CB40EF75
+                       8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9
+                       A79D2476 92F4EDA3 A6BDAB77 D6AA6474
+                       A464AE49 34663C52 65BA7018 BA091F79
+
+
+
+
+
+
+
+
+
+
+Dearlove                      Experimental                     [Page 16]
+
+RFC 7859                Identity-Based Signatures               May 2016
+
+
+Acknowledgments
+
+   The author would like to thank his colleagues who have been involved
+   in identity-based security for ad hoc networks, including (in
+   alphabetical order) Alan Cullen, Peter Smith, and Bill Williams.  He
+   would also like to thank Benjamin Smith (INRIA/Ecole Polytechnique)
+   for independently recreating the signature and other values in
+   Appendix A to ensure their correctness, and Thomas Clausen (Ecole
+   Polytechnique) for additional comments.
+
+Author's Address
+
+   Christopher Dearlove
+   BAE Systems Applied Intelligence Laboratories
+   West Hanningfield Road
+   Great Baddow, Chelmsford
+   United Kingdom
+
+   Phone: +44 1245 242194
+   Email: chris.dearlove@baesystems.com
+   URI:   http://www.baesystems.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove                      Experimental                     [Page 17]
+