`
`INTERNATIONAL TELECOMMUNICATION UNION
`
`ITU-T
`
`TELECOMMUNICATION
`STANDARDIZATION SECTOR
`OF ITU
`
`H.235
`
`(02/98)
`
`SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS
`
`Infrastructure of audiovisual services — Systems aspects
`
`Security and encryption for H-Series
`(H.323 and other H.245-based) multimedia
`terminals
`
`ITU-T Recommendation H.235
`
`(Previously CCITT Recommendation)
`
`Petitioner Apple Inc. - Exhibit 1084, Cover
`
`Petitioner Apple Inc. - Exhibit 1084, Cover
`
`

`

`ITU—T H-SERIES RECOMMENDATIONS
`
`AUDIOVISUAL AND MULTIMEDIA SYSTEMS
`
`Characteristics of transmission channels used for other than telephone purposes
`
`H.10—H.19
`
`H.300—H.399
`
`Use of telephone—type circuits for voice-frequency telegraphy
`
`Telephone circuits or cables used for various types of telegraph transmission or
`simultaneous transmission
`'
`
`Telephone-type circuits used for facsimile telegraphy
`Characteristics of data signals
`CHARACTERISTICS OF VISUAL TELEPHONE SYSTEMS
`INFRASTRUCTURE OF AUDIOVISUAL SERVICES
`
`General
`
`Transmission multiplexing and ynchronization
`
`
`
`(Communication procedures
`Coding of moving video
`Related systems aspects
`Systems and terminal equipment for audiovisual services
`
`H.20—H.29
`
`H.30—H.39
`
`H.40—H.49
`H.50~H.99
`H.100—H.199
`
`H.200—H.219
`
`H 220 H.229
`
`H.240—:II.259
`H.260—H.279
`H.280—H.299
`
`Forfurther details, please refer to [TU—TList ofRecommendations.
`
`Petitioner Apple Inc. - Exhibit 1084, Cover 2
`
`Petitioner Apple Inc. - Exhibit 1084, Cover 2
`
`

`

`ITU-T RECOMMENDATION H.235
`
`SECURITY AND ENCRYPTION FOR H—SERIES
`
`(H.323 AND OTHER H.245-BASED)
`MULTIMEDIA TERMINALS
`
`Summary
`
`This Recommendation describes enhancements within the framework of the H.3xx-Series
`
`Recommendations to incorporate security services such as Authentication and Privacy (data
`encryption). The proposed scheme is applicable to both simple point—to-point and multipoint
`conferences for any terminals which utilize Recommendation H.245 as a control protocol.
`
`For example, H.323 systems operate over packet-based networks which do not provide a guaranteed
`quality of service. For the same technical reasons that the base network does not provide QOS, the
`network does not provide a secure service. Secure real-time communication over insecure networks
`generally involves two major areas of concern — authentication and privacy.
`
`This Recommendation describes the security infrastructure and specific privacy techniques to be
`employed by the H.3xx-Series of multimedia terminals. This Recommendation will cover areas of
`concern for
`interactive conferencing. These areas
`include, but are not strictly limited to,
`authentication and privacy of all real—time media streams that are exchanged in the conference. This
`Recommendation provides the protocol and algorithms needed between the H.323 entities.
`
`This Recommendation utilizes the general facilities supported in Recommendation H.245 and as
`such, any standard which operates in conjunction with this control protocol may use this security
`framework. It is expected that, wherever possible, other H-Series terminals may interoperate and
`directly utilize the methods described in this Recommendation. This Recommendation will not
`initially provide for complete implementation in all areas, and will specifically highlight endpoint
`authentication and media privacy.
`
`This Recommendation includes the ability to negotiate services and functionality in a generic
`manner, and to be selective concerning cryptographic techniques and capabilities utilized. The
`specific manner in which they are used relates to systems capabilities, application requirements and
`specific security policy constraints. This Recommendation supports varied cryptographic algorithms,
`with varied options appropriate for different purposes; e.g. key lengths. Certain cryptographic
`algorithms may be allocated to specific security services (e.g. one for fast media stream encryption
`and another for signalling encryption).
`
`It should also be noted that some of the available cryptographic algorithms or mechanisms may be
`reserved for export or other national issues (e.g. with restricted key lengths). This Recommendation
`supports
`signalling of well-known algorithms in addition to signalling non—standardized or
`proprietary cryptographic algorithms. There are no specifically mandated algorithms; however, it is
`strongly suggested that endpoints support as many of the applicable algorithms as possible in order to
`achieve interoperability. This parallels the concept that the support of Recommendation H.245 does
`not guarantee the interoperability between two entities‘ codecs.
`
`Source
`
`ITU-T Recommendation H.235 was prepared by ITU-T Study Group 16 (1997-2000) and was
`approved under the WTSC Resolution No. 1 procedure on the 6th February 1998.
`
`Petitioner Apple Inc. - Exhibit 1084, p. i
`
`Petitioner Apple Inc. - Exhibit 1084, p. i
`
`

`

`FOREWORD
`
`ITU (International Telecommunication Union) is the United Nations Specialized Agency in the field of
`telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of
`the ITU. The ITU-T is responsible for studying technical, operating and tariff questions and issuing
`Recommendations on them with a View to standardizing telecommunications on a worldwide basis.
`
`The World Telecommunication Standardization Conference (WTSC), which meets every four years,
`establishes the topics for study by the ITU-T Study Groups which, in their turn, produce Recommendations
`on these topics.
`
`The approval of Recommendations by the Members of the ITU—T is covered by the procedure laid down in
`WTSC Resolution No. 1.
`
`In some areas of information technology which fall within ITU-T’s purview, the necessary standards are
`prepared on a collaborative basis with ISO and IEC.
`
`the expression "Administration" is used for conciseness to indicate both a
`In this Recommendation,
`telecommunication administration and a recognized operating agency.
`
`NOTE
`
`INTELLECTUAL PROPERTY RIGHTS
`
`The ITU draws attention to the possibility that the practice or implementation of this Recommendation may
`involve the use of a claimed Intellectual Property Right. The ITU takes no position concerning the evidence,
`validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others
`outside of the Recommendation development process.
`
`As of the date of approval of this Recommendation, the ITU had not received notice of intellectual property,
`protected by patents, which may be required to implement this Recommendation. However, implementors are
`cautioned that this may not represent the latest information and are therefore strongly urged to consult the
`TSB patent database.
`
`All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means,
`electronic or mechanical, including photocopying and microfilm, without permission in writing from the ITU.
`
`© ITU 1998
`
`ii
`
`Recommendation H.235
`
`(02/98)
`
`Petitioner Apple Inc. - Exhibit 1084, p. ii
`
`Petitioner Apple Inc. - Exhibit 1084, p. ii
`
`

`

`CONTENTS
`
`Page
`
`Scope ..........................................................................................................................
`
`1
`
`Normative references..................................................................................................
`
`Definitions ..................................................................................................................
`
`Symbols and abbreviations .........................................................................................
`
`Conventions ................................................................................................................
`
`System introduction....................................................................................................
`
`Summary ....................................................................................................................
`
`Authentication ............................................................................................................
`
`6.2.1
`
`Certificates ....................................................................................................
`
`Call establishment security .........................................................................................
`
`Call control (H.245) security ......................................................................................
`
`Media stream privacy .................................................................................................
`
`Trusted elements .........................................................................................................
`
`6.6.1
`
`Key escrow ....................................................................................................
`
`Non-repudiation..........................................................................................................
`
`Connection establishment procedures ........................................................................
`
`7.1
`
`Introduction ................................................................................................................
`
`8.1
`
`8.2
`
`8.3
`
`8.4
`
`8.5
`
`9.1
`
`9.2
`
`10
`
`10.1
`
`10.2
`
`H.245 signalling and procedures ................................................................................
`
`Secure H.245 channel operation .................................................................................
`
`Unsecured H.245 channel operation...........................................................................
`
`Capability exchange ...................................................................................................
`
`Master role ..................................................................................................................
`
`Logical channel signalling..........................................................................................
`
`Multipoint procedures ................................................................................................
`
`Authentication ............................................................................................................
`
`Privacy ........................................................................................................................
`
`Authentication signalling and procedures ..................................................................
`
`Introduction ................................................................................................................
`
`Diffie—Hellman with optional authentication .............................................................
`
`\I\I\JO\O\C\O\UIUIUIJ>-I>UJN
`000000000000
`
`00
`
`00
`
`,_. 0
`
`+— O
`
`H 0
`
`H O
`
`Recommendation H.235
`
`(02/98)
`
`iii
`
`Petitioner Apple Inc. - Exhibit 1084, p. iii
`
`Petitioner Apple Inc. - Exhibit 1084, p. iii
`
`

`

`10.3
`
`Subscription—based authentication..............................................................................
`10.3.1
`Introduction ....................................................................................................
`
`10.3.2 Password with symmetric encryption ...........................................................
`
`10.3.3 Password with hashing ..................................................................................
`
`10.3.4 Certificate-based with signatures ..................................................................
`
`11
`
`Media stream encryption procedures..........................................................................
`
`11.1 Media session keys .....................................................................................................
`
`12
`
`Security error recovery ...............................................................................................
`
`Annex A — H.235 ASN.1 .........................................................................................................
`
`Annex B — H.323 specific topics .............................................................................................
`
`B. 1
`
`B.2
`
`B.3
`
`B.4
`
`Background ................................................................................................................
`
`Signalling and procedures ..........................................................................................
`
`B21 Revision 1 compatibility ...............................................................................
`
`RTP/RTCP issues .......................................................................................................
`
`RAS signalling/procedures for authentication............................................................
`B41
`Introduction ...................................................................................................
`
`B.4.2 Endpoint-gatekeeper authentication (non-subscription based) .....................
`
`B.4.3
`
`Endpoint-gatekeeper authentication (subscription-based) ............................
`
`B.5
`
`Non-terminal interactions ...........................................................................................
`
`B51 Gateway.........................................................................................................
`
`Annex C — H.324 specific topics .............................................................................................
`
`Appendix I — H.323 implementation details ............................................................................
`
`1.1
`
`1.2
`
`1.3
`
`1.4
`
`Ciphertext padding methods .......................................................................................
`
`New keys ....................................................................................................................
`
`H.323 trusted elements ...............................................................................................
`
`Implementation examples...........................................................................................
`I41
`Tokens ...........................................................................................................
`
`1.4.2
`
`1.4.3
`
`Password .......................................................................................................
`
`IPSEC ............................................................................................................
`
`Appendix II — H.324 implementation details ..........................................................................
`
`Appendix III — Other H-series implementation details............................................................
`
`Appendix IV — Bibliography ...................................................................................................
`
`Page
`
`11
`11
`
`11
`
`12
`
`12
`
`13
`
`15
`
`16
`
`16
`
`19
`
`19
`
`20
`
`21
`
`21
`
`22
`22
`
`22
`
`23
`
`25
`
`25
`
`25
`
`25
`
`25
`
`27
`
`27
`
`28
`28
`
`29
`
`30
`
`31
`
`31
`
`31
`
`iv
`
`Recommendation H.235
`
`(02/98)
`
`Petitioner Apple Inc. - Exhibit 1084, p. iv
`
`Petitioner Apple Inc. - Exhibit 1084, p. iv
`
`

`

`Recommendation H.235
`
`SECURITY AND ENCRYPTION FOR H—SERIES
`
`(H.323 AND OTHER H.245—BASED)
`MULTIMEDIA TERMINALS
`
`(Geneva, 1998)
`
`1
`
`Scope
`
`The primary purpose of this Recommendation is to provide for authentication, privacy, and integrity
`within the current H-Series protocol framework. The current text of this Recommendation (1998)
`provides details on implementation with Recommendation H.323. This framework is expected to
`operate in conjunction with other H—Series protocols that utilize Recommendation H.245 as their
`control protocol.
`
`Additional goals in this Recommendation include:
`
`1)
`
`2)
`
`3)
`
`4)
`
`5)
`
`6)
`
`7)
`
`Security architecture should be developed as an extensible and flexible framework for
`implementing a security system for H—Series terminals. This should be provided through
`flexible and independent services and the functionality that they supply. This includes the
`ability to negotiate and to be selective concerning cryptographic techniques utilized, and the
`manner in which they are used.
`
`Provide security for all communications occurring as a result of H.3xx protocol usage. This
`includes aspects of connection establishment, call control, and media exchange between all
`entities. This requirement includes the use of confidential communication (privacy), and may
`exploit functions for peer authentication as well as protection of the user’s environment from
`attacks.
`
`This Recommendation should not preclude integration of other security functions in H.3xx
`entities which may protect them against attacks from the network.
`
`This Recommendation should not limit the ability for any H.3xx-Series Recommendation to
`scale as appropriate. This may include both the number of secured users and the levels of
`security provided.
`
`Where appropriate, all mechanisms and facilities should be provided independent of any
`underlying transport or
`topologies. Other means that are outside the scope of this
`Recommendation may be required to counter such threats.
`
`Provisions are made for operation in a mixed environment (secured and unsecured entities).
`
`This Recommendation should provide facilities for distributing session keys associated with
`the cryptography utilized. (This does not imply that public-key—based certificate management
`must be part of this Recommendation.)
`
`The security architecture, described in this Recommendation, does not assume that the participants
`are familiar with each other. It does however assume that appropriate precautions have been taken to
`physically secure the H-Series endpoints. The principal security threat to communications, therefore,
`is assumed to be eavesdropping on the network or some other method of diverting media streams.
`
`Recommendation H.323 (1996) provides the means to conduct an audio, video and data conference
`between two or more parties, but does not provide the mechanism to allow each participant to
`authenticate the identity of the other participants, nor provide the means to make the communications
`private (i.e. encrypt the streams).
`
`Recommendation H.235
`
`(02/98)
`
`1
`
`Petitioner Apple Inc. - Exhibit 1084, p. l
`
`Petitioner Apple Inc. - Exhibit 1084, p. 1
`
`

