Internet DRAFT - draft-rass-panrg-mpath-usecase
draft-rass-panrg-mpath-usecase
Internet S. Rass
Internet-Draft Universitaet Klagenfurt
Intended status: Informational Y. Qu
Expires: March 13, 2020 L. Han
Futurewei
September 10, 2019
Multipath Use Case and Requirement for Security
draft-rass-panrg-mpath-usecase-01
Abstract
This document describes a use case of multipath to achieve full CIA+
by using symmetric cryptography and point-to-point shared secrets.
Status of This Memo
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 https://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 March 13, 2020.
Copyright Notice
Copyright (c) 2019 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
(https://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.
Rass, et al. Expires March 13, 2020 [Page 1]
Internet-Draft Mpath security use case September 2019
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Multipath Routing . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Multi-path Service and User-Network Interface . . . . . . 4
3.2. Path and Routing Reliability . . . . . . . . . . . . . . 4
3.3. Cross Domain Path Reliability . . . . . . . . . . . . . . 5
3.4. Cross Domain Network Connections . . . . . . . . . . . . 5
3.5. Updates upon Changing Network Topologies . . . . . . . . 5
3.6. Enforced Device Pairing and De-Pairing . . . . . . . . . 6
4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Cryptographic and Graph-Theoretic Basics . . . . . . 9
A.1. Secret Sharing . . . . . . . . . . . . . . . . . . . . . 9
A.2. Network Connectivity . . . . . . . . . . . . . . . . . . 9
Appendix B. Multipath Transmission and Game-Theoretic Security . 10
B.1. End-to-end Confidentiality - Parallel Version . . . . . . 10
B.2. End-to-end Confidentiality - Sequential-Parallel Version 10
B.3. Randomized Routing to Maximize Security against Node
(Failures) . . . . . . . . . . . . . . . . . . . . . . . 11
B.4. Availability . . . . . . . . . . . . . . . . . . . . . . 12
B.5. End-to-End Authenticity . . . . . . . . . . . . . . . . . 12
B.5.1. Non-Repudiation . . . . . . . . . . . . . . . . . . . 13
B.6. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
Public-key cryptography is a convenient tool for end-to-end security,
but in practice can be cumbersome or complicated for non-expert users
to apply. Certificate- and key management rely on complex
infrastructures and to a significant extent impose monetary cost and
human effort.
This document describes a method of using symmetric cryptography and
point-to-point shared secrets to establish full CIA+
(confidentiality, integrity, availability and authenticity) end-to-
end security. The respective schemes rely on multipath transmission
and threshold cryptography, and are intended to work transparently
for the users, i.e., entirely below the application layer. The only
involvement of human action is for the key establishment, which is in
Rass, et al. Expires March 13, 2020 [Page 2]
Internet-Draft Mpath security use case September 2019
our setting equivalent to a pairing of devices, as is familiar from
other contexts, such as Bluetooth.
1.1. Requirements Language
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. Assumptions
We assume a network of bidirectional links, represented as an
undirected graph G=(V,E). An edge e=(v_1, v_2) in the set E
represents a point-to-point connection between the nodes v_1 and v_2
in the network. We assume that every such pair (v_i, v_j) in E
shares an individual secret k_ij, which is individually distinct for
all edges (i.e., no two pairs have, other than by coincidence, the
same secret). The secret exchange or establishment is left to
arbitrary means, e.g., any device pairing scheme
[I-D.ietf-dnssd-pairing] or cryptographic methods like Diffie-Hellman
key exchange [RFC2631] would be admissible, up to quantum key
distribution [BB84]. Indeed, end-to-end security in quantum networks
is the most natural application area of multipath transmission as we
discuss here.
We further assume that keys between adjacent nodes in the network
have been exchanged in an authentic manner; say, by sufficient
proximity during the device pairing (e.g., near field communication).
3. Multipath Routing
Multipath routing offers the remarking ability of establishing
public-key like security without computational intractability. This
means that periodic updates of keys or server certificates are no
longer required in such systems; updates to keys for symmetric crypto
are much easier by device re-pairing or refreshing keys from existing
key material, such as is done in quantum key distribution (QKD).
Multipath transmission, requiring no quantum technology per se,
offers nonetheless the same level of security QKD [BB84] and can
resist attacks by quantum computers (like post-quantum cryptography
[BD08]).
The key element to this end is using multiple paths to send a
message, which in the simplest instance is just like humble symmetric
encryption: consider two nodes A and B that have no direct connection
between them (i.e., A and B are several hops apart). Let us assume
that two paths connect A to B, where those paths intersect only at A
and B (we call such paths node-disjoint). If so, then A can choose a
Rass, et al. Expires March 13, 2020 [Page 3]
Internet-Draft Mpath security use case September 2019
session key k that it sends to B over the first path, and deliver the
encrypted payload over the second path. If the encryption is chosen
properly (e.g., Vernam cipher [Ver55]) and the adversary does not
intercept both paths, the connection remains secure.
The scheme straightforwardly generalizes to more than two paths,
where the payload is (always) split into shares and transmitted over
separate paths in parallel or sequentially. Security comes from the
proper encoding/creation of the pieces so that an attacker needs to
intercept a certain number of paths in order to breach
confidentiality, insert a forged message, or cause a denial of
service. The fundamental circumstance implying security here is the
existence of k (>= 2) node and link disjoint paths, so that an
adversary needs to conquer at least k nodes in the network to breach
security (by mounting a person-in-the-middle attack).
Security (up to QKD without trusted relays) thus hinges on the
following network-related assumptions:
3.1. Multi-path Service and User-Network Interface
There are at least two disjoint paths between node A and node B, so A
can send packets to node B via different paths efficiently and
reliably.
New User-Network Interface (UNI) should be defined to exchange
information between end device/application and network. The
information may include but not limited to:
o User expectation: such as number of paths, bandwidth required etc.
o Path aware info: the network should dynamically provide end-device
information such as number of paths available, each path's
attributes: path reliability, routing quality, bandwidth, path
elements etc.
3.2. Path and Routing Reliability
The sender A can deliberately choose any among the existing paths to
its receiver B to transmit a message. The routing is reliable in the
sense that there is at least a probabilistic guarantee for the packet
to travel over exactly the chosen route with a likelihood p that A
can quantify (not necessarily control). In other words, the chances
for the path to be blocked, or for the packet to take a detour for
any reason (e.g., load balancing, temporary congestions, or similar)
is at most 1-p, with the value of p being known to A. The ideal case
p = 1 expresses that the chosen route has a perfect reliability
(i.e., no deviations and guaranteed delivery).
Rass, et al. Expires March 13, 2020 [Page 4]
Internet-Draft Mpath security use case September 2019
It is admissible to express the path reliability in terms of several
such probabilities, referring to different dimensions for the quality
of service. That is, we may define a probability p_1 for the packet
to stay on the chosen route, another probability p_2 for the packet
to be delivered at all (i.e., not being blocked), or similar.
There are per se no stringent constraints regarding latencies or for
several packets to arrive in the order of transmission, since the
outer (cryptographic) transmission protocols can handle this.
However, the aforementioned probabilities quantifying the quality of
routing need to be accurately known to the sender A. Suitable
protocols to handle path deviations (temporary detours) and to
optimize quality-of-service tradeoffs based on such knowledge are
found in the literature [Ras13], [RK12].
3.3. Cross Domain Path Reliability
If two distinct network domains are joined together, the topologies
of both networks are reliably made known to the nodes in the
respective other network. Chosen routes from one network into the
other must remain quantifiably reliable in the sense of section 3.2
above, i.e., a node A in one network must still be able to determine
a probability p for a packet to stay on its route and to arrive at
the designated destination across all network domains that it
traverses.
3.4. Cross Domain Network Connections
Whenever a node A has an outside connection to a node in another
network domain N_2, A should not have a second connection to another
node in the same network domain N_2. That is, if two network domains
N_1 and N_2 are joined together via k links, those links should
pairwise connect k distinct nodes in N_1 to another k distinct nodes
in N_2. This assures that the so-constructed larger network retains
the necessary number of (at least) k node disjoint paths across the
domains (by avoiding bottle-neck connections between networks N_1 and
N_2).
3.5. Updates upon Changing Network Topologies
The information described under the preceding sections needs to
remain up-to-date whenever A wishes to send a packet somewhere.
Changing topologies such as in ad hoc networks call for a proper and
reliable updating scheme to A's local information about the network
topology. This includes also changes in topologies of remote network
domains (that the sender does not itself belong to).
Rass, et al. Expires March 13, 2020 [Page 5]
Internet-Draft Mpath security use case September 2019
3.6. Enforced Device Pairing and De-Pairing
Whenever a node X joins a network, it must establish shared secrets
(for cryptography) with any neighbor with whom it has a direct point-
to-point connection. Whenever a node X leaves the network, nodes
losing the connection to X need to abandon their cryptographic key
formerly assigned to the connection with X. The key exchange
protocols can be arbitrary (cf. section 2), but the device pairing
must in any case be authenticated.
4. Summary
The ability to route messages along chosen paths in a network,
together with sufficient vertex connectivity and unique neighborhoods
for each node opens up the possibility to achieve end-to-end
security:
o without public-key cryptography.
o using only light-weight symmetric cryptographic primitives
(encryption and hashing).
o and with the most trivial key-management consisting of only the
exchange of keys between directly connected devices (along device
pairing).
5. Security Considerations
TBD.
6. Acknowledgements
TBD.
7. References
7.1. Normative References
[I-D.ietf-dnssd-pairing]
Huitema, C. and D. Kaiser, "Device Pairing Using Short
Authentication Strings", draft-ietf-dnssd-pairing-05 (work
in progress), October 2018.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
Rass, et al. Expires March 13, 2020 [Page 6]
Internet-Draft Mpath security use case September 2019
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, DOI 10.17487/RFC2631, June 1999,
<https://www.rfc-editor.org/info/rfc2631>.
[RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo,
"Reed-Solomon Forward Error Correction (FEC) Schemes",
RFC 5510, DOI 10.17487/RFC5510, April 2009,
<https://www.rfc-editor.org/info/rfc5510>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<https://www.rfc-editor.org/info/rfc6824>.
7.2. Informative References
[FFGV07] Matthias Fitzi, Matthew K. Franklin, Juan Garay, and S.
Harsha Vardhan, TCC, LNCS, vol. 4392, Springer, 2007, pp.
311--322., "Towards Optimal and Efficient Perfectly Secure
Message Transmission".
[MS81] R. J. McElice and D. V. Sarwate, Commun. ACM 24 (1981),
no. 9, 583--584., "On Sharing Secrets and Reed-Solomon
Codes".
[Ras13] Stefan Rass, Springer Journal of Network and Systems
Management 21 (2013), no. 1, 47--64., "On Game-Theoretic
Network Security Provisioning".
[Ras14] Stefan Rass, International Journal of Advanced Computer
Science and Applications 5 (2014), no. 2, 148--157.,
"Complexity of Network Design for Private Communication
and the P-vs-NP question".
[Ras18] Stefan Rass, CoRR abs/1810.05602 (2018)., "Perfectly
secure communication, based on graph- topological
addressing in unique-neighborhood networks".
[RS10] Stefan Rass and Peter Schartner, Proceedings of the
International Conference on Security and Management (SAM),
vol. 1, CSREA Press, 2010, pp. 111--115., "Multipath
Authentication without shared Secrets and with
Applications in Quantum Networks".
Rass, et al. Expires March 13, 2020 [Page 7]
Internet-Draft Mpath security use case September 2019
[Sha49] C. E. Shannon, Bell System Technical Journal 28 (1949),
656--715., "Communication Theory of Secrecy Systems".
[Sha79] Adi Shamir, ACM 22 (1979), no. 11, 612--613., "How to
share a secret".
Rass, et al. Expires March 13, 2020 [Page 8]
Internet-Draft Mpath security use case September 2019
Appendix A. Cryptographic and Graph-Theoretic Basics
A.1. Secret Sharing
We assume a message m to come as a binary string of length L. A
simple k-out-of-k secret sharing is by picking a set of k-1 random
strings s_1, s_2, ..., s_(k-1) of the same length as m and computes
s_k := m XOR s_1 XOR s_2 XOR ... XOR s_(k-1). Information-
theoretically, one can prove [Sha49] that the recovery of m is
impossible from any set of less than k of the strings s_1, ..., s_k
(since the missing string effectively acts as a one-time pad
concealing m).
The sharing as just described is replaceable by more sophisticated
schemes, such as Shamir's polynomial sharing [Sha79], which adds
error correction capabilities [MS81] via using an isomorphy to Reed-
Solomon encoding. We shall, however, hereafter not further relate to
standardized versions of Reed-Solomon forward error correcting codes
[LRPP09], but rather work with the above simple scheme instead.
Abstractly, we shall introduce a sharing function SPLIT(m, k) that
decomposes an input message m into a set of k shares according to any
scheme of choice (for the description in this document, the above
XOR-based scheme will suffice). The inverse of SPLIT will be the
function COMBINE(s_1, ..., s_k), taking k (out of a potentially
larger set) of shares to reconstruct the message m from it. Note
that COMBINE internally may invoke error correction algorithms
[LRPP09], which we do not further expand here.
A.2. Network Connectivity
If a node A wants to transmit a message m to a node B, we assume that
A can choose a path, or a set of paths through the network along a
physical connection (over multiple hops) to the end-node B. Further,
we assume that the network's node connectivity is such that more than
one route from A to B exists, and that at least two routes exist that
do not intersect other than at A and B (node-disjoint paths). It is
known that the existence of k node-disjoint paths is equivalent to
the graph admitting a k-vertex cut; equivalently, we call such a
graph k-vertex-connected. The smallest graph with that property is
the complete graph with k+1 nodes. Furthermore, if two k-vertex-
connected graphs are given, we can combine them into one (big) k-
vertex connected graph G as follows: we pick k distinct nodes u_1,
..., u_k in G_1 and another k distinct nodes v_1, ..., v_k in G_2,
and connect the two graphs by adding edges (u_i, v_i) for all
i=1,2,...,k. The resulting graph contains all nodes and edges from
G_1 and G_2, plus the connecting edges between the two graphs. It is
provably a k-vertex-connected graph, admitting at least k node-
Rass, et al. Expires March 13, 2020 [Page 9]
Internet-Draft Mpath security use case September 2019
disjoint paths between any two nodes in either graph and from any
node in G_1 to any node in G_2 and vice versa.
While it may not be too optimistic to hope for a large k in the
existing internet topology, matters of resilience against failure of
single nodes in the network call for a least k=2, so that the network
remains connected if one node (and hence the adjacent edge) fails.
Let A's available routes to B be enumerated as R_1, ..., R_k, which A
picks with likelihoods p_1, ..., p_k, say, p_i := 1/i for an
equiprobable choice of a single route. Moreover, we let each
transmission use their point-to-point shared secrets to encrypt a
message along the network edge (v_i, v_j) under the key k_ij (e.g.,
by means of the Advanced Encryption Standard or others).
Appendix B. Multipath Transmission and Game-Theoretic Security
B.1. End-to-end Confidentiality - Parallel Version
To confidentially transmit the message m, A proceeds as follows:
1. Decompose m into shares {s_1, ..., s_k} := SPLIT(m)
2. Send each share s_i over the route R_i (for i = 1, ..., k) in
parallel to B.
3. B, upon receiving all shares recovers the message as m :=
COMBINE(r_1, ..., r_k).
By construction, the attacker needs to gather all k shares to recover
m, so that if the attacker can intercept only less than k paths, the
message m remains perfectly concealed (by the aforementioned
arguments). A picture of the scheme is found at
https://www.syssec.at/user/themes/syssec-theme/images/publikationen/
MPTrans.png
B.2. End-to-end Confidentiality - Sequential-Parallel Version
The above scheme can be further strengthened by a two-stage sharing
as follows: as before, let m the message that A wishes to send to B
in perfect privacy. It proceeds as follows:
1. Decompose m into n shares {s_1, ..., s_n} := SPLIT(m)
2. For i = 1, 2, ..., n: send each share s_i by the parallel scheme
described above; resulting in the transmission of shares r_i1,
..., r_ik for the share s_i
Rass, et al. Expires March 13, 2020 [Page 10]
Internet-Draft Mpath security use case September 2019
3. The receiver B then needs to (i) reconstruct every share s_i :=
COMBINE(r_i1, ..., r_ik) (as in the parallel version above), and
(ii) reconstruct the overall message as m := COMBINE(s_1, ...,
s_n).
An attacker needs to intercept the entirety of shares for each
individual transmission, as well as for all the sequential
transmissions. Unless the attacker can mount a full person-in-the-
middle attack, the message m remains perfectly concealed. Even if
the attacker has a positive probability q < 0 to catch all shares for
a single transmission in step 2, the probability to catch the
entirety of n sequential shares (created in step 1) equals (1-q)^n
(the path choices are made stochastically independent). In choosing
n large enough, A can make the adversary's success chances
exponentially small.
B.3. Randomized Routing to Maximize Security against Node (Failures)
Suppose that the attacker can intercept a fixed maximum number t < k
of nodes, where k is the network's vertex connectivity. If the
network is such that certain routes are more or less reliable than
others (e.g., some routes may be easier to intercept for the
adversary or temporarily be unavailable), there is no obligation in
the above scheme to use the full set of paths per parallel
transmission. Instead, to transmit a share (whether in the parallel
or sequential-parallel version of the transmission), the sender may
randomly pick the route R_i with likelihood p_i, and transmit the
share over the chosen route.
Knowing the choice rules p_1, ..., p_k for the k routes that A can
choose from, the attacker may seek to compute an optimal strategy for
intercepting, resulting in probabilities q_1, ..., q_|V| for nodes to
attack (excluding the nodes for A and B here, since our security goal
is confidentiality, disregarding impersonation attacks for the
moment).
The optimal computation of probabilities to choose routes, and
individual likelihoods to intercept nodes amounts to a simple two-
person matrix game [Ras13], whose saddle-point value (computable by
means of linear optimization) systematically quantifies (bounds) the
likelihood for the attacker to succeed. For a simplified example,
assuming that all nodes are equally "easy" for the attacker to
conquer, yet with a bound to no more than 1 node to be under the
adversary's control at a time, the optimal choice for the sender A
would be an equiprobable pick among the routes, i.e., p_i := 1/k for
all i, and an equiprobable choice of victim nodes for the attacker
(here, we assumed that the sender uses only a single path at a time).
Rass, et al. Expires March 13, 2020 [Page 11]
Internet-Draft Mpath security use case September 2019
B.4. Availability
The XOR sharing used in Section 2.1 is vulnerable against packet loss
(whether this happens by coincidence or due the attacker's actions;
DoS attacks). Making the scheme resilient against packet loss or
damage calls for error correction capabilities within the COMBINE
function, e.g., using the methods described in [LRPP09]. A full-
fledged scheme using Reed-Solomon error correction towards optimized
availability and confidentiality is described by [FFGV07].
B.5. End-to-End Authenticity
Using a similar idea [RS10], authenticity of messages is
accomplishable by message authentication codes. Since the sender A
shares secrets only with her/his direct neighbors, it can only use
their secrets to attach a message authentication code. The receiver
B, being several hops away from A, does not know the secrets to
verify the MAC, but, thanks to its ability of chosen path routing,
can ask A's neighbors to verify the MACs on B's behalf.
Putting this to practice, A authenticates a message m for B as
follows, using the keys {k_1, ..., k_n} that A shares with its direct
neighbors in the network. We write MAC(m,k) to denote a message
authentication code (MAC) for a message m computed under the (secret)
key k. Moreover, let H be a cryptographically strong hash function
(e.g., SHA-3 or likewise).
1. A computes hash-MACs, e.g., using the HMAC scheme in [RFC2104],
and attaches the MACs {a_i := MAC(H(m), k_i) | i=1,2,...,n} to
the message.
2. B receives the message m' (say, over a multipath transmission
scheme with chosen routes as described above). To verify that m'
is authentic, B computes the hash h' = H(m') and asks A's
neighbors to verify the respective MACs. To this end, B contacts
the i-th neighbor of A on a chosen route, and sends the data {h',
a_i'} to A's neighbor with whom A shares the secret k_i. Here,
the value a_i' is the MAC that B received (which could equally
well have been corrupted).
3. A's neighbor no. i uses its secret k_i to verify if MAC(h',k_i)
=?= a_i'. It replies the result ("yes" or "no") back over the
same route as how the query came in. This process happens
concurrently at all of A's neighbors (for i = 1, ..., n).
4. B collects all replies and takes either a majority decision or
(in the most stringent setting) rejects if any of the replies
comes back negative.
Rass, et al. Expires March 13, 2020 [Page 12]
Internet-Draft Mpath security use case September 2019
A picture of the scheme is found at
https://www.syssec.at/user/themes/syssec-theme/images/publikationen/
MPAuth.png
The condition upon which B accepts A's message as authentic may
depend on how resilient one needs to be about an adversary
potentially manipulating the verification query to B. If B rejects
upon a single negative verification, then even an attacker that can
conquer only a single node on any of the chosen paths can mount a
denial-of-service. On the contrary, if B accepts the majority vote,
then the attacker needs to intercept (and manipulate) more than half
of the routes chosen.
The security of this scheme follows by similar arguments as in the
case for confidentiality: the scheme is secure as long as the
adversary cannot mount a full person-in-the-middle attack,
conditional on the attacker's inability to find hash-collisions (in
that sense, the scheme is, unlike the multipath transmission for
confidentiality), only computationally secure.
Note that confidentiality of the message against the verifying
neighbors is not directly addressed here beyond the point of sending
a hash of m for verification instead of the full message.
Heuristically, the message thus remains concealed to the extent of
the neighbor's inability to find a meaningful pre-image for the
received value h'. We assumed the neighbors to be honest, unless
being under the attacker's control, so that a denial-of-service or
intentionally incorrect response is in any case possible, and cannot
be ruled out by this protocol.
B.5.1. Non-Repudiation
Under proper graph topological properties, the above authentication
scheme, though based on symmetric cryptography only, shares the non-
repudiation feature of public-key digital signatures. In fact, if
the set of secrets shared between a node and its direct neighbors (or
a subset thereof) is unique, i.e., distinct, for each node, then no
other node than A can create the MAC-set attached to the message m.
Networks with that property are easy to recognize based on their
adjacency matrix [Ras18]; moreover, the "unique-neighborhood
property" is preserved upon the same network merging operations as
described above for k-vertex-connectivity.
B.6. Integrity
From the construction of Section 3.4, integrity is directly implied
by the use of hashes that additionally act as checksums. That is,
any distortion on the transmission line will with overwhelming
Rass, et al. Expires March 13, 2020 [Page 13]
Internet-Draft Mpath security use case September 2019
probability invalidate the MAC or inner hash, thus causing the
protocol to indicate this error. Conversely, if B accepts A's
message as authentic, integrity verification is accomplished in the
same blow, unless the attacker managed to forge the message as a
whole (in which case, integrity is also unhedgeable).
Authors' Addresses
Stafan Rass
Universitaet Klagenfurt
EMail: stefan.rass@aau.at
Yingzhen Qu
Futurewei
2330 Central Expressway
Santa Clara, CA 95050
USA
EMail: yingzhen.qu@futurewei.com
Lin Han
Futurewei
2330 Central Expressway
Santa Clara, CA 95050
USA
EMail: lin.han@futurewei.com
Rass, et al. Expires March 13, 2020 [Page 14]
