Re: [STDS-802-16-MOBILE] [security] Summary of issues and requirements for PKMv2
Loeke and all,
I fully understood what you said. What broadcast service you are keeping in
mind is a IP broadcast/multicast service on the fixed network.
However, if all BS can transmit the same broadcast content at the same time,
then the end user can receive the multiple frames at the same time
and experience better quality of application content by combining these
multiple frames together.
I called this feature as a macro-diversity effect at the last meeting on my
presentation.
We can obtain the explicit gain over the air anywhere the end MSS can
receive multiple paths for the same application content.
How to transmit the same content from all BSs at the same time is beyond of
standard scope.
This feature is well known in 3G. It implies that this feature can be
deployed without any difficulty.
If you need more information, please see Samsung's contributions of session
#31, 69r1 for general framework and 63r1 for security framework
and take a look at the broadcast service in 3G,
then you can understand more details on what Yigal and I want to point out.
Thanks,
Yong Chang/Ph.D
Samsung Electronics. Ltd.
P.S: If 802.11 does not provide this feature, then I think that this is good
chance to enhance 802.11 also.
----- Original Message -----
From: "Brederveld, Loeke (loeke)" <brederveld@agere.com>
To: "Yigal Leiba" <yigall@RUNCOM.CO.IL>;
<STDS-802-16-MOBILE@listserv.ieee.org>
Sent: Thursday, May 27, 2004 11:02 PM
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_46r2.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
> >
> >
>
>