`

`Recommendations H.323, H.324 and H.310 make use of the logical channel signalling procedures of
`Recommendation H.245, in which the content of each logical channel is described when the channel
`is opened. Procedures are provided for expression of receiver and transmitter capabilities,
`transmissions are limited to what receivers can decode, and receivers may request a particular desired
`mode from transmitters. The security capabilities of each endpoint are communicated in the same
`manner as any other communication capability.
`'
`
`Some H-Series (H.323) terminals may be used in multipoint configurations. The security mechanism
`described in this Recommendation will allow for secure operation in these environments, including
`both centralized and decentralized MCU operation.
`
`2
`
`Normative references
`
`The following ITU-T Recommendations and other references contain provisions which, through
`reference in this text, constitute provisions of this Recommendation. At the time of publication, the
`editions indicated were valid. All Recommendations and other references are subject to revision; all
`users of this Recommendation are therefore encouraged to investigate the possibility of applying the
`most recent edition of the Recommendations and other references listed below. A list of the currently
`valid ITU-T Recommendations is regularly published.
`
`—
`
`—
`
`-
`
`-
`
`—
`
`—
`
`—
`
`—
`
`—
`
`—
`
`—
`
`—
`
`ITU-T Recommendation H.225.0 (1998), Call signalling protocols and media stream
`packetization for packet—based multimedia communications systems.
`
`ITU-T Recommendation H.245 (1998), Control protocolfor multimedia communication.
`
`ITU-T Recommendation H.323 (1998), Packet—based multimedia communications systems.
`
`ITU-T Recommendation Q.931 (1993), ISBN user-network interface layer 3 specification
`for basic call control.
`
`ITU—T Recommendation X.509 (1997) | ISO/IEC 9594—8:1997, Information technology —
`Open Systems Interconnection — The Directory: Authentication framework.
`
`CCITT Recommendation X.800 (1991), Security Architecture for Open Systems
`Interconnection for CCITT applications.
`
`ISO 7498-2989, Information processing systems — Open Systems Interconnection — Basic
`Reference Model — Part 2: Security Architecture.
`
`ITU-T Recommendation X803 (1994) I ISO/IEC 10745: 1995, Information technology —
`Open Systems Interconnection ~ Upper layers security model.
`
`ITU-T Recommendation X.810 (1995) | ISO/IEC 10181-lzl996, Information technology —
`Open Systems Interconnection — Securityframeworks for open systems: Overview.
`
`ITU-T Recommendation X.811 (1995) | ISO/IEC 10181—221996, Information technology —
`Open Systems Interconnection — Security fiameworks for open systems: Authentication
`framework.
`
`ISO/IEC 9798—21994, Information technology — Security techniques — Entity authentication
`— Part 2: Mechanisms using symmetric encipherment algorithms.
`
`ISO/IEC 9798—3:1993, Information technology — Security techniques — Entity authentication
`mechanisms — Part 3 .' Entity authentication using a public key algorithm.
`
`ISO/IEC 9798-4:l995, Information technology — Security techniques — Entity authentication
`— Part 4: Mechanisms using a cryptographic checkfunction.
`
`2
`
`Recommendation H.235
`
`(02/98)
`
`Petitioner Apple Inc. - Exhibit 1084, p. 2
`
`Petitioner Apple Inc. - Exhibit 1084, p. 2
`
`

`

