[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
No Subject
forged))
by smtp-gw.BayNetworks.COM (8.9.1/BNET-98/09/30-E) with ESMTP id MAA21864;
Thu, 17 Dec 1998 12:29:07 -0800 (PST)
[132.245.135.83])
by mailhost.corpeast.BayNetworks.COM (SMI-8.6/BNET-97/05/05-S) with SMTP
id PAA14808; Thu, 17 Dec 1998 15:30:01 -0500
for
Message-Id: <3.0.5.32.19981217152523.008cb9f0@bl-mail2.corpeast.baynetworks.com>
X-Sender: thardjon@bl-mail2.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Thu, 17 Dec 1998 15:25:23 -0500
To: perry@piermont.com, "Carl F. Muckenhirn" <cfm@columbia.sparta.com>
From: Thomas_Hardjono@BayNetworks.COM (Thomas Hardjono)
Subject: Re: Multicast Key Management (was Re: Anycast)
Cc: Dan McDonald <danmcd@Eng.Sun.Com>, irishjd@erols.com (John Irish),
ipsec@tis.com, thardjono@BayNetworks.COM
In-Reply-To: <87btl2k29f.fsf_-_@jekyll.piermont.com>
References: <"Carl F. Muckenhirn"'s message of "Thu, 17 Dec 1998 10:05:40 -0500">
<004901be293c$7dfa8820$0100010a@irish1>
<v04102f01b29ecbdd172a@[157.185.80.137]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@portal.ex.tis.com
Precedence: bulk
At 02:16 PM 12/17/98 -0500, Perry E. Metzger wrote:
>
>"Carl F. Muckenhirn" <cfm@columbia.sparta.com> writes:
>> Multicast key management isn't hard, just complex.
>
>I dispute that.
Let me join-in.
The problem is multi-faceted and is dependent on (among others):
- the multicast application-type (1-to-M or M-to-M)
- whether traffic unidirectional or bidirectional
- the economic-value of the content being delivered
>We've had the topic come up on several occasions of the problem of
>what it means for a group to share a multicast key. In general, any
>secret known by more than two people isn't much of a secret any
>more. If we find ourselves wanting to authenticate wide scale routing
>advertisements and such, this issue becomes critical. Conventional
>methods end up providing no security -- just latency.
There are 3 immediate problems for now:
(1) group key management (getting the keys to the end-users/hosts)
(2) applying the key to the payload/content (modify/enhance IPsec?)
(3) the problem of "infrastructure security" (which you refered
to as "authenticate wide scale routing advertisements).
Problem (3) is harder and includes:
- denial of service attacks (injection of bogus packets and
random joining/grafting to the multicast tree)
- key management for the routers
- authentication vs encryption of control messages
All of these may be dependent on the multicast routing protocol.
>Multicast key management is only "not hard" in the context of a very
>small group of multicast participants all of whom intensely want to
>keep the conversation secret and who trust each other not to forge
>messages. It might be "obvious" how to do this if you have eight guys
>who need to keep a top secret teleconference secure. If you want to
>authenticate a message going to 8,000 hosts, on the other hand, the
>problem is not nearly so simple.
Again, this depends on the application type.
In the case of subscriber/PayPerView (PPV), the wishes of the
content-producer is to ensure that only paying subscribers
get access to the encrypted content.
While getting 100% water-tightness is rather impossible (since
users may still be able to store and re-sell the content),
perhaps other solutions exist at the user-end (eg. decryptor
built-into application/viewer software).
Agreed, the problem is much "harder" with the M-to-M multicast for
conferencing (in which privacy is a *real* issue).
----------------------------------------------------------------------
Thomas Hardjono 3 Federal Street, BL3-03
Bay Architecture Lab Billerica, MA 01821, USA
Nortel Networks Tel: 978-916-4538
email: thardjono@baynetworks.com Fax: 978-916-0620
----------------------------------------------------------------------