Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-16-MOBILE] [security] Summary of issues and requirements for PKMv2



Would this also take into consideration the network level broadcasts using multi-level multi-media coding algorithms that would enable sending one signal quality level over one network path and another over a different one, e.g. standard quality television part in one signal level over one network path and the HD television part in another signal level and another path?

Branislav

> -----Original Message-----
> From: owner-stds-802-16-mobile@LISTSERV.IEEE.ORG
> [mailto:owner-stds-802-16-mobile@LISTSERV.IEEE.ORG]On Behalf Of Yigal
> Leiba
> Sent: Friday, May 28, 2004 9:17 AM
> To: STDS-802-16-MOBILE@LISTSERV.IEEE.ORG
> Subject: Re: [STDS-802-16-MOBILE] [security] Summary of issues and
> requirements for PKMv2
>
>
> Dear Loeke,
>
> I think that starting with defining what is broadcast is a
> good direction,
> and I fully accept your analysis. Regarding the 'multimedia
> broadcast', this
> is a term that is defined at the network level, not at the
> cell level, and
> is the same kind of broadcast that is used by your TV set and radio
> (although both are analog) to receive data from a broadcaster.
> You can of course claim that we can do such network level broadcast as
> broadcast within each and every cell (or sector), but such
> type of broadcast
> has very low efficiency (it has to use the most robust and hence least
> efficient modulation, and combat against interference from
> neighbor cells).
> The idea behind multimedia broadcast is to transmit the broadcast
> information to all cells across the network in a synchronized
> manner such
> that instead of destructive interference, signals from
> neighbor cell will
> add and create a macro-diversity effect. Such an effect would
> enable use of
> much more efficient modulation and coding for the broadcast multimedia
> content.
>
> Regards,
> Yigal
>
> -----Original Message-----
> From: Brederveld, Loeke (loeke) [mailto:brederveld@agere.com]
> Sent: Thursday, May 27, 2004 4:02 PM
> To: Yigal Leiba; STDS-802-16-MOBILE@listserv.ieee.org
> Subject: RE: [STDS-802-16-MOBILE] [security] Summary of issues and
> requirements for PKMv2
>
>
> Hi Yigal, all,
>
> I agree fully with you last sentence, that we have to make sure
> everybody means the same thing using the term "broadcast", and for me,
> coming from the data world, I seen already problems there. May be this
> is an open door, but let's try to define the variuos 'broadcasts'
>
> MAC level Broadcast: those MAC level frames which are intended for all
> stations in a subnet. In Ethernet / 802.11 network addressed with the
> destination MAC address ff ff ff ff ff ff.
>
> IP level Broadcast: those IP level frames which are intended
> for all IP
> stations, usualy only in a single IP subnet (else you can have big
> problems :-) ). IP broadcast (255.255.255.255) do use the MAC level
> Broadcaat destination address also.
>
> Furthermore, you have MAC and IP level Multicasts: frames which are
> intended to a select group of stations within an subnet. The station
> itself can decide it will receive certain multicasts. IP level
> Mulicats/Broadcast normally uses also MAC level Multicast/Broadcats
> addressing.
>
> I assume the "Multimedia broadcast" is an application level broadcast
> (video and/or audio broadcast). Usualy these applications are using IP
> level multicast (not all stations are interested in the application
> level broadcast). In a single cell of a wireless data system,
> certainly
> for 802.11 but as I understand, it is the same for 802.16, a multicast
> is only transmitted once, and is encrypted with a groupkey which is
> available to all authenticated stations in the cell.
>
> With this in mind, I don't understand your concern: all
> stations in the
> cell do receive the applcation broadcast content at the same moment.
> Only the latency of their internal processing will cause a slight
> difference in the moment the content is made available to the enduser.
> Different cells will transmit the multicast on different
> times depending
> e.g. on the length of the output queues, but depending on the QOS
> parameters set for the type of traffic, the difference will be within
> the acceptable latency period for that type of traffic, e.g. 50 ms. I
> can't imagine this will be problem?
>
> Loeke
>
> -----Original Message-----
> From: owner-stds-802-16-mobile@listserv.ieee.org
> [mailto:owner-stds-802-16-mobile@listserv.ieee.org] On Behalf Of Yigal
> Leiba
> Sent: Tuesday, May 25, 2004 22:16
> To: STDS-802-16-MOBILE@listserv.ieee.org
> Subject: Re: [STDS-802-16-MOBILE] [security] Summary of issues and
> requirements for PKMv2
>
>
> Hi Jeff, all,
>
> I have some concern with the issue of security for the multimedia
> broadcast content. Please keep in mind the following facts:
> 1. In order
> to fully utilize the possible macro-diversity effect for broadcast, we
> have to ensure that the exact same data is transmitted at the
> exact same
> time from all the BS. It could be that this requirement by
> itself rules
> IP out as the convergence layer suitable for such content. 2. It is
> desired that the broadcast content will be available to MSS
> in Idle mode
> as well. Given these two issues, I think we want to make sure
> that when
> using the word 'broadcast', everybody means the same thing.
>
> Yigal
>
>
> -----Original Message-----
> From: owner-stds-802-16-mobile@listserv.ieee.org
> [mailto:owner-stds-802-16-mobile@listserv.ieee.org]On Behalf Of Jeff
> Mandin
> Sent: Tuesday, May 25, 2004 5:12 PM
> To: STDS-802-16-MOBILE@listserv.ieee.org
> Subject: Re: [STDS-802-16-MOBILE] [security] Summary of issues and
> requirements for PKMv2
>
>
> DJ,
>
> Our points of contention here seem to be what belongs inside
> the MAC and
> what doesn't....
>
> 1. Preauthentication:   As I stated earlier, nothing in the preauth
> message exchange affects the MAC state of any entity; and byzantine
> message forwarding is not properly the job of the MAC layer.
>
> Accordingly, if we add a primitive to the MAC Layer
> Management Entity's
> external interface, we can easily accomodate
> preauthentication as well
> as other Master Key approaches such as the AAA-Server-based ones that
> have been discussed in 802.11i .. ie.
>
>     InstallMasterKey(MasterKey, MasterKeyId)
>
> [ This assumes the Key caching mechanism from
> http://grouper.ieee.org/groups/802/16/tge/contrib/C80216e-04_4
> 6r2.pdf ]
>
> 2. Support for Key Management by External Server - I agree
> with what you
> wrote, so I'm not sure I understand your objection.  Are you stating
> that distribution of MAC-layer keys by an external MBS should
> in fact an
> objective for PKMv2?   My point is that if the MBS is to control data
> access, then it is by definition doing it at L3 and hence way
> out of our
> scope.
>
> 3. "Push" for Multicast TEK -  Thanks for the observations.
> Asymmetric
> signature is obviously the better approach, but would seem to
> necessitate a CA infrastructure or something similar.
>
> - Jeff
>
> >
> > Some thought edited in below.. DJ
> >
> >
> >     -----Original Message-----
> >     *From:* owner-stds-802-16-mobile@LISTSERV.IEEE.ORG
> >     [mailto:owner-stds-802-16-mobile@LISTSERV.IEEE.ORG] *On
> Behalf Of
> >     *Jeff Mandin
> >     *Sent:* Monday, May 24, 2004 11:33 AM
> >     *To:* STDS-802-16-MOBILE@LISTSERV.IEEE.ORG
> >     *Subject:* [STDS-802-16-MOBILE] [security] Summary of issues and
> >     requirements for PKMv2
> >
> >     To the Security Adhoc group,
> >
> >      [snip]
> >     4.  It's been considered desirable to support a model where a
> >     backend server (eg. multimedia broadcast content distribution
> >     server) is responsbile for key management.
> >
> >          [ I think that the best way to support such a broadcast
> >     distribution model would be with IP-layer security/key
> management
> >     and IP multicasting.  Then the MAC layer (ie.BS-to-multiple-SS)
> >     security/key mgt. would be entirely transparent to the content
> >     broadcast service.]
> >
> >     I have a problem with defining an IP distribution
> mechanism since
> >     it is not layer 2. Certainly a management procedure or
> recommended
> >     practice could map IP distibution to a well defined L2
> >     distributions. However at the least we need to provide a L2
> >     distribution mechanism within the MAC. We cannot assume IP to be
> >     present, particularly with the ethernet, 802.1Q and ATM
> >     convergence sublayers.
> >
> >      [snip]
> >     6.  The PKM-KeyReq/Key-Rsp is inefficient for
> distributing TEKs of
> >     Security Associations that are actually used by multiple SS. ie.
> >     as things stand now, each individual SS sends a KeyReq and
> >     receives the key in KeyRsp.  A more efficient "push mode" TEK
> >     distribution is desirable.
> >
> >     For this to be possible, without enabling forgery by members of
> >     the multicast group, it seems that the 'pushed' key needs to be
> >     signed with the BS private key, using an asymmetric key digest
> >     mechanism (RSA? DSA?).
> >
> >     There is a lesser level improvement, which is BS initiated key
> >     transfer. This allows the BS to preempt the key
> transfer time and
> >     spread the load of key transfers.
> >
> >      [snip]
> >     8.   Support for Pre-authentication is desirable - ie.
> enabling an
> >     SS to authenticate with a potential target BS via the backbone
> >     (and establish a shared Master Key) before doing the HO.
> >
> >         [Preauth is an important feature, and can coexist
> with schemes
> >     that receive freshly-derived Master Key material from a trusted
> >     peer BS or ASA server..  However there seems to be no particular
> >     motivation for running preauthentication inside the MAC
> - instead:
> >     preauthentication via a higher-layer mechanism (eg. PANA) using
> >     the ordinary packet transport is appropriate.  Note also that
> >     running preauthentication inside MAC mgt messages leads
> to clumsy
> >     multiple-step proxying, as the BS security sublayers would
> >     sometimes need to forward messages between subnets or
> to different
> >     providers]
> >
> >     Same L2-L3 argument as for key distribution above.
> >     Pre-auth and cunning key derivation schemes could
> indeed co-exist.
> >     I'm not sure if the world will thank us for picking 2 solutions
> >     though. It seems that effective pre-auth needs to be
> tied into the
> >     handover decision making entity (in the NMS?) since it is that
> >     that knows where it might want to pre-auth to. I
> suspect a similar
> >     line of reasoning applies to key derivation schemes. Either way,
> >     its an argument for putting the fast handover security messaging
> >     in the right place in the architecture.
> >
> >
> >     - Jeff Mandin
> >     Security Adhoc Chair
> >
> >     DJ
> >
> >
>