[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: reserving some SAIDs
Steve,
In reviewing Ashar's talk, I think there is a general model
for multicast that encompasses what he described and which is not
incompatible with the SAID model we have been discussing. Also, I
disagree with your assesment that the SAID is redundant in the
multicast context and should be ignored. Use of the SAID is a great
unifying principle and allows considerable flexibility in the
granularity at which security services are provided.
In the model Ashar presented, the critical element was that
each source needs to use a different key (with the same stream cipher)
when transmitting, to avoid the problems of key stream reuse in this
multicast scenario. Ashar points out that, for packet video, the
software performance of a cipher like DES, even when used as a key
stream generator, is not generally adequate for this application. (In
contrast, packet voice has proven to be amenable to DES encryption in
the Internet for some time.) So, we should be prepared to accommodate
stream ciphers that, like RC4, can operate at the requisite data
rates. I agree with Ashar that it seems too hard to try to develop
some scheme for apportioning the key stream space to avoid reuse, so
having a different key per source is a good way to deal with this
problem.
The interchange key approach Ashar described, without the
Diffie-Hellman specific aspects, seem like a general solution to this
problem and it can be modeled using the current SAID approach. In
this approach, the interchange key is established as part of SA
establishment and can be effected using unicast or multicast key
distribution techniques. We then view that key as the SA key, common
to all the multicast group members. The per-source key, which may be
changed by the source whenever it wishes, is sent 9encrypted under the
interchange key) as part of the per-packet crypto control into after
the SAID. This makes the per-source key look like a per-packet IV and
the fact that its processing is somewhat different from a real IV is
really just a function of the specific encryption algorithm-mode that
is a characteristic of this SA. The length and processing semantics
for the crypto control info following the SAID is determined by the
parameters that were bound to the SA when it was created, so this does
not represent a deviation from that general model. So, with that
interpretation, I think that the SA model we are developing
accommodates Ashar's general requirement. His specific choice of how
to encrypt the per-source key is just one option; I can imagine ways
of doing this using a DES interchange key, but the result would not
provide the same level of authentication. However, since we have been
talking about an encryption function here, the idea that different
choices of interchange key encryption will result in different
security services other than confidentiality should not be a problem.
Steve