OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-if message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Fw: One-way data delivery incl. comments related to the Infrastructure Statement



----- Original Message ----- 
From: "Kon Wilms" <kon.wilms@ndsamericas.com>
To: <rcarlton@consultrac.com>
Sent: Tuesday, November 18, 2003 5:36 PM
Subject: One-way data delivery incl. comments related to the Infrastructure
Statement


> Rick -
>
> Here's the one-pager. Please forward it on to the group if it looks ok to
> you.
>
> To follow up on the action item I had, I've attached a brain-dump document
> regarding one-way data transmission. It is not intended to be
> all-encompassing, and it does a lot of sweeping since the topic area is so
> huge.
>
> Comments below as requested by Rick refer to the EMIF-SC statement
document,
> and context can be had from looking at the attached document. Remember
these
> are non-general examples only.
>
> Cheers
> Kon
>
> -- snip
>
> >Effective delivery/distribution processes are more about transport
> >pattern and transport-mode capacity, than simply one-way vs. two-way
> >communication. In this context, the EMIF-SC asserts that there are
> >essentially five types of delivery/distribution control that a sender
> >may impose on a payload receiver;
> >1.      No control: the payload is sent to all who subscribe.
>
> Achieved by simply broadcasting the data with no constraints. There may be
a
> difference between all who subscribe, and all. To restrict to subscribers,
> data could be encrypted.
>
> >2.      Audience designation: the payload is sent to particular types
> >of organizations or individuals who subscribe.
>
> Commonly referred to as targeting. The users or the actual services may be
> grouped into packages or bouquets. Users may filter data on the receiver
> side, or service providers may restrict data by way of issuing
entitlements
> on the transmission side of the network. Data may be encrypted using said
> entitlements or simply flagged for receiver-side automatic filtering.
>
> >3.      Authenticated audience designation: the payload is sent to
> >particular organizations or persons who are able to certify their
> >receipt through authentication.
>
> Users may authenticate on one-way systems by the basic rules of 'what I
> know, what I have'. e.g. personal pin-code key combined with phsyical
secure
> device such as smartcard. User access is controlled by delivery of
> entitlement data from the network headend to the smartcard device. In this
> way the network controls authentication directly, and only known devices
can
> decrypt payloads when authenticated by the owner of the key. Further
> filtering is done based on service groups per user or group of users. This
> is but one mechanism to accomplish authenticated audience designation on
> one-way networks. Depending on the level of security required, reception
> constraints may range from simple software pin-code, all the way up the
> chain to AES-192 encrypted streams and PKI entitlement packets combined
with
> processor smartcards or authentication chips. Typically PKI is used to
> transmit the service keys, which then when properly decrypted allow for
> secondary decryption of service data. Service data is delivered in
symmetric
> key format for high bitrates, and may use almost any cipher chaining mode.
>
> >4.      Individual receiver specification: the payload is sent to
> >addresses compiled and individually specified by the sender.  It is
> >assumed that the sender will manually authenticate each address and
> >its owner.
>
> The same type of mechanism as (2) and (3) applies. A user is a target, and
> they are entitled for a service before it starts transmission (or during
> transmission).
>
> >5.      Acknowledged individual receiver specification: the payload
> >is sent to individual addresses that are required to acknowledge its
> >receipt. (This could be carried forward to a non-repudiated
> >acknowledgement, requiring specific authentication of the source of
> >the acknowledgement.)
>
> Receipt acknowledgement can be accomplished by periodic dialback or
> connection via a non-'always-on' network. This data may be securely stored
> on the decryption device or the receiver device, or left in the clear.
>
> >Receipt management moves the issue of control from the receiver to
> >the sender's viewpoint.  In order to avoid overload, payload
> >subscriptions need to be effective.  This requires effective
> >localization and effective categorization so that individual
> >receivers do not become deluged with unimportant payloads, yet
> >continue to receive information that is truly important.
>
> Most transmission systems are capable of handling prioritized data
delivery
> and parallel transmission of multiple streams. In low-bitrate scenarios
> where only one stream within the transport is viable (simply due to
overhead
> added by multiplying streams), a queue-based priority ordered system would
> be utilized. For high bitrate scenarios, either situation may apply.
>
>
> This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail.
>

EMIF-SC One-way Data Delivery Networks.doc



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]