Federated Secure Internet Conferencing (FSIC) General Requirements

Draft submitted to ITU-T Study Group 16


Abstract
The purpose of this contribution is to solidify the goals and general requirements for a Federated Secure Internet Conferencing (FSIC) architecture for multimedia conferencing and voice over IP. FSIC has been discussed several times at Study Group 16 meetings and rapporteur meetings with some level of technical depth. A result of these discussions is that a clear and simple articulation of the general requirements is in order before the technical work can be progressed.

The overarching goal of H.FSIC is to create a federation-aware, protocol neutral, end to end authentication framework for multimedia conferencing and voice over IP.

Federations are groups of autonomous domains (e.g. networks) that agree to a common set of operating principles in order to support business relationships between them. For example, a group of hospitals may agree to grant access to network resources to individuals from other hospitals in the group (i.e. the federation), trusting that the other hospitals manage their own users in an acceptable manner. Individual users on carrier-provided networks may need to access a doctor from one of the hospitals in the federation, and make an informed decision as to whether to trust that the individual they are communicating with is in fact who they claim to be, and that their communications are private.

Challenges In The Environment
The following challenges are examples of obstacles to the widespread deployment of secure conferencing.

  1. The environment is multi-realm. The developing interest in multimedia conferencing and voice over IP is one in which enterprises, carriers and individuals need to be able to interface with each other over the IP network. Each enterprise, carrier or individual generally represents at least one administrative domain, or realm. Therefore, the global multimedia conferencing and voice over IP network must span these realms securely.
  2. Enterprises use different authentication schemes. Most of the current authentication mechanisms for multimedia conferencing require that all elements in a network use a common authentication mechanism. Since enterprises use different authentication mechanisms, inter-realm authentication is thus rendered difficult or impossible. It is not realistic to think that all enterprises will adopt the same authentication strategy.
  3. Multiple conferencing protocols are in use. Current authentication approaches work within protocols. For example, H.235 provides authentication services for H-series terminals. SIP provides several authentication approaches. Calls may travel over many different networks using many different protocols. This multi-protocol environment must still be secure.
  4. End to end authentication is desired by users. Most of the deployed authentication methods use end-to-middle authentication, in which endpoints authenticate to a central server. This provides assurance to the service provider that its resources are not being misused, but it does not provide the end users with information by which they can be assured of the identity of the calling parties.
  5. Privacy is desirable. Many applications require the encryption of call signalling and media.
  6. Authorization is important, but very complex. The ability for a user or system to determine what resources are appropriately available to a given individual or entity is important in providing services. However, the vocabulary and meaning of authorization is generally highly tailored to specific environments and applications. It does not lend itself well to a standardized vocabulary.
  7. Complexity varies. Some environments, such as carriers and large enterprises, have access to complex middleware infrastructure, such as certificate authorities and authorization servers. These institutions can make use of complex authentication schemes. Some environments, such as home networks and schools, have access to virtually no middleware infrastructures. Yet all of these environments need to be able to securely share data and authenticate users.



Requirements
The following are architectural requirements of H.FSIC.

  1. End to End Authentication. H.FISC must support the ability of an individual user to verify the identity of a calling party and make an informed decision as to the veracity of the asserted identity.
  2. Supports federated approaches to security. Federations are groups of administrative domains that agree to a common set of operating principles. These federations form trust fabrics that are useful to individuals and institutions. The FSIC architecture must be able to operate within multiple federated environments.
  3. Does not require a homogenous authentication method. The FSIC architecture must not require that all realms use the same authentication method, but should instead allow realms to use existing authentication infrastructure. However, the architecture should allow realms to make assertions about their authentication process, so that call recipients can make informed decisions about the degree of trust to afford the remote party. This implies a degree of extensibility inherent in the architecture.
  4. Protocol Independence. The FSIC architecture should work outside of protocols (H.323, SIP, etc.) so that security is not lost at the protocol gateway boundary. Of course, this implies that some method is necessary to associate particular call flows with authenticated network elements. So, some level of support for FSIC will likely need to be included within a protocol, but its impact should be minimal.
  5. Authorization. H.FSIC is not an authorization framework, but it must support the ability to communicate with an authorization service.
  6. Support for encryption. The architecture, while not responsible directly for encryption, should support key exchange or a similar method by which end to end encryption data can be exchanged.
  7. Easy to implement. One of the barriers to widespread deployment of existing security models is the complexity of infrastructure required to support it. H.FSIC should be implementable without complex middeware infrastructure, though it should leverage that infrastructure if it is available.



General Work Goals
H.FSIC has two primary dimensions. The first is the creation of the architecture itself. The second is building support for that architecture into existing protocols.

A Federated Architecture for Secure Internet Conferencing
H.FSIC will produce a complete architecture describing a federated approach to secure Internet conferencing. This will be in the form of an ITU-T Recommendation. A goal is to have a draft technical architecture available for review at the Spring 2005 SG meeting.

Pursuit of Protocol Specific Standards
Assuming that the federated architecture is ratified as a standard, then various protocol specific implementations will be pursued. For example, an extension to H.323 will be pursued through the ITU-T to support the new architecture (most likely through H.235). Further, an extension to SIP will be pursued through the IETF to support the new architecture in that protocol.

Related Efforts and Work In Progress


Conclusion
The editor requests that these requirements and work plans be approved by the Study Group in order to further the efforts in H.FSIC for the next Study Group meeting.
__________________