Federated Secure Internet Conferencing Thread

1. Federated Secure Internet Conferencing Thread Work In Progress

2. 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 Creation Requirements Standardized in SDOs Campus Bid Package Secure Conferencing Forum Secure Conferencing Outreach Work Plan

3. 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.

4. Scenario 2. User Identification Across Multiple Networks • 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.

5. Scenario 3. Multipoint Authentication with Guest Access • 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.

6. Scenario 4. No Access to Advanced Middleware • 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.

7. Scenario 5. Limited bandwidth, Processing and Memory • 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.

8. Design Goals

9. End to end security • 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).

10. Support federated trust models • 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.

11. Globally scalable • 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.

12. Support for privacy • 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.

13. Minimal impact on conferencing protocol • 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.

14. Ability to span multiple protocols • 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.

15. 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.

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

17. Adjustable confidence levels • 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.

18. 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.

19. Authentication Service Realm 4 Authentication Service Realm 2 Authentication Service Realm 1 Authentication Service Realm 3 Authorization Service Authorization Service Authorization Service Call Signaling Media Remote Security Channel Local Security Channel Authentication Service Working Model 5678 Credential Authority ABC Credential Authority XYZ Credential Authority FEDERATION B FEDERATION A Internet Security Agent 1 Security Agent 2 SIP Realm VC Endpoint 1 VC Endpoint 2 Gateway H.323 Realm

20. Call Flow NAT Problem