📄 rfc1949.txt
字号:
RFC 1949 Scalable Multicast Key Distribution May 1996
group key distribution centre (GKDC), and that the functions it
provides should be able to be "passed on" to other nodes as they join
the tree. Hence, our scheme involves truly distributed key
distribution capability, and is therefore scalable. It does not
require dedicated KDCs. We are proposing that a CBT primary core
initially take on the role of a GKDC.
6.1 Operational Overview
When a CBT group is created, it is the group initiator's
responsibility to create a multicast group access control list (ACL)
[14]. It is recommended that this list is a digitally signed
"document", the same as (or along the lines of) an X.509 certificate
[9], such that it can be authenticated. The group initiator
subsequently unicasts the ACL to the primary core for the group. This
communication is not part of the CBT protocol. The ACL's digital
signature ensures that it cannot be modified in transit without
detection. If the group membership itself is sensitive information,
the ACL can be additionally encrypted with the public key of the
primary core before being sent. The ACL can be an "inclusion" list
or an "exclusion" list, depending on whether group membership
includes relatively few, or excludes relatively few.
The ACL described above consists of group membership (inclusion or
exclusion) information, which can be at the granularity of hosts or
users. How these granularities are specified is outside the scope of
this document. Additionally, it may be desirable to restrict key
distribution capability to certain "trusted" nodes (routers) in the
network, such that only those trusted nodes will be given key
distribution capability should they become part of a CBT delivery
tree. For this case, an additional ACL is required comprising
"trusted" network nodes.
The primary core creates a session key subsequent to receiving and
authenticating the message containing the access control list. The
primary core also creates a key encrypting key (KEK) which is used
for re-keying the group just prior to an old key exceeding its life-
time. This re-keying strategy means that an active key is less
likely to become compromised during its lifetime.
The ACL(s), group key, and KEK are distributed to secondary cores as
they become part of the distribution tree.
Any tree node with this information can authenticate a joining
member, and hence, secure tree joining and multicast session key
distribution are truly distributed across already authenticated tree
nodes.
Ballardie Experimental [Page 7]
RFC 1949 Scalable Multicast Key Distribution May 1996
6.2 Integrated Join Authentication and Multicast Key Distribution
For simplicity, in our example we assume the presence of an
internetwork-wide asymmetric key management scheme, such as that
proposed in [17]. However, we are not precluding the use of
symmetric cryptographic techniques -- all of the security services we
are proposing, i.e. integrity, authentication, and confidentiality,
can all be achieved using symmetric cryptography, albeit a greater
expense, e.g. negotiation with a third party to establish pairwise
secret keys. For these reasons, we assume that a public (asymmetric)
key management scheme is globally available, for example, through the
Domain Name System (DNS) [17] or World Wide Web [18].
NOTE: given the presence of asymmetric keys, we can assume digital
signatures provide integrity and origin authentication services
combined.
The terminology we use here is described in Appendix A. We formally
define some additional terms here:
+ grpKey: group key used for encrypting group data traffic.
+ ACL: group access control list.
+ KEK: key encrypting key, used for re-keying a group with a new
group key.
+ SAparams: Security Association parameters, including SPI.
+ group access package (grpAP): sent from an already verified tree
node to a joining node.
[token_sender, [ACL]^SK_core, {[grpKey, KEK,
SAparams]^SK_core}^PK_origin-host,
{[grpKey, KEK, SAparams]^SK_core}^PK_next-hop]^SK_sender
NOTE: SK_core is the secret key of the PRIMARY core.
As we have already stated, the elected primary core of a CBT tree
takes on the initial role of GKDC. In our example, we assume that a
group access control list has already been securely communicated to
the primary core. Also, it is assumed the primary core has already
participated in a Security Association estabishment protocol [20,21],
and thus, holds a group key, a key-encrypting key, and an SPI.
NOTE, there is a minor modification required to the CBT protocol
[4], which is as follows: when a secondary core receives a join,
instead of sending an ack followed by a re-join to the primary,
Ballardie Experimental [Page 8]
RFC 1949 Scalable Multicast Key Distribution May 1996
the secondary forwards the join to the primary; the ack travels
from the primary (or intermediate on-tree router) back to the join
origin. All routers (or only specific routers) become GKDCs after
they receive the ack.
We now demonstrate, by means of an example, how CBT routers join a
tree securely, and become GKDCs. For clarity, in the example, it is
assumed all routers are authorised to become GKDCs, i.e. there is no
trusted-router ACL.
In the diagram below, only one core (the primary) is shown. The
process of a secondary joining the primary follows exactly what we
describe here.
In the diagram, host h wishes to join multicast group G. Its local
multicast router (router A) has not yet joined the CBT tree for the
group G.
b b b-----b
\ | |
\ | |
b---b b------b
/ \ / KEY....
/ \/
b C C = Core (Initial Group Key Dist'n Centre)
/ \ A, B, b = non-core routers
/ \
/ \ ======= LAN where host h is located
B b------b
\
\ NOTE: Only one core is shown, but typically
host h A a CBT tree is likely to comprise several.
o |
=====================
Figure 1: Example of Multicast Key Distribution using CBT
A branch is created as part of the CBT secure tree joining process,
as follows:
+ Immediately subsequent to a multicast application starting up on
host h, host h immediately sends an IGMP group membership
report, addressed to the group. This report is not suppressible
(see Appendix B), like other IGMP report types, and it also
includes the reporting host's token, which is digitally signed
h --> DR (A): [[token_h]^SK_h, IGMP group membership report]
Ballardie Experimental [Page 9]
RFC 1949 Scalable Multicast Key Distribution May 1996
(A host's token differs in two respects compared with tokens
defined in [9]. To refresh, a token assists a recipient in the
verification process, and typically contains: recipient's
unique identity, a timestamp, and a pseudo-random number. A
token is also usually digitally signed by its originator.
Firstly, A host's token does not contain the intended
recipient's identity, since this token may need to traverse
several CBT routers before reaching a GKDC. A host does not
actually know which router, i.e. GKDC, will actually
acknowledge the join that it invoked. Secondly, the host's
token is digitally signed -- this is usual for a token.
However, tokens generated by routers need not be explicitly
digitally signed because the JOIN-REQUESTs and JOIN-ACKs that
carry them are themselves digitally signed.)
+ In response to receiving the IGMP report, the local designated
router (router A) authenticates the host's enclosed token. If
successful, router A formulates a CBT join-request, whose target
is core C (the primary core). Router A includes its own token in
the join, as well as the signed token received from host h. The
join is digitally signed by router A.
NOTE 1: router A, like all CBT routers, is configured with the
unicast addresses of a prioritized list of cores, for different
group sets, so that joins can be targeted accordingly.
NOTE 2: the host token is authenticated at most twice, once by
the host's local CBT router, and once by a GKDC. If the local
router is already a GKDC, then authentication only happens once.
If the local router is not already a GKDC, a failed authentica-
tion check removes the overhead of generating and sending a CBT
join-request.
Router A unicasts the join to the best next-hop router on the
path to core C (router B).
A --> B: [[token_A], [token_h]^SK_h, JOIN-REQUEST]^SK_A
+ B authenticates A's join-request. If successful, B repeats the
previous step, but now the join is sent from B to C (the pri-
mary, and target), and the join includes B's token. Host h's
token is copied to this new join.
B --> C: [[token_B], [token_h]^SK_h, JOIN-REQUEST]^SK_B
+ C authenticates B's join. As the tree's primary authorization
point (and GKDC), C also authenticates host h, which triggered
the join process. For this to be successful, host h must be
Ballardie Experimental [Page 10]
RFC 1949 Scalable Multicast Key Distribution May 1996
included in the GKDC's access control list for the group. If h
is not in the corresponding access control list, authentication
is redundant, and a join-nack is returned from C to B, which
eventually reaches host h's local DR, A.
Assuming successful authentication of B and h, C forms a group
access package (grpAP), encapsulates it in a join-ack, and digi-
tally signs the complete message. C's token, host h's signed
token, a signed ACL, and two (group key, KEK) pairs are included
in the group access package; one for the originating host, and
one for the next-hop CBT router to which the join-ack is des-
tined. Each key pair is digitally signed by the issuer, i.e. the
primary core for the group. The host key pair is encrypted using
the public key of the originating host, so as to be only deci-
pherable by the originating host, and the other key pair is
encrypted using the public key of the next-hop router to which
the ack is destined -- in this case, B. Host h's token is used
by the router connected to the subnet where h resides so as to
be able to identify the new member.
C --> B: [[token^h]^SK_h, grpAP, JOIN-ACK]^SK_C
+ B authenticates the join-ack from C. B extracts its encrypted
key pair from the group access package, decrypts it, authenti-
cates the primary core, and stores the key pair in encrypted
form, using a local key. B also verifies the digital signature
included with the access control list. It subsequently stores
the ACL in an appropriate table. The originating host key pair
remains enciphered.
The other copy of router B's key pair is taken and deciphered
using its secret key, and immediately enciphered with the public
key of next-hop to which a join-ack must be passed, i.e. router
A. A group access package is formulated by B for A. It contains
B's token, the group ACL (which is digitally signed by the pri-
mary core), a (group key, KEK) pair encrypted using the public
key of A, and the originating host's key pair, already
encrypted. The group access package is encapsulated in a join-
ack, the complete message is digitally signed by B, then for-
warded to A.
B --> A: [[token^h]^SK_h, grpAP, JOIN-ACK]^SK_B
+ A authenticates the join-ack received from B. A copy of the
encrypted key pair that is for itself is extracted from the
group access package and deciphered, and the key issuer (primary
core) is authenticated. If successful, the enciphered key pair
is stored by A. The digital signature of the included access
Ballardie Experimental [Page 11]
RFC 1949 Scalable Multicast Key Distribution May 1996
control list is also verified, and stored in an appropriate
table. The key pair encrypted for host h is extracted from the
group access package, and is forwarded directly to host h, which
is identified from the presence of its signed token. On
receipt, host h decrypts the key pair for subsequent use, and
stores the SA parameters in its SA table.
A --> h: [[token^h]^SK_h, {grpKey, KEK, SAparams}^PK_h]
Going back to the initial step of the tree-joining procedure, if the
DR for the group being joined by host h were already established as
part of the corresponding tree, it would already be a GKDC. It would
therefore be able to directly pass the group key and KEK to host h
after receiving an IGMP group membership report from h:
A --> h: [[token^h]^SK_h, {grpKey, KEK, SAparams}^PK_h]
If paths, or nodes fail, a new route to a core is gleaned as normal
from the underlying unicast routing table, and the re-joining process
(see [4]) occurs in the same secure fashion.
7. A Question of Trust
The security architecture we have described, involving multicast key
distribution, assumes that all routers on a delivery tree are trusted
and do not misbehave. A pertinent question is: is it reasonable to
assume that network routers do not misbehave and are adequately
protected from malicious attacks?
Many would argue that this is not a reasonable assumption, and
therefore the level of security should be increased to discount the
threat of misbehaving routers. As we described above, routers
periodically decrypt key pairs in order to verify them, and/or re-
encrypt them to pass them on to joining neighbour routers.
In view of the above, we suggest that if more stringent security is
required, the model we presented earlier should be slightly amended
to accommodate this requirement. However, depending on the security
requirement and perceived threat, the model we presented may be
acceptable.
We recommend the following change to the model already presented
above, to provide a higher level of security:
All join-requests must be authenticated by a core router, i.e. a join
arriving at an on-tree router must be forwarded upstream to a core if
the join is identified as being a "secure" join (as indicated by the
presence of a signed host token).
Ballardie Experimental [Page 12]
RFC 1949 Scalable Multicast Key Distribution May 1996
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -