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
> >
> >
>