`—
`
`—
`
`3
`
`ATKINSON (R.): Security Architecture for the Internet Protocol, RFC 1825, Internet
`Engineering Task Force, 1995.
`
`KRAWCZYK (H.), BELLARE (M.), CANETTI (R): HMAC: Keyed—Hashing for Message
`Authentication, RFC 2104, Internet Engineering Task Force, 1997.
`
`Definitions
`
`For the purposes of this Recommendation the definitions given in clause 3 of Recommendations
`H.323, H.225.0 and H.245 apply along with those in this clause. Some of the following terms are
`used as defined in CCITT Rec. X.800 I ISO 7498—2 and in Recommendations X803, X810 and
`X811.
`
`access control: The prevention of unauthorized use of a resource, including the prevention
`3.1
`of use of a resource in an unauthorized manner (X.800).
`
`3.2
`
`3.3
`
`authentication: The provision of assurance of the claimed identity of an entity (X811).
`
`authorization: The granting of permission on the basis of authenticated identification.
`
`attack: The activities undertaken to bypass or exploit deficiencies in a system‘s security
`3.4
`mechanisms. By a direct attack on a system they exploit deficiencies in the underlying algorithms,
`principles, or properties of a security mechanism. Indirect attacks are performed when they bypass
`the mechanism, or when they make the system use the mechanism incorrectly.
`
`certificate: A set of security-relevant data issued by a security authority or trusted third
`3.5
`party, together with security information which is used to provide the integrity and data origin
`authentication services for the data (X810). In this Recommendation the term refers to "public key"
`certificates which are values that represent an owners public key (and other optional information) as
`verified and signed by a trusted authority in an unforgeable format.
`
`3.6
`
`cipher: A cryptographic algorithm, a mathematical transform.
`
`confidentiality: The property that prevents disclosure of information to unauthorized
`3.7
`individuals, entities, or processes.
`
`cryptographic algorithm: Mathematical function that computes a result from one or several
`3.8
`input values.
`
`encipherment: Encipherment (encryption) is the process of making data unreadable to
`3.9
`unauthorized entities by applying a cryptographic algorithm (an encryption algorithm). Decipherment
`(decryption) is the reverse operation by which the ciphertext is transformed to the plaintext.
`
`3.10
`
`integrity: The property that data has not been altered in an unauthorized manner.
`
`key management: The generation, storage, distribution, deletion, archiving and application
`3.11
`of keys in accordance with a security policy (X.800).
`
`media stream: A media stream can be of type audio, video or data or a combination of any
`3.12
`of them. Media stream data conveys user or application data (payload) but no control data.
`
`nonrepudiation: Protection from denial by one of the entities involved in a communication
`3.13
`of having participated in all or part of the communication.
`
`privacy: A mode of communication in which only the explicitly enabled parties can interpret
`3.14
`the communication. This is typically achieved by encryption and shared key(s) for the cipher.
`
`Recommendation H.235
`
`(02/98)
`
`3
`
`Petitioner Apple Inc. - Exhibit 1084, p. 3
`
`Petitioner Apple Inc. - Exhibit 1084, p. 3
`
`

