ISO/IEC 16512-2:2008/FDAmd 1
(Amendment)Information technology — Relayed multicast protocol: Specification for simplex group applications — Part 2: — Amendment 1: Security extensions
Information technology — Relayed multicast protocol: Specification for simplex group applications — Part 2: — Amendment 1: Security extensions
Technologies de l'information — Protocole de multidiffusion relayé: Spécification relative aux applications de groupe simplex — Partie 2: — Amendement 1: Extensions de sécurité
General Information
Relations
Standards Content (Sample)
FINAL ISO/IEC
AMENDMENT
DRAFT 16512-2:2008
FDAM 1
ISO/IEC JTC 1
Information technology — Relayed
Secretariat: ANSI
multicast protocol: Specification for
Voting begins on:
simplex group applications
2011-03-04
Voting terminates on:
AMENDMENT 1: Security extensions
2011-05-04
Technologies de l'information — Protocole de multidiffusion relayé:
Spécification relative aux applications de groupe simplex
AMENDEMENT 1: Extensions de sécurité
Please see the administrative notes on page ii-1
RECIPIENTS OF THIS DRAFT ARE INVITED TO
SUBMIT, WITH THEIR COMMENTS, NOTIFICATION
OF ANY RELEVANT PATENT RIGHTS OF WHICH
THEY ARE AWARE AND TO PROVIDE SUPPORT-
ING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
Reference number
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/IEC 16512-2:2008/FDAM 1:2011(E)
LOGICAL, COMMERCIAL AND USER PURPOSES,
DRAFT INTERNATIONAL STANDARDS MAY ON
OCCASION HAVE TO BE CONSIDERED IN THE
LIGHT OF THEIR POTENTIAL TO BECOME STAN-
DARDS TO WHICH REFERENCE MAY BE MADE IN
©
NATIONAL REGULATIONS. ISO/IEC 2011
---------------------- Page: 1 ----------------------
ISO/IEC 16512-2:2008/FDAM 1:2011(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
Copyright notice
This ISO document is a Draft International Standard and is copyright-protected by ISO. Except as permitted
under the applicable laws of the user's country, neither this ISO draft nor any extract from it may be
reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic,
photocopying, recording or otherwise, without prior written permission being secured.
Requests for permission to reproduce should be addressed to either ISO at the address below or ISO's
member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Reproduction may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
ii © ISO/IEC 2011 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 16512-2:2008/FDAM 1:2011(E)
In accordance with the provisions of Council Resolution 21/1986, this document is circulated in the
English language only.
© ISO/IEC 2011 – All rights reserved ii-1
---------------------- Page: 3 ----------------------
ISO/IEC 16512-2:2008/FDAM 1:2011(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
Amendment 1 to ISO/IEC 16512-2 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information
technology, Subcommittee SC 6, Telecommunications and information exchange between systems, in
collaboration with ITU-T. The identical text is published as ITU-T Rec. X.603.1 (2007)/Amd.1 (11/2009).
© ISO/IEC 2011 – All rights reserved iii
---------------------- Page: 4 ----------------------
ISO/IEC 16512-2:2008/Amd.1:2011 (E)
INTERNATIONAL STANDARD
RECOMMENDATION ITU-T
Information technology – Relayed multicast protocol:
Specification for simplex group applications
Amendment 1
Security extensions
1) Clause 1, Scope
Delete the existing text and replace it with the following:
This Recommendation | International Standard specifies the Relayed MultiCast Protocol for simplex group applications
(RMCP-2), an application-layer protocol, which constructs a multicast tree for data delivery from one sender to multiple
receivers over the Internet where IP multicast is not fully deployed.
Clauses 5-8 define a basic RMCP-2 protocol without security features, and clauses 9-12 define a secure RMCP-2
protocol that adds security features to the basic protocol. Both protocols specify a series of functions and procedures for
multicast agents to construct a one-to-many relayed data path and to relay simplex data. They also specify the
operations of the session manager to manage multicast sessions.
These protocols can be used for applications that require one-to-many data delivery services, such as multimedia
streaming services or file dissemination services.
Annex E defines a membership authentication procedure for use with the secure RMCP-2 protocol. Annexes A-D
provide informative material related to these protocols. Annex F contains an informative bibliography.
2) Clause 2, Normative references
Following the first paragraph, re-order the existing references and add new subheadings as follows:
2.1 Identical Recommendations | International Standards
– Recommendation ITU-T X.603 (2004) | ISO/IEC 16512-1:2005, Information technology – Relayed
multicast protocol: Framework.
2.2 Additional references
– ISO/IEC 9797-2:2002, Information technology – Security techniques – Message Authentication Codes
(MACs) – Part 2: Mechanisms using a dedicated hash-function.
– ISO/IEC 9798-3:1998, Information technology – Security techniques – Entity authentication –
Part 3: Mechanisms using digital signature techniques.
– ISO/IEC 18033-2:2006, Information technology – Security techniques – Encryption algorithms – Part 2:
Asymmetric ciphers.
– ISO/IEC 18033-3:2005, Information technology – Security techniques – Encryption algorithms – Part 3:
Block ciphers.
– ISO/IEC 18033-4:2005, Information technology – Security techniques – Encryption algorithms – Part 4:
Stream ciphers.
– IETF RFC 2094 (1997), Group Key Management Protocol (GKMP) Architecture.
– IETF RFC 3546 (2003), Transport Layer Security (TLS) Extensions.
– IETF RFC 3830 (2004), MIKEY: Multimedia Internet KEYing.
– IETF RFC 4279 (2005), Pre-Shared Key Ciphersuites for Transport Layer Security (TLS).
– IETF RFC 4346 (2006), The Transport Layer Security (TLS) Protocol Version 1.1.
– IETF RFC 4535 (2006), GSAKMP: Group Secure Association Key Management Protocol.
Rec. ITU-T X.603.1 (2007)/Amd.1 (11/2009) 1
FINAL DRAFT / PROJET FINAL
---------------------- Page: 5 ----------------------
ISO/IEC 16512-2:2008/Amd.1:2011 (E)
3) Clause 3, Definitions
Add the following definitions to clause 3:
3.13 RMCP-2 protocol: A relayed multicast protocol for simplex group applications.
NOTE – When used in clauses 5-8, this term has the same meaning as basic RMCP-2. It is expected that this term will be
withdrawn and replaced by basic RMCP-2 protocol in future revisions of this Recommendation | International Standard.
3.14 basic RMCP-2 protocol: The relayed multicast protocol for simplex group application defined in clauses 5-8.
3.15 secure RMCP-2 protocol: The relayed multicast protocol supporting security features for simplex group
applications defined in clauses 9-12.
3.16 dedicated multicast agent (DMA): An intermediate MA pre-deployed as a trust server by the Session
Manager (SM) in an RMCP session.
3.17 security policy: The set of criteria for the provision of security services, together with the set of values for
these criteria, resulting from agreement of the security mechanisms defined in 10.1.4.
3.18 TLS_CERT mode: A mode of the TLS defined in IETF RFC 4346 for the authentication of MAs using a
certificate.
3.19 TLS_PSK mode: A mode of the TLS defined in IETF RFC 4279 for the authentication of MAs using a pre-
shared key for the TLS key exchange.
3.20 relayed multicast region; RM region: A management zone defined by the use of the session key Ks.
3.21 member multicast region; MM region: A management zone defined by the use of one or more group
keys Kg.
3.22 member multicast group; MM group:
1) (in a multicast disabled area) a group consisting of one DMA and multiple RMAs sharing the same
group key Kg.
2) (in a multicast enabled area) a group consisting of one HMA, multiple RMAs together with one or more
candidate HMAs sharing the same group key Kg.
3.23 candidate HMA: A DMA that is able to assume the role of an HMA, should the original HMA leave or be
terminated from a multicast-enabled MM group.
3.24 group attribute (GP_ATTRIBUTE): An attribute that defines whether or not the Content Provider controls
the admission of RMAs to the secure RMCP-2 session.
3.25 closed group: An MM group in which all the RMAs have been allocated a service user identifier from the
Content Provider before subscribing to the secure RMCP-2 session.
3.26 open group: An MM group in which none of the RMAs require a service user identifier before subscribing to
the secure RMCP-2 session.
4) Clause 4, Abbreviations
Add the following abbreviations to clause 4:
ACL Access Control List
AUTH Authentication
CEK Contents Encryption Key
CP Content Provider
HRSREQ Head Required Security Request
HRSANS Head Required Security Answer
KEYDELIVER Key Delivery
SECAGREQ SECurity AGreement REQuest
SECAGANS SECurity AGreement ANSwer
SECALGREQ SECurity ALgorithms REQuest
SECLIST Selected sECurity LIST
TLS Transport Layer Security
2 Rec. ITU-T X.603.1 (2007)/Amd.1 (11/2009)
FINAL DRAFT / PROJET FINAL
---------------------- Page: 6 ----------------------
ISO/IEC 16512-2:2008/Amd.1:2011 (E)
5) New clauses 9-12
Add the following new clauses:
9 Overview of secure RMCP-2
9.1 Conventions
9.1.1 Use of basic RMCP-2 protocol
The term basic RMCP-2 protocol, when used in clauses 9-12, refers to the protocol defined in clauses 5-8.
9.1.2 Hexadecimal notation
Code values for message parameters in clause 11 (Format of secure RMCP-2 messages) and clause 12 (Parameters) are
expressed in hexadecimal notation, e.g., 0x14 for 20 in decimal notation.
9.2 Secure RMCP-2 entities
9.2.1 Introduction
The secure RMCP-2 protocol supports security functions of the RMCP-2 used for relayed multicast data transport
through unicast communication over the Internet.
The secure RMCP-2 protocol components correspond to those described in the basic RMCP-2 protocol except that a
new type of MA, a dedicated multicast agent (DMA), has been introduced. A dedicated multicast agent is an
intermediate MA pre-deployed as a trust server by the SM. For secure communication, each session consists of an SM,
an SMA, DMAs, RMAs, together with a single sending application and multiple receiving applications. Their topology,
as shown in Figure 85, corresponds with that in the basic RMCP-2 protocol (see 5.1).
Sending
SMA SM
App.
DMA
RMA RMA RMA
Receiving Receiving Receiving
App. App. App.
X.603.1(07)Amd.1(09)_F85
Figure 85 – RMCP-2 service topology with security
Rec. ITU-T X.603.1 (2007)/Amd.1 (11/2009) 3
FINAL DRAFT / PROJET FINAL
---------------------- Page: 7 ----------------------
ISO/IEC 16512-2:2008/Amd.1:2011 (E)
9.2.2 Session manager
The SM is responsible for maintaining session security, which includes the management of service membership, the
management of key and ACL for DMA and RMA, and message encryption/decryption together with the SM functions
of basic RMCP-2. Figure 86 shows an abstract protocol stack for the operation of SM functions. The SM has TLS and
multicast session security modules for the provision of security. TLS is used for the initial authentication of DMAs and
RMAs when they join the session. The Multicast session security module performs the following security functions
after the completion of TLS authentication:
a) Security policy;
b) Session admission management;
c) Session key management;
d) Access Control list management;
e) Secure group and membership management;
f) Message encryption/decryption.
Figure 86 – Internal structure of the SM
9.2.3 Dedicated multicast agents
DMAs are in charge of the secure establishment and maintenance of the RMCP-2 tree, support of membership
authentication and data confidentiality. Figure 87 shows the internal structure of the DMAs with modules for
Key/Message Security Management and Group/Member Security Management. These modules support the following
security functions:
Key/Message Security Management Module
a) Group key management;
b) Message encryption/decryption;
c) Contents encryption key management.
Group/Member Security Management Module
a) Secure tree configuration;
b) Session key management;
c) Secure group and membership management.
4 Rec. ITU-T X.603.1 (2007)/Amd.1 (11/2009)
FINAL DRAFT / PROJET FINAL
---------------------- Page: 8 ----------------------
ISO/IEC 16512-2:2008/Amd.1:2011 (E)
Figure 87 – Internal structure of DMAs
9.2.4 Sender and receiver multicast agents
The internal structure of the SMA and the RMAs is shown in Figure 88. The structure is the same as for DMAs except
that the Group Security Management Module is not included.
Figure 88 – Internal structure of the SMA and RMAs
9.3 Protocol blocks
The protocol blocks for the SM, Group/Member Security Management of MAs and Key/Message Security Management
of MAs are shown in Figures 89, 90 and 91. They correspond to the protocol stacks in the basic RMCP-2 protocol in 5.2
(see Figures 2, 3 and 4) but also include the TLS protocol and the Multicast Session Security Module.
The secure RMCP-2 protocol supports general encryption/decryption algorithms of TLS for a variety of common
applications. The SM and MAs (SMA, DMAs and RMAs) share the security information described in the security
policy. The Multicast Session Security Module contains common symmetric encryption/decryption algorithms,
authentication mechanisms, and multicast security modules related to RMCP-2 security functions.
Rec. ITU-T X.603.1 (2007)/Amd.1 (11/2009) 5
FINAL DRAFT / PROJET FINAL
---------------------- Page: 9 ----------------------
ISO/IEC 16512-2:2008/Amd.1:2011 (E)
Figure 89 – Protocol block of the SM
The SM messages and the Group/Member Security Management messages of MAs are transmitted reliably through the
TCP protocol.
Figure 90 – Protocol block for the group/member security management of MAs
Key/Message Security Management messages may be transferred using any transport protocol. The transport protocol
may be selected according to the nature of the transferred data types. TLS provides secure communication for TCP over
unicast communication. The Multicast Security Encryption/Decryption and Authentication Modules protect the
multicast packets. These modules contain common symmetric encryption algorithms, hash algorithms, and multicast
security modules defined in this Recommendation | International Standard to protect the multicast packets.
Figure 91 – Protocol block for the key/message security management of MAs
6 Rec. ITU-T X.603.1 (2007)/Amd.1 (11/2009)
FINAL DRAFT / PROJET FINAL
---------------------- Page: 10 ----------------------
ISO/IEC 16512-2:2008/Amd.1:2011 (E)
9.4 Types of secure RMCP-2 protocol messages
Control messages are exchanged between secure RMCP-2 protocol nodes in a request-and-answer manner.
Table 9 shows the messages that are specific to the secure RMCP-2 protocol. They complement the messages listed in
Table 1 (see 5.4).
Table 9 – Secure RMCP-2 messages
Messages Meaning Operations
SUBSREQ Additional control type= Session Initialization
(control type= SERV_USER_IDENT in SUBSREQ
SERV_USER_IDENT) (Subscription request)
RELREQ Additional control type=AUTH Membership Authentication
(control type=AUTH) in RELREQ (Relay request)
RELANS Additional control type=AUTH_ANS
(control type=AUTH_ANS) in RELANS (Relay answer)
Establishment of Multicast Security Policy
SECAGREQ Security Agreement request
SECLIST Security List
SECALGREQ Security Algorithms request
SECAGANS Security Agreement answer
Key Distribution
KEYDELIVER Key Delivery
Group Member Authentication
HRSREQ Head Required Security request
Group Key Distribution ACL Management
HRSANS Head Required Security answer
9.5 Structure of regional security management
For scalable security management, the secure RMCP-2 protocol supports security functions in two independent regions:
a RM (Relayed Multicast) region and a MM (Member Multicast) region.
The RM region is a management zone of the session key (Ks). It consists of the SM, the SMA and DMAs in a multicast
disabled area.
MM-group 1
: multicast-disabled
RM region
SMA
SMA
MM-group 2
+Sending Application
: multicast-disabled
Candidate HMA
MM-group 3
MM region
: multicast-enabled
Figure 92 – Security management regions
Rec. ITU-T X.603.1 (2007)/Amd.1 (11/2009) 7
FINAL DRAFT / PROJET FINAL
---------------------- Page: 11 ----------------------
ISO/IEC 16512-2:2008/Amd.1:2011 (E)
The MM region is a management zone defined by the use of group keys (Kg). The MM region consists of DMAs and
RMAs. They can be connected over a multicast-enabled or a multicast-disabled network. The MM region consists of
one or more MM groups each using its own Kg group key.
Multicast-enabled MM groups consist of an HMA, one or more candidate HMAs and multiple RMAs that receive the
same multicast messages. Candidate HMAs are DMAs that are not connected to the data delivery tree, but have the
capability to assume the role of HMA if required. Multicast-disabled MM groups consist of one DMA and multiple
RMAs. In both cases, the RMAs are logically connected direct to their parent DMA on the data delivery tree.
Any change in an MM group is localized within the scope of its own MM group.
10 Protocol operation
10.1 SM operation
The SM supports the establishment of security policies applied to each secure RMCP-2 session, and is responsible for
user and MA security management such as user and MA authentication. It manages the session key for each RMCP-2
session through the creation, update, and distribution of key information. The SM also has message encryption and
decryption abilities through the use of TLS and owned cryptography suites.
10.1.1 Admission control
10.1.1.1 TLS authentication
TLS authentication is performed in advance of the subscription requests of MAs (SMA, DMAs or RMAs). An MA
establishes a TLS session with the SM according to IETF RFC 3546. The SM, as part of the IETF 3546 procedure,
decides which TLS mode, TLS_CERT or TLS_PSK, is applied for the verification of the parties concerned. The SM
responds to the MA and, if the mutual authentication is successful, shares a secret key K with the MA.
TLS
The SM also delivers the session key Ks, encrypted using K , to the SMA and the DMAs, but not to the RMAs.
TLS
The TLS session with the SMA and DMAs is closed after the session key is delivered, since the SM, SMA and DMAs
exchange control messages that have been encrypted with the session key. The TLS session with RMAs is retained and
not closed until membership authentication with their parent DMA in the secure tree join procedure (see 10.2.4) and the
individual key KMAS has been established.
10.1.1.2 Admission of the SMA
A secure RMCP-2 session is initiated through the subscription of the SMA. The SMA first obtains authorization for
providing the contents from the SM. The SMA is authenticated by the SM through the TLS session (see 10.1.1.1) and
then joins the session by exchanging SUBSREQ and SUBSANS messages with the SM. As a result of this, the SMA
receives the session key Ks and is enabled to act as an administrative node of the secure RMCP-2 tree.
10.1.1.3 Admission of DMAs
The DMAs, as prospective trust parties, are invited by the SM to join the session and to establish the DMA network
before the subscription of RMAs. The means of this invitation are outside the scope of this Recommendation |
International Standard.
The DMAs are authenticated by the SM through the TLS session and they join the session through the exchange of
SUBSREQ and SUBSANS messages with the SM. They receive the session key Ks from the SM and join the RMCP-2
tree through the secure tree join procedure (see 10.2.4).
The SM consults with the DMAs joining the session before the announcement of the opening of the secure RMCP-2
session, giving a date and time when the subscription of RMAs begins. The means of this announcement are outside the
scope of this Recommendation | International Standard.
10.1.1.4 Admission of RMAs to open groups
A potential RMA will know from the announcement of the session whether or not the session supports open groups.
The RMAs are authenticated by the SM through the TLS session and join the session through the exchange of
SUBSREQ and SUBSANS messages with the SM. They do not receive the session key Ks. They join the RMCP-2 tree
through the secure tree join procedure (see 10.2.4).
8 Rec. ITU-T X.603.1 (2007)/Amd.1 (11/2009)
FINAL DRAFT / PROJET FINAL
---------------------- Page: 12 ----------------------
ISO/IEC 16512-2:2008/Amd.1:2011 (E)
10.1.1.5 Admission of RMAs to closed groups
A potential RMA will know from the announcement of the session whether or not the session supports closed groups.
Access to membership of closed groups is controlled by the content provider (CP). A potential RMA requests a service
user identifier from the CP. The CP provides a service user identifier to the potential RMA and also sends the service
user identifier, without revealing the identity of the potential RMA, to the SM. The CP is responsible for the format of
this identifier and this is not defined in this Recommendation | International Standard.
When the session is opened to RMAs, the RMAs are authenticated by the SM through the TLS session and they join the
session through the exchange of SUBSREQ and SUBSANS messages with the SM. The SUBSREQ message shall
contain the service user identifier. The SM shall send a rejection in the RESULT control of the SUBSANS message if
the SM does not hold an identical service user identifier.
The RMAs do not receive the session key Ks. They join the RMCP-2 tree through the secure tree join procedure
(see 10.2.4).
10.1.2 Key management for which the SM is responsible
10.1.2.1 Session key
The session key (Ks) is shared between the SM, the SMA and DMAs and is used to encrypt/decrypt control messages in
the RM region. It is initially created by the SM in the bootstrapping of the RMCP-2 session. Ks is encrypted by the
individual key K (see 10.1.2.2) for delivery to the SMA and to each DMA through the data protection procedure of
TLS
TLS following successful TLS authentication.
Ks is updated at regular intervals through the hash function. When a DMA is truncated or an abnormal situation occurs,
the SM does not use the hash function, but instead creates a totally new session key Ks, without hashing. The new key
is delivered to the SMA and all DMAs in the RMCP-2 session (see Figure 93).
Figure 93 – Session key management
10.1.2.2 TLS key
The TLS key K is a private key generated through successful TLS authentication during admission control. Each MA
TLS
(SMA, DMA and RMA) shares a different K with the SM, which is not shared with the other MAs. K is not
TLS TLS
updated during the lifetime of the RMCP-2 session.
10.1.3 Establishment of security policy
When a new RMCP-2 session is created, the SM, together with the SMA and the DMAs, establish the security policy
for the session. The policy is established through the exchange of SECAGREQ, SECLIST and SECAGANS messages
that enable the selection of the parameters in Table 10 to define the level of security that is to be provided, as well as the
choice of algorithms to be used. The security policy is the set of selected attributes of policy items after the agreement
on security mechanisms.
Rec. ITU-T X.603.1 (2007)/Amd.1 (11/2009) 9
FINAL DRAFT / PROJET FINAL
---------------------- Page: 13 ----------------------
ISO/IEC 16512-2:2008/Amd.1:2011 (E)
Table 10 – Multicast security policy
Item Attributes Definition Further details
CON_EN_DEC_ID – AES CBC Mode 128-bit key Notifies which encryption/decryption algorithm See Table 16
is used for content data
– AES CTR Mode 128-bit key
– PKCS #1
– SEED
GK_EN_DEC_ID – AES CBC Mode 128-bit key Notifies which encryption/decryption algorithm See Table 16
is used for content data for group keys
– AES CTR Mode 128-bit key
– PKCS #1
– SEED
AUTH_ID – HMAC-SHA Notifies which hash/MAC algorithm is applied See Table 17
– HMAC-MD5
– MD5
GP_ATTRIBUTE – closed Notifies the nature of the group See Table 18
– open (default)
GK_MECHA – static Notifies updating properties of the group key See Table 19
– periodic
– backward
– forward
– periodic+backward
– periodic+forward
– periodic+backward+forward
GK_NAME – KDC Notifies which group key mechanism is used. See Table 20
– GKMP
– MIKEY
– GSAKMP
– LKH
AUTH_ATTRIBUTE – membership Notifies the type of authentication used See Table 21
AUTH_NAME – MEM_AUTH Notifies the authentication mechanism used See Table 22
10.1.4 Agreement of security mechanisms
10.1.4.1 SMA and DMAs
The security procedure is initiated after the admission control. The messages are protected by the session key between
the SM, SMAs and DMAs, and by the K between the SM and the RMAs. The SMA and the DMAs perform the
TLS
procedure prior to RMA subscription because the server-oriented systems (SMA and DMAs) need to set up the security
policy in order to provide a stable service. The SMA and DMAs (see Figure 94) each request a security agreement
(SECAGREQ) containing their own security mechanisms and algorithms. After a Security Agree.time, the SM
examines the SECAGREQ messages, determines the security policy for the session and sends the security policy
(SECLIST) to the SMA and DMAs. If any of these MAs do not have the algorithms of the security policy, they request
copies from the SM (SECALGREQ) and the SM sends the corresponding security modules to them. The method for the
delivery of these modules is outside the scope of this Recommendation | International Standard. The SMA and each
DMA configure the agreed security mechanisms. After configuration, the MAs send an acknowledgement
(SECAGANS) to the SM.
10 Rec. ITU-T X.603.1 (2007)/Amd.1 (11/2009)
FINAL DRAFT / PROJET FINAL
---------------------- Page: 14 ----------------------
ISO/IEC 16512-2:2008/Amd.1:2011 (E)
Figure 94 – Security agreement of DMA and SMA
10.1.4.2 RMAs
When the session is opened for RMA subscription, each RMA requests a security agreement (SECAGREQ) (see
Figure 95). The SM sends the security policy (SECLIST) to the RMA. If the RMA does not have any of the algorithms
of the security policy, it requests copies from the SM (SECALGREQ) and the SM sends the corresponding security
modules to the RMA. The method for the delivery of these modules is outside the scope of this Recommendation |
International Standard. The RMA configures the agreed security mechanisms and sends an acknowledgement
(SECAGANS) to the SM.
Figure 95 – Security agreement of RMAs
10.1.5 Access control for RMAs
The SM creates an access control list (ACL) containing hashed MAID and HASHED_AUTH for each authenticated
RMA in the current session. Figure 96 illustrates the ACL procedure. After the session has been opened to RMAs, a
DMA may request an ACL from the SM using an HRSREQ message encrypted by Ks. The SM responds with an
HRSANS message encypted by Ks which contains the ACL. A DMA may update its ACL information through the
periodic exchange of HRSREQ and HRSANS messages with the SM.
A DMA shall reject a request from an RMA to join the group if the ACL list does not contain the information for that
RMA.
Rec. ITU-T X.603.1 (2007)/Amd.1 (11/2009) 11
FINAL DRAFT / PROJET FINAL
---------------------- Page: 15 ----------------------
ISO/IEC 16512-2:2008/Amd.1:2011 (E)
Figure 96 – ACL management
10.2 MA operation
As main components of the secure RMCP-2 protocol, the SMA and the DMAs are responsible for secure tree
configuration and key management, as well as for group and member management and message encryption/decryption.
10.2.1 Key management for which the SMA and DMAs are responsible
10.2.1.1 Group key management
A group key (Kg) is shared be
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.