< draft-jholland-mboned-ambi-01.txt   draft-jholland-mboned-ambi-02.txt >
Mboned J. Holland Mboned J. Holland
Internet-Draft K. Rose Internet-Draft K. Rose
Intended status: Experimental Akamai Technologies, Inc. Intended status: Experimental Akamai Technologies, Inc.
Expires: April 26, 2019 October 23, 2018 Expires: October 28, 2019 April 26, 2019
Asymmetric Manifest-Based Integrity Asymmetric Manifest Based Integrity
draft-jholland-mboned-ambi-01 draft-jholland-mboned-ambi-02
Abstract Abstract
This document introduces Asymmetric Manifest-Based Integrity (AMBI). This document defines Asymmetric Manifest-Based Integrity (AMBI).
AMBI allows each receiver of a stream of multicast packets to check AMBI allows each receiver of a stream of multicast packets to check
the integrity of the contents of each packet in the data stream. the integrity of the contents of each packet in the data stream.
AMBI operates by employing a cryptographically-verifiable, loss- AMBI operates by passing cryptographically verifiable manifests for
resilient sequence of manifests containing integrity information for the data packets, over out-of-band communication channels.
both data and integrity packet payloads.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2019. This Internet-Draft will expire on October 28, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Comparison with TESLA . . . . . . . . . . . . . . . . . . 4 1.1. Comparison with TESLA . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Protocol Specification . . . . . . . . . . . . . . . . . . . 4 2. Protocol Specification . . . . . . . . . . . . . . . . . . . 4
2.1. Packet Identifiers . . . . . . . . . . . . . . . . . . . 4 2.1. Packet Identifiers . . . . . . . . . . . . . . . . . . . 4
2.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. RTP Sequence Number . . . . . . . . . . . . . . . . . 5 2.1.2. RTP Sequence Number . . . . . . . . . . . . . . . . . 5
2.1.3. SRTP Sequence Number . . . . . . . . . . . . . . . . 6 2.1.3. SRTP Sequence Number . . . . . . . . . . . . . . . . 5
2.1.4. UDP Option . . . . . . . . . . . . . . . . . . . . . 6 2.1.4. UDP Option . . . . . . . . . . . . . . . . . . . . . 5
2.2. Anchor Message . . . . . . . . . . . . . . . . . . . . . 6 2.2. Anchor Message . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. DNS-based Anchor URI Bootstrap . . . . . . . . . . . 6 2.2.2. DNS-based Anchor URI Bootstrap . . . . . . . . . . . 6
2.2.3. Anchor Message YANG model . . . . . . . . . . . . . . 7 2.2.3. Anchor Message YANG model . . . . . . . . . . . . . . 7
2.2.4. Example Anchor Message . . . . . . . . . . . . . . . 14 2.2.4. Example Anchor Message . . . . . . . . . . . . . . . 14
2.3. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 15 2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2. Example Manifest Layout . . . . . . . . . . . . . . . 16 2.3.2. Manifest Layout . . . . . . . . . . . . . . . . . . . 15
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
4.1. Packet Identifiers . . . . . . . . . . . . . . . . . . . 18 4.1. Packet Identifiers . . . . . . . . . . . . . . . . . . . 18
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Normative References . . . . . . . . . . . . . . . . . . 18 5.1. Normative References . . . . . . . . . . . . . . . . . . 19
5.2. Informative References . . . . . . . . . . . . . . . . . 18 5.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Multicast transport poses security problems that are not easily Multicast transport poses security problems that are not easily
addressed by the same security mechanisms used for unicast transport. addressed by the same security mechanisms used for unicast transport.
The "Introduction" sections of the documents describing TESLA The "Introduction" sections of the documents describing TESLA
[RFC4082], and TESLA in SRTP [RFC4383], and TESLA with ALC and NORM [RFC4082], and TESLA in SRTP [RFC4383], and TESLA with ALC and NORM
[RFC5776] present excellent overviews of the challenges unique to [RFC5776] present excellent overviews of the challenges unique to
multicast authentication, briefly summarized here: multicast authentication, briefly summarized here:
skipping to change at page 3, line 11 skipping to change at page 3, line 9
o An asymmetric signature of a larger message comprising multiple o An asymmetric signature of a larger message comprising multiple
packets requires reliable receipt of all such packets, something packets requires reliable receipt of all such packets, something
that cannot be guaranteed in a timely manner even for protocols that cannot be guaranteed in a timely manner even for protocols
that do provide reliable delivery, and the retransmission of which that do provide reliable delivery, and the retransmission of which
may anyway exceed the useful lifetime for data formats that can may anyway exceed the useful lifetime for data formats that can
otherwise tolerate some degree of loss. otherwise tolerate some degree of loss.
Aymmetric Manifest-Based Integrity (AMBI) specifies a method for Aymmetric Manifest-Based Integrity (AMBI) specifies a method for
receivers or middle boxes to cryptographically authenticate and receivers or middle boxes to cryptographically authenticate and
verify the integrity of a stream of data packets by communicating verify the integrity of a stream of packets, by communicating packet
integrity-protecting hashes chained from an asymmetrically-signed "manifests" (described in Section 2.3) via an out-of-band
root in a way that is robust to packet loss. communication channel that provides authentication and verifiable
integrity.
Integrity-protecting hashes are assembled into discrete "manifests"
that are 1:1 with data packets and have a fixed maximum size that is
a function only of the hash output size, packet identifier size, and
(for the root manifest) asymmetric signature length. Each hash is
computed over the contents of a specific data payload and associated
manifest. Manifests may be communicated either in-band (e.g.,
appended to or otherwise incorporated into the payload of the
associated data packet) or out-of-band (in an associated channel with
similar or better reliability characteristics).
TBD: It would be really nice if the signature were not in the root
manifest itself, as that potentially complicates in-band integrity
protection.
To achieve robustness of integrity information in the face of packet Each manifest contains cryptographic hashes of packet payloads
loss, we employ a variant of the scheme described in [STRAUTH] to corresponding to specific packets in the authenticated data stream.
structure the manifests. Manifests are described in more detail in
Section 2.3.
A root manifest is authenticated by a signature in an "anchor Each manifest MUST be delivered in a manner that provides
message", itself authenticated using some pre-established trust cryptographic integrity of the manifest. For example, TLS or IPSec
relationship. Anchor messages are described in greater detail in may be used to deliver a stream of manifests with unicast from a
Section 2.2. trusted sender to many receivers, or another mechanism that provides
authentication for a multicast stream, such as a protocol which signs
each packet, could be used to provide authentication for the
manifests.
The use of a single signature to authenticate a large sequence of Upon successful verification of the contents of a manifest and
data packets allows the sender and receiver to amortize the receipt of any subset of the corresponding data packets, the receiver
computational overhead of asymmetric authentication across enough has proof of the integrity of the contents of the data packets listed
data packets to sustain high data rates. Furthermore, the use of in the manifest.
asymmetric authentication allows for asynchronous distribution of
authentication information, something not possible with TESLA.
Upon successful authentication of a root manifest and verification of An "anchor message", described in Section 2.2, provides the link
the chain of hashes required to establish the integrity of a between an authenticated data stream and the out-of-band channel of
particular data payload, the corresponding payload may be delivered manifests that authenticates it. This document defines a DNS-based
to the application (in the case of a client) or relayed to the next method for a sender to advertise a URI that can be used to retrieve
hop (in the case of a middle box). the anchor message over a secure transport. The anchor message MAY
also be provided by other out-of-band mechanisms that provide
integrity guarantees for the anchor message. Describing alternate
methods is out of scope for this document.
Authenticating the integrity of the data packets depends on: Authenticating the integrity of the data packets depends on:
o authentication of the anchor message that provides the linkage o authentication of the anchor message that provides the linkage
between the data stream, the manifest channel, and the root between the manifest channel and the data stream; and
manifest authentication key;
o the secrecy and cryptographic strength of private keys used for o the secrecy and cryptographic strength of private keys used for
signing the root manifests; and signing manifests, or the authentication of the secure channels
used for transmitting manifests; and
o the difficulty of generating a collision for the hashes in the o the difficulty of generating a collision for the packet hashes in
manifests. the manifest.
1.1. Comparison with TESLA 1.1. Comparison with TESLA
AMBI and TESLA [RFC4082] and [RFC5776] attempt to achieve a similar AMBI and TESLA [RFC4082] and [RFC5776] attempt to achieve a similar
goal of authenticating the integrity of streams of multicast packets. goal of authenticating the integrity of streams of multicast packets.
AMBI imposes a higher overhead, as measured in the amount of extra AMBI imposes a higher overhead, as measured in the amount of extra
data required, than TESLA imposes. In exchange, AMBI provides non- data required, than TESLA imposes. In exchange, AMBI provides non-
repudiation (which TESLA does not), and relaxes the requirement for repudiation (which TESLA does not), and relaxes the requirement for
establishing an upper bound on clock synchronization between sender establishing an upper bound on clock synchronization between sender
and receiver. and receiver.
This tradeoff enables new capabilities for AMBI, relative to TESLA. This tradeoff enables new capabilities for AMBI, relative to TESLA.
In particular, when receiving multicast traffic from an untrusted In particular, when receiving multicast traffic from an untrusted
transit network, AMBI can be used by a middle box to authenticate transit network, AMBI can be used by a middle box to authenticate
packets from a trusted source before forwarding traffic through the packets from a trusted source before forwarding traffic through the
network, and the receiver also can separately authenticate the network, and the receiver also can separately authenticate the
packets. This use case is not possible with TESLA because the data packets. (This use case is not possible with TESLA because the data
packets can't be authenticated until a key is disclosed, so either packets can't be authenticated until a key is disclosed, so either
the middlebox has to forward data packets without first the middlebox has to forward data packets without first
authenticating so that the receiver has them prior to key disclosure, authenticating so that the receiver has them prior to key disclosure,
or the middlebox has to hold packets until the key is disclosed, at or the middlebox has to hold packets until the key is disclosed, at
which point the receiver can no longer establish their authenticity. which point the receiver can no longer establish their authenticity.)
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Protocol Specification 2. Protocol Specification
2.1. Packet Identifiers 2.1. Packet Identifiers
2.1.1. Overview
A packet identifier is a sequence number contained within the 2.1.1. Overview
authenticated payload of a packet. The packet identifier is used in
a manifest to associate each integrity-protecting hash with a
specific data payload and integrity manifest.
Every packet containing either data or manifest MUST contain a packet Packet identifiers are a sequence number contained within the
identifier. If a data payload and its associated manifest are authenticated payload of the packet. This sequence number is used
contained in separate packets, this packet identifier MUST be the inside a manifest to associate each packet hash with a specific
same in both packets. packet. Each authenticated packet MUST contain a packet identifier.
See Section 4.1 for a discussion of the security implications.
This document defines a new UDP option in Section 2.1.4 for use as a This document defines a new UDP option in Section 2.1.4 for use as a
packet identifier. packet identifier.
Some multicast-capable transport protocols have a sequence number Some multicast-capable transport protocols have a sequence number
embedded in data packets in the protocol. The sequence numbers in embedded in data packets in the protocol. The sequence numbers in
these protocols MAY be used instead of the new UDP option, to avoid these protocols MAY be used instead of the new UDP option, to avoid
introducing extra overhead in the authenticated data packets. introducing extra overhead in the authenticated data packets.
In Section 2.1.2, Section 2.1.3, and Section 2.1.4, this document In Section 2.1.2, Section 2.1.3, and Section 2.1.4, this document
skipping to change at page 5, line 38 skipping to change at page 5, line 19
Other appropriate sequence number systems may exist, such as the Other appropriate sequence number systems may exist, such as the
anti-replay Sequence Number field in Section 3.1 of [RFC6584], when anti-replay Sequence Number field in Section 3.1 of [RFC6584], when
NORM or FLUTE operates with an authentication profile that uses it NORM or FLUTE operates with an authentication profile that uses it
(however, since that example already provides authentication, it is (however, since that example already provides authentication, it is
not added as an option in this document). The AMBI anchor message not added as an option in this document). The AMBI anchor message
format can be extended in future documents to support those or other format can be extended in future documents to support those or other
suitable schemes by adding values to the registry defined in suitable schemes by adding values to the registry defined in
Section 3. Section 3.
In some deployments, in contrast to using the new UDP option, the In some deployments, in contrast to using the new UDP option, the
approach of using an existing sequence number as packet identifier approach of using an existing sequence number may carry a benefit
may carry a benefit because, in combination with out-of-band because it requires no change to the stream of packets being
manifests, it requires no change to the data stream, possibly authenticated, enabling interoperability with existing unmodified
enabling interoperability with legacy receivers. sending and receiving applications.
2.1.2. RTP Sequence Number 2.1.2. RTP Sequence Number
Sequence number from Section 5.1 of [RFC3550]. Sequence number from Section 5.1 of [RFC3550].
TBD: discussion of security consequences of using 16 bits- recommend TBD: discussion of security consequences of using 16 bits-recommend a
a bigger hash in manifests for this case? bigger hash in manifests for this case?
2.1.3. SRTP Sequence Number 2.1.3. SRTP Sequence Number
Packet Index from Section 3.3.1 of [RFC3711]. Packet Index from Section 3.3.1 of [RFC3711].
2.1.4. UDP Option 2.1.4. UDP Option
Define a new UDP option [I-D.ietf-tsvwg-udp-options] (TBD2). Define a new UDP option [I-D.ietf-tsvwg-udp-options] (TBD2).
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Kind=TBD2 | Length=6 | 32-bit packet identifier | | UDP Kind=TBD2 | Length=6 | 32-bit sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2. Anchor Message 2.2. Anchor Message
2.2.1. Overview 2.2.1. Overview
An anchor message provides the information that makes it possible to An anchor message provides the information that makes it possible to
authenticate root manifests for a stream. An anchor message MAY be associate the manifests with the data packets they authenticate. ID
discovered and transmitted by any means providing adequate source values that appear as text integers in the anchor message also appear
authentication and data integrity to meet the security needs of the in the manifest binary data, with the anchor message providing
receiver. context on how to interpret the values.
An anchor message MAY be discovered and transmitted by any means
which provides adequate source authentication and data integrity to
meet the security needs of the receiver.
In order to support middle-box authentication, it is RECOMMENDED that In order to support middle-box authentication, it is RECOMMENDED that
senders arrange to distribute anchor messages according to the method senders arrange to distribute anchor messages according to the method
outlined in Section 2.2.2. outlined in Section 2.2.2.
2.2.2. DNS-based Anchor URI Bootstrap 2.2.2. DNS-based Anchor URI Bootstrap
TBD: This section needs to be updated for [STRAUTH]. This document defines a new DNS resource record (RR) to communicate a
URI for an AMBI anchor message to remote receivers of the sender's
traffic, so they can use it to authenticate traffic from the sender.
When a middle box tries to process a join for a specific source, if The sender is the owner of the RR, and configures the zone so that it
it is configured to perform authentication on SSM multicast channels contains an RR that provides a URI that can provide secure delivery
it can forward, it SHOULD make a DNS request for ambi.(reverse- of the an anchor message appropriate to authenticate all the sender's
source-ip).ip6.arpa or ambi.(reverse-source-ip).in-addr.arpa, for multicast traffic.
IPv6 or IPv4 source addresses.
When AMBI is provided to authenticate traffic from this source IP, This mechanism only works for source-specific multicast (SSM)
this domain name SHOULD be configured with a TXT field which contains channels. The source address of the (S,G) is reversed and used as an
a URI that can be used to securely fetch an anchor message that index into one of the reverse mapping trees (in-addr.arpa for IPv4,
describes all the AMBI- authenticatable traffic from this source IP. as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as
described in Section 2.5 of [RFC3596]).
Other methods MAY be used to discover and transfer an anchor message. When a middle box or receiver processes a join for a new source, if
The description of alternate methods is out of scope for this it is configured to perform authentication on SSM multicast channels
document. it can forward, the middle box can discover a URI to obtain the
anchor message by issuing a DNS request for the AMBI record of the
reverse IP of the source of the (S,G), then fetch the contents of the
resulting URI, validate it, and use it to authenticate traffic from
the source.
TBD: consider breaking up anchor message to avoid large, frequently TBD: consider breaking up anchor message to avoid large, frequently
changing anchors for sources with many groups. changing anchors for sources with many groups.
TBD: consider graceful rollover for anchors, instead of synchronized TBD: consider graceful rollover for anchors, instead of synchronized
update of anchor hash. update of anchor hash.
2.2.3. Anchor Message YANG model 2.2.3. Anchor Message YANG model
TBD: This section needs to be updated for [STRAUTH]. The anchor message is composed of a YANG instance object that
validates against the YANG model below.
<CODE BEGINS> file "ietf-ambi-anchor.yang" <CODE BEGINS> file "ietf-ambi-anchor.yang"
module ietf-ambi-anchor { module ietf-ambi-anchor {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ambi-anchor"; namespace "urn:ietf:params:xml:ns:yang:ietf-ambi-anchor";
prefix "ambi"; prefix "ambi";
import ietf-yang-types { import ietf-yang-types {
prefix "yang"; prefix "yang";
skipping to change at page 8, line 13 skipping to change at page 8, line 7
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of This version of this YANG module is part of
draft-jholland-mboned-ambi, draft-jholland-mboned-ambi, [TBD: change]
see the internet draft itself for full legal notices."; see the internet draft itself for full legal notices.";
revision 2018-06-27 { revision 2018-06-27 {
description "Initial revision."; description "Initial revision.";
reference reference
""; "";
} }
/* TBD: copied some from https://tools.ietf.org/html/rfc8177, /* TBD: copied some from https://tools.ietf.org/html/rfc8177,
but the model doesn't seem to match what I want. is there another but the model doesn't seem to match what I want. is there another
skipping to change at page 11, line 13 skipping to change at page 11, line 8
type yang:date-and-time; type yang:date-and-time;
mandatory true; mandatory true;
description description
"The expiration time for this anchor message."; "The expiration time for this anchor message.";
} }
} }
description "Anchor message for AMBI"; description "Anchor message for AMBI";
list public_key { list public_key {
key id; key id;
description "Public key for non-recursive manifest"; description "Public key for ALTI signatures.";
leaf id { leaf id {
type key-identifier; type key-identifier;
mandatory true; mandatory true;
description description
"The key identifier referenced in a manifest."; "The key identifier referenced in a manifest.";
} }
leaf algorithm { leaf algorithm {
type identityref { type identityref {
base crypto-signature; base crypto-signature;
} }
skipping to change at page 14, line 4 skipping to change at page 13, line 47
type identityref { type identityref {
base sequence-type; base sequence-type;
} }
mandatory true; mandatory true;
description description
"The linkage to the data packet sequence numbers in "The linkage to the data packet sequence numbers in
the manifest."; the manifest.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 1: Anchor Message YANG model Figure 1: Anchor Message YANG model
2.2.4. Example Anchor Message 2.2.4. Example Anchor Message
TBD: This section needs to be updated for [STRAUTH].
{ {
"ietf-ambi-anchor:anchor": { "ietf-ambi-anchor:anchor": {
"self": { "self": {
"uri": "https://example.com/ambi/anchor/example_1.json", "uri": "https://example.com/ambi/anchor/example_1.json",
"version": 1, "version": 1,
"hash_algorithm": "blake2b", "hash_algorithm": "blake2b",
"hash_bits": 256, "hash_bits": 256,
"expires": "2018-03-05T23:59:59Z" "expires": "2018-03-05T23:59:59Z"
}, },
"public_key": [ "public_key": [
skipping to change at page 15, line 35 skipping to change at page 15, line 28
] ]
} }
} }
Figure 2: Example Anchor Message Figure 2: Example Anchor Message
2.3. Manifests 2.3. Manifests
2.3.1. Overview 2.3.1. Overview
A manifest contains a sequence of hashes of data and corresponding A manifest cannot be interpreted except in context of a known anchor
manifest payloads according to the DAG schema defined in section 3 of message.
[STRAUTH]. Additionally, a root manifest contains a public key
signature to allow for authentication against an anchor message.
o TBD: insert more details about the construction here
* Constructive description of scheme for p=1 and p>1
* How to choose the packets according to different settings of p
* Hash construction H(data,manifest)
* Possible hash algorithms and truncation
A manifest M_j cannot be interpreted except in the context of a known
anchor message authenticating a root manifest M_0, and a sequence of
hashes h_i, manifests M_i, and data payloads D_i for 1 <= i <= j such
that h_i is contained in the manifest M_{i-1} and such that
h_i=H(D_i,M_i).
For a root manifest to be considered authentic, the anchor version in
the manifest MUST match the value in a known unexpired anchor message
and the signature of the root manifest MUST be authentic according to
the public key in the anchor message.
A manifest MAY omit the packet identifier associated with a
particular hash if the underlying packet stream employs packet
identifiers that are implicit from the structure of the integrity DAG
scheme and from the offset within the augmented chain. For example,
packet identifiers that increment by exactly one in successive data
packets and which overflow to zero would have this property.
2.3.2. Example Manifest Layout In order for a manifest to be considered as potentially
authenticating a set of packets, the Anchor Version MUST match the
value in a known unexpired anchor message, and the Anchor Hash MUST
match the hash of the contents of that anchor message, according to
the /anchor/self/hash_algorithm and /anchor/self/hash_bits fields, in
order for a manifest to be accepted for use as evidence of
authenticity and integrity.
The following describes the manifest layout for an integrity scheme A manifest also MUST NOT be accepted unless it has verified
employing a hash with an output of 256 bits and an explicit packet authenticity and integrity, either because it contains a
identifier space of 32 bits. This can be extended to other hash cryptographic signature, or because it appeared in a secured unicast
ranges and packet identifier spaces in the obvious way. With a stream, or because another verified manifest has provided the packet
sufficiently-strong hash function, the packet identifier may also be hash for a packet containing this manifest.
safely truncated to the maximum possible window size for useful in-
flight data to save bits while avoiding trial hash comparison.
Given: * Manifest packet identifier i_0 * Augmented chain offset f * 2.3.2. Manifest Layout
k <= 5 * k is implicit from the chosen DAG scheme and from offset f
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=0 | Reserved | f | Anchor Version | | Ver=0 | Reserved=0 |P|S| Anchor Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Identifier i_1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Anchor Hash (variable length, 4-octet aligned, 0-padded) |
| Hash H(D_{i_1},M_{i_1}) | | ... |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | Manifest ID | Packet Hash Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Identifier i_k | | First Packet Hash Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Packet Identifier Step (if S-bit set) |
| Hash H(D_{i_k},M_{i_k}) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Cryptographic Signature (if a root manifest) | | ... Packet Hashes ... |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.3.2.1. Ver (Protocol Version)
MUST be set to 0 by senders, and if a nonzero value is received this
message MUST NOT be accepted or processed as a manifest.
For manifests streams which were authenticated by a means other than
cryptographic signature, it is RECOMMENDED that authenticators stop
following this manifest stream and refresh the anchor if they receive
an invalid version.
For manifest streams authenticated by signature, it is RECOMMENDED
that authenticators remain joined to this stream and ignore this
packet, as the manifest MAY have been sent maliciously.
An authenticator MAY implement a rate limit on invalid manifests and
drop the stream if the rate is exceeded.
2.3.2.2. Reserved
MUST be set to 0 by senders and MUST be ignored by receivers.
2.3.2.3. P ("Purge" bit)
If this bit is 1, the anchor message this manifest specifies MUST be
purged by authenticators who accept this manifest, so that it cannot
be used to authenticate future manifests unless it was re-fetched.
2.3.2.4. S ("Step" bit)
If this bit is 1, the "Packet Identifier Step" field is present in
this manifest, else it is not.
2.3.2.5. Anchor Version
The value from the "/anchor/self/version" field in the anchor
message. If no unexpired anchor message with this version is known
to the authenticator, this manifest MUST NOT be accepted.
2.3.2.6. Anchor Hash
The hash of the anchor message, using the algorithm indicated by the
"/anchor/self/hash_algorithm" field, using the first bits from the
hash up to the number of bits indicated by the "/anchor/self/
hash_bits" field in the anchor message.
If the hash of an anchor message with this version does not match the
bits in this field, this manifest MUST NOT be accepted.
This field is padded at the end with 0-bits until the end is 4-octet
aligned.
2.3.2.7. Manifest ID
The value from "/anchor/manifest_stream/id" in the anchor message
corresponding to the manifest stream this manifest is a part of.
2.3.2.8. First Packet Hash Identifier
The packet number corresponding to the first packet hash that's
contained in this manifest. This refers to a value in a data packet
described by the "/anchor/manifest_stream/sequence_type" field for
this manifest stream.
2.3.2.9. Packet Identifier Step
If the "S bit" is 0, this field is not present in the manifest.
If the "S bit" is 1, this field is repeatedly added to the First
Packet Hash Identifier using 32-bit signed arithmetic to determine
the packet number of subsequent hashes.
2.3.2.10. Packet Hash Count
The number of hashes contained in the Packet Hashes section.
2.3.2.11. Packet Hashes
Concatenated Hashes of the data packets authenticated by this
manifest. The hash covers the IP payload of the packet, it is
calculated with the algorithm indicated by the "/anchor/
manifest_stream" object from the anchor message, with an "id" field
matching the "Manifest ID" field, with the algorithm and number of
bits equal to the "hash_algorithm" and "hash_bits"field from that
object. The hashes are concatenated without padding, except the last
octet is padded with 0 if necessary.
3. IANA Considerations 3. IANA Considerations
TBD1: Request a "Specification Required" registry for Packet TBD1: Request a "Specification Required" registry for Packet
identifier methods, from https://tools.ietf.org/html/rfc5226#section- identifier methods, from https://tools.ietf.org/html/rfc5226#section-
4.1 . Reserve anything beginning with "experimental:"? 4.1 . Reserve anything beginning with "experimental:"?
TBD2: Add a new entry to the "UDP Option Kind" numbers registry: TBD2: Add a new entry to the "UDP Option Kind" numbers registry:
https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options- https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-
02#section-14 02#section-14
TBD: check guidelines in https://tools.ietf.org/html/rfc5226 and TBD: check guidelines in https://tools.ietf.org/html/rfc5226 and
remove this paragraph remove this paragraph
Example from: https://tools.ietf.org/html/rfc5226#section-5.1 Example from: https://tools.ietf.org/html/rfc5226#section-5.1
TBD: new Resource Record type with a URI in the RRData? Or should
this be done as a NAPTR + URI chain?
[TO BE REMOVED: Please add the yang model in Section 2.2.3 to: [TO BE REMOVED: Please add the yang model in Section 2.2.3 to:
https://www.iana.org/assignments/yang-parameters/yang- https://www.iana.org/assignments/yang-parameters/yang-
parameters.xhtml parameters.xhtml
Name:ietf-ambi-anchor Maintained by IANA: N Namespace: Name:ietf-ambi-anchor Maintained by IANA: N Namespace:
urn:ietf:params:xml:ns:yang:ietf-ambi-anchor Prefix: anchor urn:ietf:params:xml:ns:yang:ietf-ambi-anchor Prefix: anchor
Reference: I-D.draft-jholland-mboned-ambi Notes: ] Reference: I-D.draft-jholland-mboned-ambi Notes: ]
4. Security Considerations 4. Security Considerations
4.1. Packet Identifiers 4.1. Packet Identifiers
TBD: explain attack from generating malicious packets and then TBD: explain attack from generating malicious packets and then
looking for collisions, as opposed to having to generate a collision looking for collisions, as opposed to having to generate a collision
including a packet identifier and then hitting a match including a sequence number and then hitting a match
TBD: DNSSEC vis-a-vis anchor url discovery. (we need a diagram about TBD: DNSSEC vis-a-vis anchor url discovery. (we need a diagram about
for middle-box handling of a revers-path propagated join?) Explain for middle-box handling of a revers-path propagated join?) Explain
why malicious DNS could deny service, but cannot cause accepting why malicious DNS could deny service, but cannot cause accepting
attack packets. attack packets.
TBD: Is the purge bit sufficient to cover when a key is found to be
leaked?
TBD: follow the rest of the guidelines: https://tools.ietf.org/html/ TBD: follow the rest of the guidelines: https://tools.ietf.org/html/
rfc3552 rfc3552
5. References 5. References
5.1. Normative References 5.1. Normative References
[I-D.ietf-tsvwg-udp-options] [I-D.ietf-tsvwg-udp-options]
Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- Touch, J., "Transport Options for UDP", draft-ietf-tsvwg-
udp-options-05 (work in progress), July 2018. udp-options-07 (work in progress), March 2019.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", STD 88,
RFC 3596, DOI 10.17487/RFC3596, October 2003,
<https://www.rfc-editor.org/info/rfc3596>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
5.2. Informative References 5.2. Informative References
[DIGSIGN] Rohatgi, P., "How to Sign Digital Streams", 1997, [DIGSIGN] Rohatgi, P., "How to Sign Digital Streams", 1997,
<https://link.springer.com/content/pdf/10.1007/ <https://link.springer.com/content/pdf/10.1007/
BFb0052235.pdf>. BFb0052235.pdf>.
skipping to change at page 19, line 30 skipping to change at page 20, line 34
Reliable Multicast (NORM) Protocols", RFC 5776, Reliable Multicast (NORM) Protocols", RFC 5776,
DOI 10.17487/RFC5776, April 2010, DOI 10.17487/RFC5776, April 2010,
<https://www.rfc-editor.org/info/rfc5776>. <https://www.rfc-editor.org/info/rfc5776>.
[RFC6584] Roca, V., "Simple Authentication Schemes for the [RFC6584] Roca, V., "Simple Authentication Schemes for the
Asynchronous Layered Coding (ALC) and NACK-Oriented Asynchronous Layered Coding (ALC) and NACK-Oriented
Reliable Multicast (NORM) Protocols", RFC 6584, Reliable Multicast (NORM) Protocols", RFC 6584,
DOI 10.17487/RFC6584, April 2012, DOI 10.17487/RFC6584, April 2012,
<https://www.rfc-editor.org/info/rfc6584>. <https://www.rfc-editor.org/info/rfc6584>.
[STRAUTH] Modadugu, N., "Authenticating Streamed Data in the
Presence of Random Packet Loss", 2001,
<https://crypto.stanford.edu/~pgolle/papers/auth.pdf>.
ISOC Network and Distributed System Security Symposium
Authors' Addresses Authors' Addresses
Jake Holland Jake Holland
Akamai Technologies, Inc. Akamai Technologies, Inc.
150 Broadway 150 Broadway
Cambridge, MA 02144 Cambridge, MA 02144
United States of America United States of America
Email: jakeholland.net@gmail.com Email: jakeholland.net@gmail.com
Kyle Rose Kyle Rose
Akamai Technologies, Inc. Akamai Technologies, Inc.
150 Broadway 150 Broadway
Cambridge, MA 02144 Cambridge, MA 02144
United States of America United States of America
Email: krose@krose.org Email: krose@krose.org
 End of changes. 55 change blocks. 
167 lines changed or deleted 220 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/