One document matched: draft-ietf-rmt-sec-discussion-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-rmt-sec-discussion-05"
ipr="pre5378Trust200902">
<front>
<title abbrev="Security and RMT Protocols">Security and Reliable Multicast
Transport Protocols: Discussions and Guidelines</title>
<author fullname="Brian Adamson" initials="B." surname="Adamson">
<organization>Naval Research Laboratory</organization>
<address>
<postal>
<street></street>
<city>Washington, DC</city>
<code>20375</code>
<country>USA</country>
</postal>
<email>adamson@itd.nrl.navy.mil</email>
<uri>http://cs.itd.nrl.navy.mil</uri>
</address>
</author>
<author fullname="Vincent Roca" initials="V." surname="Roca">
<organization>INRIA</organization>
<address>
<postal>
<street></street>
<city>Montbonnot</city>
<code>38334</code>
<country>France</country>
</postal>
<email>vincent.roca@inria.fr</email>
<uri>http://planete.inrialpes.fr/~roca/</uri>
</address>
</author>
<author fullname="Hitoshi Asaeda" initials="H" surname="Asaeda">
<organization>Keio University</organization>
<address>
<postal>
<!-- <street>Graduate School of Media and Governance</street>-->
<street>5322 Endo</street>
<city>Fujisawa</city>
<region>Kanagawa</region>
<code>252-8520</code>
<country>Japan</country>
</postal>
<email>asaeda@wide.ad.jp</email>
<uri>http://www.sfc.wide.ad.jp/~asaeda/</uri>
</address>
</author>
<date day="10" month="May" year="2010" />
<area>Transport</area>
<workgroup>RMT</workgroup>
<keyword>security analysis</keyword>
<abstract>
<t>This document describes general security considerations for the
Reliable Multicast Transport (RMT) Working Group set of building blocks
and protocols. An emphasis is placed on risks that might be resolved in
the scope of transport protocol design. However, relevant security
issues related to IP Multicast control-plane and other concerns not
strictly within the scope of reliable transport protocol design are also
discussed. The document also begins an exploration of approaches that
could be embraced to mitigate these risks. The purpose of this document
is to provide a consolidated security discussion and provide a basis for
further discussions and potential resolution of any significant security
issues that may exist in the current set of RMT standards.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Reliable Multicast Transport (RMT) Working Group has produced a
set of building block (BB) and protocol instantiation (PI)
specifications for reliable multicast data transport. Some present PIs
defined within the scope of RMT include <xref
target="RFC5775">Asynchronous Layered Coding (ALC)</xref>, <xref
target="RFC5740">NACK-Oriented Reliable Multicast (NORM)</xref>, and the
<xref target="I-D.ietf-rmt-flute-revised">File Delivery over
Unidirectional Transport (FLUTE)</xref> application that is built on top
of ALC. These can be considered "Content Delivery Protocols" (CDP) as
described in <xref target="Neumann05"></xref>. In this document, the
term CDP will refer indifferently to either ALC or NORM, with their
associated BBs.</t>
<t>The use of these BBs and PIs raises some new security risks. For
instance, these protocols share a novel set of Forward Error Correction
(FEC) and congestion control building blocks that present some new
capabilities for Internet transport, but may also pose some new security
risks. Yet some security risks are not related to the particular BBs
used by the PIs, but are more general. Reliable multicast transport
sessions are expected to involve at least one sender and multiple
receivers. Thus, the risk of and avenues to attack are implicitly
greater than that of point-to-point (unicast) transport sessions. Also
the nature of IP multicast can expose other coexistent network flows and
services to risk if malicious users exploit it. The classic <xref
target="RFC1112">Any-Source Multicast (ASM)</xref> model of multicast
routing allows any host to join an IP multicast group and send traffic
to that group. This poses many potential security challenges. And, while
the emerging <xref target="RFC3569">Source-Specific Multicast
(SSM)</xref>, <xref target="RFC4607"></xref> model that enables users to
receive multicast data sent only from specified sender(s) simplifies
some challenges, there are still specific issues. For instance, possible
areas of attack include those against the control plane where malicious
hosts join IP multicast groups to cause multicast traffic to be directed
to parts of the network where it is not needed or desired. This may
indirectly cause denial-of-service (DoS) to other network flows. Also,
attackers may transmit erroneous or corrupt messages to the group or
employ strategies such as replay attack within the "data plane" of
protocol operation.</t>
<t>The goals of this document are therefore to: <list style="numbers">
<t>Define the possible general security goals: protecting the
network infrastructure, and/or the protocol, and/or the content,
and/or the user (e.g., its privacy);</t>
<t>List the possible elementary security services that will make it
possible to fulfill the general security goals. Some of these
services are generic (e.g., object and/or packet integrity), while
others are specific to RMT protocols (e.g., congestion control
specific security schemes);</t>
<t>List some technological building blocks and solutions that can
provide the desired security services;</t>
<t>Highlight the CDP and the use-case specificities that will impact
security. Indeed, the set of solutions proposed to fulfill the
security goals will greatly be impacted by these considerations;</t>
</list> In some cases, the existing RMT documents already discuss the
risks and outline approaches to solve them, at least partially. The
purpose of this document is to consolidate this content and provide a
basis for further discussion and potential resolution of any significant
security issues that may exist.</t>
<section title="Conventions Used in this Document">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
</section>
<section title="Quick Introduction to RMT Protocols and their Use">
<section title="The Two Families of CDP">
<t>The ALC and NORM classes of CDP are designed to reliably deliver
content to a group of multicast receivers. However, ALC and NORM have
a different set of features and limitations. ALC supports a
unidirectional delivery model where there is no feedback from the
receivers to senders. Reliability is achieved by the joint use of
carousel-based transmission techniques associated to FEC encoding to
recover from missing (erased) packets.</t>
<!--
The transmission stream can
deliver data at different rates to different receivers, thus offering
the potential for multirate congestion control. This allows
scalability for delivery of bulk content to potentially very large
group sizes.
-->
<t>On the opposite, NORM achieves reliability by means of FEC encoding
(as with ALC) and feedback from the receivers. More specifically, NORM
leverages Negative Acknowledgement techniques to control the senders'
transmission of content. The advantage is that the sender need not
transmit any more information than necessary to satisfy the receivers'
need for fully reliable transfers. However, while NORM specifies
feedback control techniques to allow it to scale to large group sizes,
it is not as massively scalable as ALC. Additionally, the NORM
feedback control mechanisms add some header content and protocol
implementation complexity.</t>
<t>The appropriate choice of a CDP depends upon application needs,
deployment constraints, and network connectivity considerations. And
while there are many common security considerations for these two
classes of CDP, there are also some unique considerations for
each.</t>
</section>
<section anchor="protocolCharacteristics"
title="RMT Protocol Characteristics">
<t>This section focuses on the RMT protocol characteristics that
impact the choice of the technological building blocks, and the way
they can be applied. Both ALC and NORM have been designed with
receiver group size scalability. While ALC targets massively scalable
sessions (e.g., millions of receivers), NORM is less ambitious,
essentially because of the use of feedback messages.<!--Ideally, the use of security mechanisms should not break these scalability features.--></t>
<t>The ALC and NORM protocols also differ in the communication paths:
<list style="symbols">
<t>sender to receivers: ALC and NORM, for bulk data transfer and
signaling messages;</t>
<t>receivers to sender: NORM only, for feedback messages;</t>
<t>receivers to receivers: NORM only for control messages;</t>
</list> Note that the fact ALC is capable of working on top of
purely unidirectional networks does not mean that no back-channel is
available (<xref target="useCaseCharacteristics"></xref>).</t>
<t>The NORM and ALC protocols support a variety of content delivery
models where transport may be carefully coordinated among the sender
and receivers or with looser coordination and interaction. This leads
to a number of different use cases for these protocols.</t>
</section>
<section anchor="useCaseCharacteristics"
title="Target Use Case Characteristics">
<t>This section focuses on the target use cases and their special
characteristics. These details will impact both the choice of the
technological building blocks and the way they can be applied. One can
distinguish the following use case features: <list style="symbols">
<t>Purely unidirectional transport versus symmetric bidirectional
transport versus asymmetric bidirectional transport. Most of the
time, the amount of traffic flowing to the source is limited, and
one can overlook whether the transport channel is symmetric or
not. The nature of the underlying transport channel is of
paramount importance, since many security building blocks will
require a bidirectional communication;</t>
<t>Massively scalable versus moderately scalable session. Here we
do not define precisely what the terms "massively scalable" and
"moderately scalable" mean.</t>
<t>Known set of receivers versus unknown set of receivers: I.e.,
does the source know at any point of time the set of receivers or
not? Of course, knowing the set of receivers is usually not
compatible with massively scalable sessions;</t>
<t>Dynamic set of receivers versus fixed set of receivers: I.e.,
does the source know at some point of time the maximum set of
receivers or will it evolve dynamically?</t>
<t>High rate data flow versus small rate data flow: Some security
building blocks are CPU-intensive and are therefore incompatible
with high data rate sessions (e.g., solutions that digitally sign
all packets sent).</t>
<t>Protocol stack available at both ends: A solution that requires
some unusual features within the protocol stack will not always be
usable. Some target environments (e.g., embedded systems) provide
a minimum set of features and extending them (e.g., to add IPsec)
is not necessarily realistic;</t>
<t>Multicast routing and other layer-3 protocols in use: E.g., SSM
routing is often seen as one of the key service to improve the
security within multicast sessions, and some security building
blocks require specialized versions of layer-3 protocols (e.g.,
IGMP/MLD with security extensions). In some cases these
assumptions might not be realistic.</t>
</list>Depending on the target goal and the associated security
building block used, other features might be of importance. For
instance TESLA requires a loose time synchronization between the
source and the receivers. Several possible techniques are available to
provide this, but some of them may be feasible only if the target use
case has the appropriate characteristics.</t>
</section>
</section>
<section title="Some Security Threats">
<t>The IP architecture provides common access to notional control and
data planes to both end and intermediate systems. For the purposes of
discussion here, the "control plane" mechanisms are considered those
with message exchanges between end systems (typically computers) and
intermediate systems (typically routers) (or among intermediate systems)
while the "data plane" encompasses messages exchanged among end systems,
usually pertaining to the transfer of application data. The security
threats described here are introduced within the taxonomy of control
plane and data plane IP mechanisms.</t>
<section title="Control-Plane Attacks">
<t>In this discussion, "control-plane" in the context of Internet
Protocol systems refers to signaling among end systems and
intermediate systems to facilitate routing and forwarding of packets.
For IP multicast, this notably includes Internet Group Management
Protocol (IGMP), Multicast Listener Discovery protocol (MLD), and
multicast routing protocol messaging. While control-plane attacks may
be considered outside of the scope of the transport protocol
specifications discussed here, it is important to understand the
potential impact of such attacks with respect to the deployment and
operation of these protocols. For example, awareness of possible IP
Multicast control-plane manipulation that can lead to unauthorized (or
unexpected) monitoring of data plane traffic by malicious users may
lead a transport application or protocol implementation to support
encryption to ensure data confidentiality and/or privacy. Also, these
types of attack also have bearing on assessing the real risks of
potentially more complex attacks against the transport mechanisms
themselves. In some cases, the solutions to these control-plane risk
areas may reduce the impact or possibility of some data-plane attacks
that are discussed in this document.</t>
<t>The presence of these types of attack may necessitate that
policy-based controls be embedded in routers to limit the distribution
(including transmission and reception) of multicast traffic (on a
group-wise and/or traffic volume basis) to different parts of the
network. Such policy-based controls are beyond the scope of the RMT
protocol specifications. However, such network protection mechanisms
may reduce the opportunities for or effectiveness of some of the
data-plane attacks discussed later. For example, reverse-path checks
can significantly limit opportunities for attackers to conduct replay
attacks when hosts actually do use IPsec. Also, future IP Multicast
control protocols may wish to consider providing security mechanism to
prevent unauthorized monitoring or manipulation of messages related to
group membership, routing, and activity. The sections below describe
some variants of control-plane attacks.</t>
<section title="Control Plane Monitoring">
<t>While this may not be a direct attack on the transport system, it
may be possible for an attacker to gain useful information in
advancing attack goals by monitoring IP Multicast control plane
traffic including group membership and multicast routing
information. Identification of hosts and/or routers participating in
specific multicast groups may readily identify systems vulnerable to
protocol-specific exploitation. And, with regards to user privacy
concerns, such "side information" may be relevant to this emerging
aspect of network security as described in <xref
target="sec.privacy"></xref>.</t>
<!-- [HA] Pointed a privacy section -->
</section>
<section anchor="sec.unauthorized_group_membership"
title="Unauthorized (or Malicious) Group Membership">
<t>One of the simplest attacks is that where a malicious host joins
an IP multicast group so that potentially unwanted traffic is routed
to the host's network interface. This type of attack can turn a
legitimate source of IP traffic into a "attacker" without requiring
any access privileges to the source host or routers involved. This
type of attack can be used for denial-of-service purposes or for the
real attacker (the malicious joiner) to gain access to the
information content being sent. Similarly, some routing protocols
may permit any sender (whether joined to the specific group or not)
to transmit messages to a multicast group.</t>
<t>It is possible that malicious hosts could also spoof IGMP/MLD
messages, joining groups posing as legitimate hosts (or spoof source
traffic from legitimate hosts). This may be done at intermediate
locations in the network or by hosts co-resident with the authorized
hosts on local area networks. Such spoofing could be done by raw
packet generation or with replay of previously-recorded control
messages.</t>
<t>For the sake of completeness, it should be noted that multicast
routing protocol control messaging may be subject to similar threats
if sufficient protocol security mechanisms are not enabled in the
routing infrastructure. <xref target="RFC4609"></xref> describes
security threats to the PIM-SM multicast routing
infrastructures.</t>
<!-- [HA] Added text and pointed mroutesec RFC -->
</section>
</section>
<section title="Data-Plane Attacks">
<t>This section discusses some types of active attacks that might be
conducted "in-band" with respect to the reliable multicast transport
protocol operating within the data plane of network data transfer.
I.e., the "data-plane" here refers to IP packets containing end-to-end
transport content to support the reliable multicast transfer. The
passive attack of unauthorized data-plan monitoring is discussed above
since such activity might be made possible by the vulnerabilities of
the IP Multicast control plane. To cover the two classes of RMT
protocols, the active data-plane attacks are categorized as 1) those
where the attacker generates messages posing as a data sender, and 2)
those where the attacker generates messages posing as a receiver
providing feedback to the sender(s) or group. Additionally, a common
threat to protocol operation is that of brute-force, rogue packet
generation. This is discussed briefly below, but the more subtle
attacks that might be conducted are given more attention as those fall
within the scope of the RMT transport protocol design. Additionally,
special consideration is given to that of the "replay attack" [see
<xref target="ReplayAttacks"></xref>], as it can be applied across
these different categories.</t>
<section title="Rogue Traffic Generation">
<t>If an attacker is able to successfully inject packets into the
multicast distribution tree, one obvious denial-of-service attack is
for the attacker to generate a large volume of apparently
authenticate traffic (and if authentication mechanisms are used, a
"replay" attack strategy might be used). The impact of this type of
attack can be significant since the potential for routers to relay
the traffic to multiple portions of a networks (as compared to a
single unicast routing path). However, other than the amplified
negative impact to the network, this type of attack is no different
than what is possible with rogue unicast packet generation and
similar measures used to protect the network from such attacks could
be used to contain this type of brute-force attack. Of course, the
pragmatic question of whether current implementations of such
protection mechanisms support IP Multicast SHOULD be considered.</t>
</section>
<section title="Sender Message Spoofing">
<t>Sender message spoofing attacks are applicable to both CDP: ALC
(sender-only transmission) and NORM (sender-receiver exchanges).
Without an authentication mechanism, an attacker can easily generate
sender messages that could disrupt a reliable multicast transfer
session. And with FEC-based transport mechanisms, a single packet
with an apparently-correct FEC payload identifier<xref
target="RFC5052"></xref> but a corrupted FEC payload could
potentially render an entire block of transported data invalid.
Thus, a modest injection rate of corrupt traffic could cause severe
impairment of data transport. Additionally, such invalid sender
packets could convey out-of-bound indices (e.g., bad symbol or block
identifiers) that can lead to buffer overflow exploits or similar
issues in implementations that insufficiently check for invalid
data.</t>
<t>An indirect use of sender message spoofing would be to generate
messages that would cause receivers to take inappropriate
congestion-control action. In the case of the layered congestion
control mechanisms proposed for ALC use, this could lead to the
receivers erroneously leaving groups associated with higher
bandwidth transport layers and suffering unnecessarily low transport
rates. Similarly, receivers may be misled to join inappropriate
groups directing unwanted traffic to their part of the network.
Attacks with similar effect could be conducted against the <xref
target="RFC4654">TCP-Friendly Multicast Congestion Control
(TFMCC)</xref> approach proposed for NORM operation with spoofing of
sender messages carrying congestion control state to receivers.</t>
</section>
<section title="Receiver Message Spoofing">
<t>These attacks are limited to CDP that use feedback from receivers
in the group to influence sender and other receiver operation. In
the NORM protocol, this includes negative-acknowledgement (NACK)
messages fed back to the sender to achieve reliable transfer,
congestion control feedback content, and the optional positive
acknowledgement features of the specification. It is also important
to note that for ASM operation, NORM receivers pay attention to the
messages of other receivers for the purpose of suppression to avoid
feedback implosion as group size grows large.</t>
<t>An attacker that can generate false feedback can manipulate the
NORM sender to unnecessarily transmit repair information and reduce
the goodput of the reliable transfer regardless of the sender's
transmit rate. Contrived congestion control feedback could also
cause the sender to transmit at an unfairly low rate.</t>
<t>As mentioned, spoofed receiver messaging may not be directed only
at senders, but also at receivers participating in the session. For
example, an attacker may direct phony receiver feedback messages to
selected receivers in the group causing those receivers to suppress
feedback that might have otherwise been transmitted. This attack
could compromise the ability of those receivers to achieve reliable
transfer. Also, suppressed congestion control feedback could cause
the sender to transmit at a rate unfair to those attacked receivers
if their fair congestion control rate were lower.</t>
</section>
<section anchor="ReplayAttacks" title="Replay Attacks">
<t>The infamous "replay attack" (injection of a previously
transmitted packet to one or more participants) is given special
attention here because of the special consequences it can have on
RMT protocol operation. Without specific protection mechanisms
against replay (e.g., duplicate message detection), it is possible
for these attacks to be successful even when security mechanisms
such as packet authentication and/or encryption are employed.</t>
<section title="Replay of Sender Messages">
<t>Generally, replay of recent protocol messages from the sender
will not harm transport, and could potentially assist it, unless
it is of sufficient volume to result in the same type of impact as
the "rogue traffic generation" described above. However, it is
possible that replay of sufficiently old messages may cause
receivers to think they are "out of sync" with the sender and
reset state, compromising the transfer. Also, if sender transport
data identifiers are reused (object identifiers, FEC payload
identifiers, etc), it is possible that replay of old messages
could corrupt data of a current transfer.</t>
</section>
<section title="Replay of Receiver Messages">
<t>Replay of receiver messages are problematic for the NORM
protocol, because replay of NACK messages could cause the sender
to unnecessarily transmit repair information for an FEC coding
block. Similarly, the sender transmission rate might be
manipulated by replay of congestion control feedback messages from
receivers in the group. And the way that NORM senders estimate
group round-trip timing (GRTT) could allow a replay attack to
manipulate the senders' GRTT estimate to an unnecessarily large
value, adding latency to the reliable transport process.</t>
</section>
</section>
</section>
</section>
<section anchor="generalGoals" title="General Security Goals">
<t>The term "security" is extremely vast and encompasses many different
meanings. The goal of this section is to clarify what "security" means
when considering the CDP defined in the IETF RMT working group. However,
the scope can also encompass additional applications, like streaming
applications. This section only focuses on the desired general goals.
The following sections will then discuss the possible elementary
services that will be required to fulfill these general goals, as well
as the underlying technological building blocks.</t>
<t>The possible final goals include, in decreasing order of importance:
<list style="symbols">
<t>network protection: the goal is to protect the network from
attacks, no matter whether these attacks are voluntary (i.e.,
launched by one or several attackers) or non voluntary (i.e., caused
by a misbehaving system, where "system" can designate a building
block, a protocol, an application, or a user);</t>
<t>protocol protection: the goal is to protect the RMT protocol
itself, e.g., to avoid that a misbehaving receiver prevents other
receivers to get the content, no matter whether this is done
intentionally or not;</t>
<t>content protection: to goal is to protect the content itself, for
instance to guaranty the integrity of the content, or to make sure
that only authorized clients can access the content;</t>
<t>and user protection: the goal is often to protect the user
privacy.</t>
</list></t>
<section title="Network Protection">
<t>Protecting the network is of course of primary importance. An
attacker should not be able to damage the whole infrastructure by
exploiting some features of the RMT protocol. Unfortunately, recent
past has shown that the multicast routing infrastructure is relatively
fragile, as well as the applications built on top of it. Since the RMT
protocols may use congestion control mechanisms to regulate sender
transmission rate, the protocol security features should ensure that
the sender may not be manipulated to transmit at incorrect rates (most
importantly not at an excessive rate) to any parts of the receiver
group. In the case of NORM, the security mechanisms should ensure that
the feedback suppression mechanisms are protected to prevent
badly-behaving network nodes from purposefully causing feedback
implosion. In the case of ALC, where layered congestion control may be
used via dynamic grou/layer membership, this extends to considerations
of excessive manipulation of the multicast router control plane.</t>
</section>
<section title="Protocol Protection">
<t>Protecting the protocols is also of importance, since the higher
the number of clients, the more serious the consequences of an attack.
This is all the more true as scalability is often one of the desired
goals of CDP. Ideally, receivers should be sufficiently isolated from
one another, so that a single misbehaving receiver does not affect
others. Similarly, an external attacker should not be able to break
the system, i.e., resulting in unreliable operation or delivery of
incorrect content.</t>
</section>
<section title="Content Protection">
<t>The content itself should be protected when meaningful. This level
of security is often the concern of the content provider (and its
responsibility). For instance, in case of confidential (or non-free)
content, the typical solution consists in encrypting the content. It
can be done within the upper application, i.e., above the RMT
protocol, or within the transport system.</t>
<t>But other requirements may exist, like verifying the integrity of a
received object, or authenticating the sender of the received packets.
To that goal, one can rely on the use of building blocks integrated
within, or above, or beneath the RMT protocol.</t>
<t>One may also consider that offering the packet sender
authentication and content integrity services are basic requirements
that should fulfill any RMT system that operates within an open
network, where any attacker can easily inject spurious traffic in an
ongoing NORM or ALC session. In that case this goal is not the
responsibility of the content provider but the responsibility of the
administrator who deploys the RMT system itself.</t>
</section>
<section anchor="sec.privacy" title="Privacy">
<t>Finally the user should be protected, and more specifically its
privacy. In general, there is no privacy issue for data sender: the
data sender's address is announced to all prospective receivers prior
to their joins. Moreover receivers need to specify the source
address(es) as well as the IP multicast address in SSM communication
upon their subscription. The situation is different if we consider
receivers since their address should not be disclosed publicly.</t>
<t>Data receivers use IGMP or MLD protocols to notify their upstream
routers to join or leave IP multicast session. The recent IGMPv3 <xref
target="RFC3376"></xref> and MLDv2 <xref target="RFC3810"></xref> do
not adopt the "report suppression mechanism". Report suppression makes
the receiver host withdraw its own report when the host hears a report
scheduled to be sent from other host joining the same group.
Eliminating the report suppression mechanism does not contribute to
minimizing the number of responses, but enables the router to keep
track of host membership status on a link. Due to this specification,
operators who maintain upstream routers that attach multicast data
receiver can recognize data receivers' addresses by tracing IGMP/MLD
report messages. Although such traced data may be useful for capacity
planning or accounting from operator's perspective, the detail
information including receivers' IP addresses should be carefully
treated.</t>
<t>As described in <xref
target="sec.unauthorized_group_membership"></xref>, unauthorized users
may spoof IGMP/MLD query messages and trace receivers' addresses on
the same LAN. Currently, IGMP/MLD protocols do not protect this
attack. It is desired for these protocols to ignore invalid query
messages and provide receiver's privacy by some means.</t>
</section>
</section>
<section title="Elementary Security Techniques">
<t>The goals defined in <xref target="generalGoals"></xref> will be
fulfilled by means of underlying security techniques, provided by one or
several technological building blocks. This section only focuses on
these elementary security techniques. Some general techniques
traditionally available are:</t>
<texttable title="General Security Techniques">
<ttcol width="20%">Technique</ttcol>
<ttcol>Goal</ttcol>
<c>packet integrity</c>
<c>Enable session participants to verify that a packet has not been
inappropriately modified in transit.</c>
<c>packet source authentication</c>
<c>Enable a receiver to verify the source of a packet.</c>
<c>packet group authentication</c>
<c>Enable a receiver to verify that a packet originated or was
modified only within the group and has not been modified by nonmembers
in transit; Additionally, if attribution of any modifications by the
group is required, certain group authentication mechanisms may provide
this capability.</c>
<c>packet non-repudiation</c>
<c>Enable any third party to verify the source of a packet such that
the source cannot repudiate having sent the packet.</c>
<c>packet anti-replay</c>
<c>Enable a receiver to detect that a packet is the same as a
previously-received packet</c>
<c>object integrity</c>
<c>Enable a receiver to verify the integrity of a whole object. Such
object integrity verification should be possible for any singular
object or any composition of sub-objects which together constitute a
larger object structure.</c>
<c>object source authentication</c>
<c>Enable a receiver to verify the source of an object.</c>
<c>object confidentiality</c>
<c>Enable a source to guarantee that only authorized receivers can
access the object data.</c>
</texttable>
<t>Some additional techniques are specific to the RMT protocols:</t>
<texttable title="RMT-Specific Security Techniques">
<ttcol width="20%">Technique</ttcol>
<ttcol>Goal</ttcol>
<c>congestion control security</c>
<c>Prevent an attacker from modifying the congestion control protocol
normal behavior (e.g., by reducing the transmission (NORM) or
reception (ALC) rate, or on the opposite increasing this rate up to a
point where congestion occurs)</c>
<c>group management</c>
<c>Ensure that only authorized receivers (as defined by a certain
group management policy) join the RMT session and possibly inform the
source</c>
<c>backward group secrecy</c>
<c>Prevent a new group member to access the information in clear sent
to the group before he joined the group</c>
<c>forward group secrecy</c>
<c>Prevent a former group member to access the information in clear
sent to the group after he left the group</c>
</texttable>
<t>These techniques are usually achieved by means of one or several
technological building blocks. The target use case where the RMT system
will be deployed will greatly impact the choice of the technological
building block(s) used to provide these services, as explained in <xref
target="useCaseCharacteristics"></xref>.</t>
</section>
<section title="Technological Building Blocks">
<t>Here is a list of techniques and building blocks that are likely to
fulfill one or several of the goals listed above: <list style="symbols">
<t>IPsec;</t>
<t>Group MAC;</t>
<t>Digital signatures;</t>
<t>TESLA;</t>
<t>SSM communication model;</t>
<!-- [HA] wording -->
</list> Each of them is now quickly discussed. In particular we
identify what service it can offer, its limitations, and its field of
application (adequacy with respect to the CDP and the target use
case).</t>
<section title="IPsec">
<section title="Benefits">
<t>One direct approach using existing standards is to apply IPsec
<xref target="RFC4301"></xref> to achieve the following properties:
<list style="symbols">
<t>source authentication and packet integrity (IPsec AH or
ESP)</t>
<t>confidentiality by means of encryption (IPsec ESP)</t>
</list></t>
</section>
<section title="Requirements">
<t>It is expected that the approach to apply IPsec for reliable
multicast transport sessions is similar to that described for OSPFv3
security<xref target="RFC4552"></xref>. The following list proposes
the IPsec capabilities needed to support a similar approach to RMT
protocol security: <list style="symbols">
<t>Mode - Transport mode IPsec security is required;</t>
<t>Selectors - source and destination addresses and ports,
protocol.</t>
<t>For some uses, preplaced, manual key support may be required
to support application deployment and operation. For automated
key management for group communication the Group Secure
Association Key Management Protocol (GSAKMP) described in <xref
target="RFC4535"></xref> may be used to emplace the keys for
IPsec operation.</t>
</list> Note that a periodic rekeying procedure similar to that
described in RFC 4552 can also be applied with the additional
benefit that the reliable transport aspects of the CDP provide
robustness to any message loss that might occur due to ANY timing
discrepancies among the participants in the reliable multicast
session.</t>
</section>
<section title="Limitations">
<t>It should be noted that current IPsec implementations may not
provide the capability for anti-replay protection for multicast
operation. In the case of the NORM protocol, a sequence number is
provided for packet loss measurement to support congestion control
operation. This sequence number can also be used within a NORM
implementation for detecting duplicate (replayed) messages from
sources (senders or receivers) within the transport session group.
In this way, protection against replay attack can be achieved in
conjunction with the authentication and possibly confidentiality
properties provided by an IPsec encapsulation of NORM messages. NORM
receivers generate a very low volume of feedback traffic and it is
expected that the 16-bit sequence space provided by NORM will be
sufficient for replay attack protection. When a NORM session is
long-lived, the limits of the sender repair window are expected to
provide protection from replayed NACKs as they would typically be
outside of the sender's current repair window. It is suggested that
IPsec implementations that can provide anti-replay protection for IP
Multicast traffic, even when there are multiple senders within a
group, be adopted. The GSAKMP document has some discussion in this
area.</t>
</section>
</section>
<section title="Group MAC">
<section title="Benefits">
<t>The use of Group MAC (Message Authentication Codes) within the
CDP <xref target="SimpleAuth"></xref> is a simple solution to
provide a loss tolerant group authentication/integrity service for
all the packets exchanged within a session (i.e., the packets
generated by the session's sender and the session's receivers). This
scheme is easy to deploy since it only requires that all the group
members share a common secret key. Because Group MAC heavily relies
on fast symmetric cryptographic building blocks, CPU processing
remains limited both at the sender and receiver sides, which makes
it suitable for high data rate transmissions, and/or lightweight
terminals. Finally, the transmission overhead remains limited.</t>
</section>
<section title="Requirements">
<t>This scheme only requires that all the group members share a
common secret key, possibly associated to a re-keying mechanism
(e.g., each time the group membership changes, or on a periodic
basis).</t>
</section>
<section title="Limitations">
<t>This scheme cannot protect against attacks coming from inside the
group, where a group member impersonates the sender and sends forged
messages to other receivers. It only provides a group-level
authentication/integrity service, unlike the TESLA and Digital
Signature schemes. Note that the Group MAC and Digital Signature
schemes can be advantageously used together, as explained in <xref
target="SimpleAuth"></xref>.</t>
</section>
</section>
<section title="Digital Signatures">
<section title="Benefits">
<t>The use of Digital Signatures within the CDP <xref
target="SimpleAuth"></xref> is a simple solution to provide a
loss-tolerant authentication/integrity service for all the packets
exchanged within a session (i.e., the packets generated by the
session's sender and the session's receivers). This scheme is easy
to deploy since it only requires that the participants know the
packet sender's public key, which can be achieved with either Public
Key Infrastructure (PKI) or by preplacement of these keys.</t>
</section>
<section title="Requirements">
<t>This scheme is easy to deploy since it requires only that the
participants know the packet sender's public key, which can be
achieved with either PKI or by preplacement of these keys.</t>
</section>
<section title="Limitations">
<t>When RSA <xref target="RsaPaper"></xref> asymmetric cryptography
is used, the digital signatures approach has two major shortcomings:
<list style="symbols">
<t>it is limited by high computational costs, especially at the
sender, and</t>
<t>it is limited by high transmission overheads.</t>
</list>This scheme is well suited to low data rate flows, when
transmission overheads are not a major issue. For instance it can be
used as a complement to TESLA for the feedback traffic coming from
the session's receivers. The use of ECC ("Elliptic Curve
Cryptography") significantly relaxes these constraints, especially
when seeking for higher security levels. For instance, the following
key size provide equivalent security:</t>
<texttable>
<ttcol align="center">Symmetric Key Size</ttcol>
<ttcol align="center">RSA Key Size</ttcol>
<ttcol align="center">ECC Key Size</ttcol>
<c>80 bits</c>
<c>1024 bits</c>
<c>160 bits</c>
<c>112 bits</c>
<c>2048 bits</c>
<c>224 bits</c>
</texttable>
<t>However in some cases, the Intellectual Property Rights (IPR)
considerations for ECC may limit its use, so the other techniques
are presented here as well. Note that the Group MAC and Digital
Signature schemes can be advantageously used together, as explained
in <xref target="SimpleAuth"></xref>.</t>
</section>
</section>
<section title="TESLA">
<section title="Benefits">
<t>The use of <xref target="RFC5776">TESLA</xref> within the CDP
offers a loss tolerant, lightweight, authentication/integrity
service for the packets generated by the session's sender. Depending
on the time synchronization and bootstrap methods used, TESLA can be
compatible with massively scalable sessions. Because TESLA heavily
relies on fast symmetric cryptographic building blocks, CPU
processing remains limited both at the sender and receiver sides,
which makes it suitable for high data rate transmissions, and/or
lightweight terminals. Finally, the transmission overhead remains
limited.</t>
</section>
<section title="Requirements">
<t>The security offered by TESLA relies heavily on time. Therefore
the session's sender and each receiver need to be loosely
synchronized in a secure way. To that purpose, several methods
exist, depending on the use case: direct time synchronization (which
requires a bidirectional transport channel), using a secure <xref
target="RFC1305">Network Time Protocol (NTP)</xref> infrastructure
(which also requires a bidirectional transport channel), or a Global
Positioning System (GPS) device, or a clock with a time-drift that
is negligible in front of the TESLA time accuracy requirements.</t>
<t>The various bootstrap parameters must also be communicated to the
receivers, using either an in-band or out-of-band mechanism,
sometimes requiring bidirectional communications. So, depending on
the time synchronization scheme and the bootstrap mechanism method,
TESLA can be used with either bidirectional or unidirectional
transport channels.</t>
</section>
<section title="Limitations">
<t>One limitation is that TESLA does not protect the packets that
are generated by receivers, for instance the feedback packets of
NORM. These packets must be protected by other means.</t>
<t>Another limitation is that TESLA requires some buffering
capabilities at the receivers in order to enable the delayed
authentication feature. This is not considered though as a major
issue in the general case (e.g., FEC decoding of objects within an
ALC session already requires some buffering capabilities, that often
exceed that of TESLA), but it might be one in case of embedded
environments.</t>
</section>
</section>
<section title="Source-Specific Multicast">
<!-- [HA] Changed -->
<t><xref target="RFC3569">Source-Specific Multicast (SSM)</xref>,
<xref target="RFC4607"></xref> amends the classical Any-Source
Multicast (ASM) model by creating logical IP multicast "channels" that
are defined by the multicast destination address <spanx style="emph">and</spanx>
the specific source address(es). Thus for a given "channel", only the
specific source(s) can inject packets that are distributed to the
receivers. This form of multicast has group management benefits since
a source can independently control the "channels" it creates.</t>
<section title="Requirements">
<t>Use of SSM requires that the network intermediate systems
explicitly support it. Additionally, hosts operating systems are
required to support the IGMPv3/MLDv2 extensions for SSM, and the CDP
implementations need to support the IGMPv3/MLDv2 API, including
management of the <srcAddr; dstMcastAddr> "channel"
identifiers.</t>
</section>
<section title="Limitations">
<t>CDP such as NORM that use signaling from receivers to multicast
senders will need to use unicast addressing for feedback messages.
In the case of NORM, its timer-based feedback suppression requires
support of the sender NORM_CMD(REPAIR_ADV) message to control
receiver feedback. In some topologies, use of unicast feedback may
require some additional latency (increased backoff factor) for safe
operation. The security of the unicast feedback from the receivers
to sender will need to be addressed separately since the IP
multicast model, including SSM, does not provide the sender
knowledge of authorized group members.</t>
</section>
<!-- [HA] Modified with source-based and receiver-based attacks, and merged "Benefits" section -->
<section title="Source-Based and Receiver-Based Attacks">
<t>The security threats are categorized into "source-based" and
"receiver-based" attacks <xref target="RFC4609"></xref>. In short,
the former is a DoS attack against the multicast networks, in which
data is sent to numerous and random group addresses, and the latter
is a DoS attack against multicast routers, in which innumerable
IGMP/MLD joins are sent from a client.</t>
<t>Regarding source-based attack, there are some security benefits
in SSM. Since data-plane traffic for an SSM "channel" is limited to
that of a single, specific source address, it is possible that
network intermediate systems may impose mechanism that prevent
injection of traffic to the group from inappropriate (perhaps
malicious) nodes. This can reduce the risk for denial-of-service and
some of the other attacks described in this document. While SSM
alone is not a complete security solution, it can simplify secure
RMT operation.</t>
<t>On the contrary, SSM is not robust against receiver-based attack.
An SSM capable router constructs a Shortest-Path Tree (SPT) with no
shared tree coordination. Therefore, even if a host triggers invalid
or unavailable channel subscriptions, the upstream router starts
establishing all SPTs with no intellectual decision. What is worse
is that these multicast routers cannot recognize the original router
that is attacked and cannot stop the attack itself.</t>
</section>
</section>
<section title="Summary">
<t>The following table summarizes the pros/cons of each
authentication/integrity scheme used at application/transport level
(where "-" means bad, "0" means neutral, and "+" means good):</t>
<texttable>
<ttcol align="left"></ttcol>
<ttcol align="center">RSA Digital Signature</ttcol>
<ttcol align="center">ECC Digital Signature</ttcol>
<ttcol align="center">Group MAC</ttcol>
<ttcol align="center">TESLA</ttcol>
<c>True authentication and integrity</c>
<c>Yes</c>
<c>Yes</c>
<c>No (group security)</c>
<c>Yes</c>
<c>Immediate authentication</c>
<c>Yes</c>
<c>Yes</c>
<c>Yes</c>
<c>No</c>
<c>Processing load</c>
<c>-</c>
<c>0</c>
<c>+</c>
<c>+</c>
<c>Transmission overhead</c>
<c>-</c>
<c>0</c>
<c>+</c>
<c>+</c>
<c>Complexity</c>
<c>+</c>
<c>+</c>
<c>+</c>
<c>-</c>
</texttable>
<!--
<t>The following table summarizes the pros/cons of each
authentication/integrity scheme used at application/transport
level:</t>
<texttable>
<ttcol align="left"></ttcol>
<ttcol align="center">RSA Digital Signature</ttcol>
<ttcol align="center">ECC Digital Signature</ttcol>
<ttcol align="center">Group MAC</ttcol>
<ttcol align="center">TESLA</ttcol>
<c>True auth and integrity</c>
<c>Yes</c>
<c>Yes</c>
<c>No (group security)</c>
<c>Yes</c>
<c>Immediate auth</c>
<c>Yes</c>
<c>Yes</c>
<c>Yes</c>
<c>No</c>
<c>Processing load</c>
<c>- -</c>
<c>+</c>
<c>++</c>
<c>+</c>
<c>Transmission overhead</c>
<c>- -</c>
<c>+</c>
<c>++</c>
<c>+</c>
<c>Complexity</c>
<c>++</c>
<c>++</c>
<c>++</c>
<c>- -</c>
</texttable>
-->
</section>
</section>
<section title="Security Infrastructure">
<t>Deploying the elementary technological building blocks often requires
that a security infrastructure exists. Such security infrastructure can
provide: <list style="symbols">
<t>Public Key Infrastructure (PKI) for trusted third party vetting
of, and vouching for, user identities. PKI also allows the binding
of public keys to users, usually by means of certificates.</t>
<t>Group Key Management with rekeying schemes that are either
periodic or triggered by some higher level event. It is required in
particular when the group is dynamic and forward/backward secrecy
are important. This is also required to improve the scalability of
the CDP (since key management is done automatically, using a key
server topology), or the security provided by the CDP (since the
underlying cryptographic keys will be changed frequently)</t>
</list></t>
<t>It is expected that some CDP deployments may use existing
client-server security infrastructure models so that receivers may
acquire any necessary security material and be authenticated or
validated as needed for group participation. Then, the reliable delivery
of session data content will be provided via the applicable RMT
protocols. Note that in this case the security infrastructure itself may
limit the scalability of the group size or other aspects of reliable
multicast transfer. The IETF Multicast Security (MSEC) Working Group has
developed some protocols that can be applied to achieve more scalable
and effective group communication security infrastructure<xref
target="RFC4046"></xref>. It is encouraged that these mechanisms be
considered in the development of security for CDP.</t>
</section>
<section title="New Threats Introduced by the Security Scheme Itself">
<t>Introducing a security scheme, as a side effect, can sometimes
introduce new security threats. For instance, signing all packets with
asymmetric cryptographic schemes (to provide a source
authentication/content integrity/anti-replay service) opens the door to
DoS attacks. Indeed, verifying asymmetric-based cryptographic signatures
is a CPU intensive task. Therefore an attacker can easily overload a
receiver (or a sender in case of NORM) by injecting a significant number
of faked packets.</t>
</section>
<section title="Consequences for the RMT and MSEC Working Group">
<t>To meet the goals outlined in this document, it is expected that the
RMT and MSEC Working Groups may need to develop some supporting protocol
security mechanisms. It is also possible to cooperate with the Multicast
Backbone (MBONE) Deployment (MBONED) Working Group for defining
operational considerations.</t>
<!-- [HA] Added MBONED WG statement -->
<section title="RMT Transport Message Security Encapsulation Header">
<t>An alternative approach to using IPsec to provide the necessary
properties to protect RMT protocol operation from the application
attacks described earlier, is to extend the RMT protocol message set
to include a message encapsulation option. This encapsulation header
could be used to provide authentication, confidentiality, and
anti-replay protection as needed. Since this would be independent of
the IP layer, the header might need to provide a source identifier to
be used as a "selector" for recalling security state (including
authentication certificate(s), sequence state, etc) for a given
message. In the case of the NORM protocol, a <spanx style="verb">NormNodeId</spanx>
field exists that could be used for this purpose. In the case of ALC,
the security encapsulation mechanism would need to add this function.
The security encapsulation mechanism, although resident "above" the IP
layer, could use <xref target="RFC4535">GSAKMP</xref> or a similar
approach for automated key management.</t>
</section>
<!--
FROM THE JULY 2006 RMT MINUTES:
2- RMT BBs to Standard Track and Security
(point raised by Magnus Westerlund on the ML)
Magnus explains that having specifications (BBs, PIs) on the STD track
without any detailed guidelines on how to implement security services is
not reasonable. Hence this discussion...
Lorenzo answers there are many possible goals which makes this discussion
(and recommendations) difficult. The highest security goal is probably
to protect the network, a lower goal is to protect the protocol itself,
and an even lower goal is to protect the objects being transported.
Magnus agrees that there is a hierarchy of possible goals, but it does
not mean that we can ignore them altogether.
Lorenzo reminds that one initial RMT's goal was scalability, and therefore
it was decided that the source should not know the identity of the
receivers. As a consequence, it makes some security requirements more
complex to achieve.
George Gross: Scalability was one of the goals also for MSEC too
(e.g., for key management). Many BBs developed in MSEC will come for free.
Lorenzo: Do we need any modification to the protocols defined in MSEC
to use them in RMT?
George reminds the group that IPsec has been redesigned recently in order
to support multicast.
Lorenzo: We are not standardizing the application, but the transport.
As RMT is providing transport solutions, is there any need to bother
with application topics?
George: IPsec is one solution, but the question is whether we want to
use it (there are limitations) or want provide security in the
application layer?
Magnus: If we want to do that on a lower layer (i.e., with IPsec) we
need to specify a profile for it here.
The discussion now focuses on the above three goals (content, network
and protocol protection):
1) Content protection:
Magnus: The provider of the content has its own opinion on how to protect
the content.
Lorenzo: It's not the problem of RMT to provide content protection.
We can say we need a WG in the application level to address this problem.
Magnus agrees with Lorenzo.
Mark: Yet but we must keep in mind that there's an urgent need to make
progress. Many people are using FLUTE/ALC now...
Magnus: Confidentiality issue is the last problem to solve. There are
more important problems to solve first.
2) Network protection:
Lorenzo: Network protection in our case means protecting the network
from congestion. What is the situation ?
Brian: There is a potential attack to TFMCC (used by NORM). The sender
can slow down because of a malicious receivers who says to be a bad
node.
George explains that against this kind of receiver feedback attack, the
only solution is to provide group key management and to use digital
signatures. This technique can enable the sender to decide whether
a receiver who sends feedback is an authorized member of the group or
not. But a requirement is to use a key management infrastructure...
3) Protocol protection:
One possible goal is to protect the transport protocol against nodes
that want to stop the protocol.
Lorenzo: Can we mandate the use of SSM to protect NORM?
Magnus answers that an attacker having control over the network can
easily spoof the source, so using SSM does not really solve the problem.
George: Using public keys, a certificate authority and digital signature
can help... The new version of IPsec, that features multicast extensions,
is another way to achieve that goal.
Lorenzo suggests to ask the MSEC WG to have it a WG item. He also
suggests to add in the security requirement of NORM a note explaining
that this scheme can be used.
Gorry: Why do we go to SSM?
Lorenzo explains there's a potential solution for TFMCC if we mandate the
use of SSM. It seems a realistic assumption.
Brian explains that with SSM, a receiver can still slow down the sender
but cannot break the network.
Lorenzo: A possible solution, for TFMCC, is to say that if the sender
receives contradicting feedback, then he should trust the worst one.
Gorry explains that in case of the ALC layer congestion control
scheme, there's an incentive to receive at a higher rate even if it
breaks the network (i.e., by not being fair with other TCP flows).
Lorenzo: Is there any work in unicast to address the problem?
What about a TCP receiver that acknowledges each packet even if
he didn't receive them? It can happen in NORM and ALC but also in TCP.
It seems to be a very tough problem since it needs to involve the routers.
Somebody explains that the problem is that we trust the host to do
the congestion control. In TCP, if a receiver misbehaves, he will
probably be the only one to be hurt.
Lorenzo: So we have a very big problem here... But we are only
opening issues, we are not solving them!
-->
</section>
<section title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
<section title="Security Considerations">
<t>This document is a general discussion of security for the RMT
protocol family. But specific security considerations are not applicable
as this document does not introduce any new techniques.</t>
</section>
<section title="Acknowledgments">
<t>The authors would like acknowledge Magnus Westerlund for stimulating
the working group activity in this area. Additionally George Gross and
Ran Atkinson contributed many ideas to the discussion here.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.4301'?>
<?rfc include='reference.RFC.5052'?>
<?rfc include="reference.I-D.ietf-rmt-flute-revised"?>
<?rfc include="reference.RFC.5740"?>
<?rfc include='reference.RFC.4535'?>
<?rfc include='reference.RFC.4552'?>
<?rfc include='reference.RFC.4046'?>
<?rfc include='reference.RFC.4609'?>
<!-- [HA] RFC4609: mroutesec -->
<?rfc include="reference.RFC.5775"?>
<?rfc include="reference.RFC.5776"?>
<reference anchor="SimpleAuth">
<front>
<title>Simple Authentication Schemes for the ALC and NORM
Protocols</title>
<author fullname="Vincent Roca" initials="V." surname="Roca">
<organization></organization>
</author>
<date day="" month="October" year="2009" />
</front>
<seriesInfo name="Internet Draft"
value="draft-ietf-rmt-simple_auth-for-alc-norm-02.txt (work in progress)" />
</reference>
<?rfc include='reference.RFC.3376'?>
<?rfc include='reference.RFC.3810'?>
<?rfc include='reference.RFC.1112'?>
<?rfc include='reference.RFC.3569'?>
<?rfc include='reference.RFC.4607'?>
<?rfc include='reference.RFC.4654'?>
</references>
<references title="Informative References">
<reference anchor="Neumann05">
<front>
<title>Large Scale Content Distribution Protocols</title>
<author fullname="Christoph Neumann" initials="C." surname="Neumann">
<organization></organization>
</author>
<author fullname="Vincent Roca" initials="V." surname="Roca">
<organization></organization>
</author>
<author fullname="Rod Walsh" initials="R." surname="Walsh">
<organization></organization>
</author>
<date month="October" year="2005" />
<abstract>
<t></t>
</abstract>
</front>
<seriesInfo name="ACM Computer Communications Review (CCR)"
value="Vol. 35 No. 5" />
</reference>
<reference anchor="RsaPaper">
<front>
<title>A Method for Obtaining Digital Signatures and Public-Key
Cryptosystems</title>
<author fullname="R.L. Rivest" initials="R.L." surname="Rivest">
<organization></organization>
</author>
<author fullname="A. Shamir" initials="A." surname="Shamir">
<organization></organization>
</author>
<author fullname="L. Adleman" initials="L." surname="Adleman">
<organization></organization>
</author>
<date year="1978" />
</front>
<seriesInfo name="Communications of the ACM 21," value="pp. 120-126" />
<format target="http://people.csail.mit.edu/rivest/Rsapaper.pdf"
type="HTML" />
</reference>
<?rfc include='reference.RFC.1305'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:56:40 |