Federated secure internet conferencing thread
1 / 20

Federated Secure Internet Conferencing Thread - PowerPoint PPT Presentation

  • Uploaded on

Federated Secure Internet Conferencing Thread Work In Progress Year 1 Q1 Year 1 Q2 Year 1 Q3 Year 1 Q4 Year 2 Q1 Year 2 Q2 Year 2 Q3 Year 2 Q4 Federated Secure Internet Conferencing Thread Project Timeline Use Case Creation Use Cases Standardized in SDOs Requirements

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Federated Secure Internet Conferencing Thread' - ostinmannual

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Work plan l.jpg

Year 1


Year 1


Year 1


Year 1


Year 2


Year 2


Year 2


Year 2


Federated Secure Internet Conferencing Thread Project Timeline

Use Case


Use Cases Standardized in SDOs



Requirements Standardized in SDOs

Campus Bid Package

Secure Conferencing Forum

Secure Conferencing Outreach

Work Plan

Scenario 1 free and unfettered access to multiple service providers l.jpg
Scenario 1. Free and Unfettered Access to Multiple Service Providers

  • A conferencing service provider operates an advanced multipoint conferencing gateway that allows customers to conduct high quality video conference calls while sharing computer presentations. The service provider has standing contracts with several universities to allow access to any user in those universities. The service provider also has contracts with other universities whose contracts stipulate that only faculty and staff, but not students, have access to the service. In addition, the service provider allows anyone on the Internet to access its service even if it does not have a pre-existing account or contract, provided the caller includes a credit card number when making the call. The service provider only provides conferencing services. It does not provide call server, signaling or directory services; it is assumed that customers already have access to these services through their home institution or some other commercial provider.

Scenario 2 user identification across multiple networks l.jpg
Scenario 2. User Identification Across Multiple Networks Providers

  • A worker is involved in a demanding project and cannot be interrupted, but is expecting an important call from a customer at another company. The worker uses an H.323 video device, but the customer uses SIP IP telephones. The worker receives a call and before answering sees that the call is 1) from an individual in the expected company, 2) the name and email address of the customer, and 3) that the customer’s identity is vouched for by both the company itself and a large, well known public certificate authority. The work decides to accept the call. Later in the day, the customer calls again, but this time from a cell phone. The same identification information appears and the call is accepted.

Scenario 3 multipoint authentication with guest access l.jpg
Scenario 3. Multipoint Authentication with Guest Access Providers

  • A project team manager is hosting a conference call. The manager views a web interface to the conference bridge. As team members dial into the conference bridge, their credentials appear on the manager’s screen. He approves all but one of the calls, which appears to be from an unauthorized source. Later in the call, one of the team members is asked to bring a guest speaker into the call. The guest dials into the call, and the moderator sees that the guest’s credentials match the person identified by the team member, so the guest is allowed into the call.

Scenario 4 no access to advanced middleware l.jpg
Scenario 4. No Access to Advanced Middleware Providers

  • A local elementary school initiates a program with a local farmer to have a video conference every week in which the students discuss what is happening at the farm a the particular time of year. The farmer agrees and both he and the school go the local electronics store and purchase a consumer grade video conferencing appliance. The first time the farmer calls the school, his identity appears on the screen, but indicates no other authority vouches for him. Privacy is very important at the school, so the teacher answers the call privately. When she sees that it is indeed the farmer, she presses a ‘SAVE FAVORITES’ button on her appliance so that the next time the farmer calls his call come straight through.

Scenario 5 limited bandwidth processing and memory l.jpg
Scenario 5. Limited bandwidth, Processing and Memory Providers

  • The trustees of a major corporation are meeting in the corporate board room at the company’s headquarters. The board room is outfitted with the latest high end secure conferencing equipment. One of the trustees is not present because of a travel schedule conflict, but is available to dial into the conference using his PDA from the airport’s public wireless Internet. He calls into the board room, his credentials are displayed there, and the call is accepted.

Design goals l.jpg
Design Goals Providers

End to end security l.jpg
End to end security Providers

  • The architecture must support the ability of an entity (e.g. a caller) to identify itself to the final destination (e.g. the called party) and any network entity along the path (such as a call server or gateway).

Support federated trust models l.jpg
Support federated trust models Providers

  • The architecture must be able to recognize and react to the existence of other institutions within its federation, as well as institutions in other federations.

Globally scalable l.jpg
Globally scalable Providers

  • It is not sufficient that the architecture scales very high. It must be capable of scaling globally. This implies that many complex and autonomous networks, users, domains and federations exist without any a priori knowledge of one another, and can react to one another in meaningful ways. It is not sufficient to require an overarching administrative or technical infrastructure.

Support for privacy l.jpg
Support for privacy Providers

  • The architecture must be capable of securely exchanging encryption keys and passing them to the underlying conferencing protocols for encryption of media streams and call signaling messages. It is not the responsibility of the federated architecture to perform the actual encryption.

Minimal impact on conferencing protocol l.jpg
Minimal impact on conferencing protocol Providers

  • The architecture should be able to be implemented with minimal changes to an existing protocol. Ideally, a simple protocol extension should be all that is required to support the federated approach. This will be an aid to acceptance in the marketplace. This requirement suggests the importance of decoupling the security mechanism from the endpoint itself. This allows for the creation of robust security mechanism independent of endpoint constraints. Thus, the security mechanisms are free to implement the federated architecture of their choice, and the task then becomes on of ‘associating’ an authentication event with a particular conferencing event.

Ability to span multiple protocols l.jpg
Ability to span multiple protocols Providers

  • The architecture must fully support authentication and key exchanges across multiple protocols and gateways, an area that has been problematic with existing approaches. The decoupling notion described above will be an aid in accomplishing this goal.

Scalable from individual users to large service provider networks l.jpg
Scalable from individual users to large service provider networks

  • The architecture should scale in such a way that large service providers can utilize extensive middleware servers, attribute authorities, directory servers and other infrastructure necessary to administer very large and secure services. At the same time, the architecture should not prevent the very simplest of applications, in which an individual user can make a secure call to another individual user, with no access to advanced middleware and without benefit of a service provider. This requirement is essential to ensure broad deployment.

Low latency l.jpg
Low latency networks

  • The architecture should not introduce unacceptable delays into the call setup or call signaling process.

Adjustable confidence levels l.jpg
Adjustable confidence levels networks

  • The architecture should allow for varying security requirements. For example, a call to hotel concierge may require a very low level of security, while a call involving military secrets may involve an extremely high degree of security. The architecture should allow for these varying requirements without system reconfiguration.

Support flexible ui approaches for credential management and authorization l.jpg
Support flexible UI approaches for credential management and authorization

  • The architecture should not dictate a particular user interface and should support multiple methods of credential management. For example, it should be open to locally stored credentials, credentials stored on a smart card or smart device, credentials stored on the network such as in an H.350 directory, or even biometric interfaces including retinal scans and voice recognition.

Working model l.jpg

Authentication Service Realm 4 authorization

Authentication Service Realm 2

Authentication Service Realm 1

Authentication Service Realm 3

Authorization Service

Authorization Service

Authorization Service

Call Signaling


Remote Security Channel

Local Security Channel

Authentication Service

Working Model














Agent 1


Agent 2

SIP Realm

VC Endpoint 1

VC Endpoint 2


H.323 Realm

Call flow l.jpg
Call Flow authorization