`

`private channel: For this Recommendation, a private channel is one that is a result of prior
`3.15
`negotiation on a secure channel. In this context it may be used to handle media streams.
`
`(for
`public key cryptography: An encryption system utilizing asymmetric keys
`3.16
`encryption/decryption) in which the keys have a mathematical relationship to each other — which
`cannot be reasonably calculated.
`
`symmetric (secret—key based) cryptographic algorithm: An algorithm for performing
`3.17
`encipherrnent or the corresponding algorithm for performing decipherment in which the same key is
`required for both encipherment and decipherment (X.810).
`
`3.18
`
`threat: A potential violation of security (X800).
`
`4
`
`Symbols and abbreviations
`
`This Recommendation uses the following abbreviations:
`
`DSS
`
`Digital Signature Standard
`
`IPSEC
`
`Internet Protocol Security
`
`QOS
`
`RSA
`SDU
`
`TLS
`
`Quality of Service
`
`Rivest, Shamir and Adleman (public key algorithm)
`Service Data Unit
`
`Transport Level Security
`
`5
`
`Conventions
`
`In this Recommendation the following conventions are used:
`
`—
`
`—
`
`—
`
`"Shall" indicates a mandatory requirement.
`
`"Should" indicates a suggested but optional course of action.
`
`"May" indicates an optional course of action rather than a recommendation that something
`take place.
`
`References to clauses, subclauses, annexes and appendices refer to those items within this
`Recommendation unless another Recommendation is explicitly listed. For example, "1.4" refers to
`subclause 1.4 of this Recommendation; "6.4/H.245" refers to subclause 6.4 in Recommendation
`H.245.
`
`This Recommendation describes the use of "n" different message types: H.245, RAS, Q.931, etc. To
`distinguish between the different message types,
`the following convention is followed. H.245
`message and parameter names consist of multiple concatenated words highlighted in bold typeface
`(maximumDelayJitter). RAS message names are represented by three-letter abbreviations (ARQ).
`Q.931 message names
`consist of one or
`two words with the
`first
`letters
`capitalized
`(Call Proceeding).
`
`4
`
`Recommendation H.235
`
`(02/98)
`
`Petitioner Apple Inc. - Exhibit 1084, p. 4
`
`Petitioner Apple Inc. - Exhibit 1084, p. 4
`
`

`

`6
`
`System introduction
`
`6.1
`
`1)
`
`2)
`
`3)
`
`4)
`
`5)
`
`6)
`
`7)
`
`Summary
`
`The call signalling channel may be secured using TLS [TLS] or IPSEC [13/IPSEC] on a
`secure well—known port (H2250).
`
`in the process of
`Users may be authenticated either during the initial callconnection,
`securing the H.245 channel and/or by exchanging certificates on the H.245 channel.
`
`The encryption capabilities of a media channel are determined by extensions to the existing
`capability negotiation mechanism.
`
`Initial distribution of key material from the master is via H.245 OpenLogicalChannel or
`OpenLogicalChannelAck messages.
`
`Re-keying may be accomplished by H.245 commands: EncryptionUpdateRequest and
`EncryptionUpdate.
`
`Key material distribution is protected either by operating the H.245 channel as a private
`channel or by specifically protecting the key material using the selected exchanged
`certificates.
`
`The security protocols presented either conform to ISO published standards or IETF
`proposed standards.
`
`6.2
`
`Authentication
`
`The process of authentication verifies that the respondents are, in fact, who they say they are.
`Authentication may be accomplished in conjunction with the exchange of public key based
`certificates. Authentication may also be accomplished by an exchange which utilizes a shared secret
`between the entities involved. This may be a static password or some other a priori piece of
`information.
`
`This Recommendation describes the protocol for exchanging the certificates, but does not specify the
`criteria by which they are mutually verified and accepted. In general, certificates give some assurance
`to the verifier that the presenter of the certificate is who he says he is. The intent behind the
`certificate exchange is to authenticate the user of the endpoint, not simply the physical endpoint.
`Using digital certificates, an authentication protocol proves that the respondents possess the private
`keys corresponding to the public keys contained in the certificates. This authentication protects
`against man—in-the—middle attacks, but does not automatically prove who the respondents are. To do
`this normally requires that there be some policy regarding the other contents of the certificates. For
`authorization certificates, for example, the certificate would normally contain the service-provider’s
`identification along with some form of user account identification prescribed by the service provider.
`
`The authentication framework in this Recommendation does not prescribe the contents of certificates
`(i.e. does not specify a certificate policy) beyond that required by the authentication protocol.
`However, an application using this framework may impose high-level policy requirements such as
`presenting the certificate to the user for approval. This higher level policy may either be automated
`within the application or require human interaction.
`
`For authentication which does not utilize digital certificates, this Recommendation provides the
`signalling to complete various challenge/response scenarios. This method of authentication requires
`prior coordination by the communicating entities so that a shared secret may be obtained. An
`example of this method would be a customer of a subscription—based service.
`
`As a third option, the authentication may be completed within the context of a separate security
`protocol such as TLS [TLS] or IPSEC [lS/IPSEC].
`
`Recommendation H.235
`
`(02/98)
`
`5
`
`Petitioner Apple Inc. - Exhibit 1084, p. 5
`
`Petitioner Apple Inc. - Exhibit 1084, p. 5
`
`

`

`Both bidirectional and unidirectional authentication may be supported by peer entities. This
`authentication may occur on some or all of the communication channels.
`
`All of the specific authentication mechanisms described in this Recommendation are identical to, or
`derived from, ISO developed algorithms as specified in Parts 2 to 3 of ISO/IEC 9798, or based on
`IETF protocols.
`
`6.2.1
`
`Certificates
`
`including their generation, administration and distribution is
`The standardization of certificates,
`outside the scope of this Recommendation. The certificates used to establish secure channels (call
`signalling and/or call control) shall conform to those prescribed by whichever protocol has been
`negotiated to secure the channel.
`
`It should be noted that for authentication utilizing public key certificates, the endpoints are required
`to provide digital signatures using the associated private key value. The exchange of public key
`certificates alone does not protect against man-in-the-middle attacks. The H.235 protocols conform
`to this requirement.
`
`6.3
`
`Call establishment security
`
`There are at least two reasons to motivate securing the call establishment channel (e.g. H.323 using
`Q.931). The first is for simple authentication, before accepting the call. The second reason is to allow
`for call authorization. If this functionality is desired in the H-Series terminal, a secure mode of
`communication should be used (such as TLS/IPSEC for H.323) before the exchange of call
`connection messages. Alternatively, the authorization may be provided based upon a service-specific
`authentication. The constraints of a service-specific authorization policy are outside the scope of this
`Recommendation.
`
`6.4
`
`Call control (H.245) security
`
`The call control channel (H.245) should also be secured in some manner to provide for subsequent
`media privacy. The H.245 channel shall be secured using any negotiated privacy mechanism (this
`includes the Option of "none"). H.245 messages are utilized to signal encryption algorithms and
`encryption keys used in the shared, private, media channels. The ability to do this, on a logical
`channel by logical channel basis, allows different media channels to be encrypted by different
`mechanisms. For example, in centralized multipoint conferences, different keys may be used for
`streams to each endpoint. This may allow media streams to be made private for each endpoint in the
`conference. In order to utilize the H.245 messages in a secure manner, the entire H.245 channel
`(logical channel 0) should be opened in a negotiated secur