*VidMid-VC-AuthN/Z Conference Call*
April 9, 2002

*Participants*

Ken Klingenstein - Colorado/Internet2 (chair)
Samir Chatterjee - Claremont Graduate U.
Nadim El-Khoury - UNC-CH
Renee Frost - Internet2
Michael Gettes - Georgetown
Pierre Hagendorf - RADVISION
Lisa Hogeboom - Internet2
Steve Olshansky - Internet2
Ron Tipton - U. Tennessee, Knoxville
Nate Klingenstein - Internet2 (scribe)

*Discussion*

- Videoconferencing's State -

The first agenda item of the call was to call upon Pierre's implementation experience acquired as system architect of product development at RADVISION. In this position, he is responsible for technological issues regarding videoconferencing, especially with respect to future developments and evolution of RADVISION products. Ken asked him a wide variety of questions to better understand the thoughts and goals of the implementers.

Pierre's opinion is that the VidMid group is relatively advanced as compared to the standards bodies working on similar problems of authentication and authorization. He also noted that the focus of the marketplace was significantly weighted towards encryption technologies rather than authentication. The general fears of the corporate world in adopting online communication of critical discussions are primarily of eavesdroppers or man-in-the-middle snoopers rather than the attack or usage scenarios that authentication and authorization are intended to address in current implementations. Pierre foresaw that as IP grows more and more predominant as the backbone for intra-enterprise communications, authentication will become a much more significant issue.

As of today, significant authentication implementation is not widely done. Improvements are intended to be made in the near future, with several drafts having been developed by the IETF SIP working group. Pierre was familiar with several of those drafts, but hasn't tracked them lately. SAML will most likely need to have bindings to H.323 and SIP written and standardized before SAML will be of significant use to the group; one alternative to this is to add web front-ends to most video flows, utilizing the current HTTP bindings of SAML and access control schemes built around it.

Given that the group is proposing significant additional recommendations to go alongside existing video standards, there is a need to be careful that anything designed is compatible with existing standards or with the marketplace's desires, or it will be difficult to move anything the group proposes to implementation. This must be considered in terms of trust models, call flows, device requirements, etc.

- SIP Scenarios -

Samir created a draft set of scenarios/diagrams to allow the group to begin reviewing how authn/z can be built into SIP's call flows and infrastructure. The group initially reviewed the three of the four scenarios that had been written to detail the intra-realm usage cases before proceeding to the more difficult extra-realm trust issues, including a brief discussion of inter-realm scenario 4. [AI] Samir offered to revise the scenarios document and recirculate it to the list.

Scenario 1:
The idea of providing some form of single sign-on (SSO) within the origin domain for use with SIP authentication is introduced here in the form of a registrar server. The intent would be to craft the registration command such that it would automatically present some form of credential sufficient for the device's authentication. Pierre could only speak for H.235 implementation, which would recommend using some sort of Kerberos ticket, certificate, or other signature; the group was unsure whether a specific credential is necessary for SIP's standards. The flows presume that the client already has the means for authentication provided and ready to present at the time the request is made.

Reiterating the middleware theme that heavyweight authentication should be performed in a limited volume, creation of a lighter credential out of the authentication process which could then be used as a token to prove the authentication was suggested. This leads to the necessity to add a flow in 1.2 between the SIP proxy and the authentication server to validate the token created by the login server when the user initially authenticated.

This is directly analogous to certificate validation and CRL checking in PKI and verification of the signature on the XML package in SAML. However, use of a token like this instead of repeated re-authentication for each new call opens the flows to a variety of new attacks, including man-in-the-middle challenges. Limiting the lifetime of the assertion or use of serialized assertions can help to mitigate part of the problem, but these safeguards would be very difficult to implement in the SIP flows. The group noted as an outstanding issue the need to strike a balance between overhead and security, and more particularly this individual choice.

Scenario 2:
This scenario is similar to Scenario 1, except that the videoconferencing device is presumed to be in a generally accessible lab. No SSO system is assumed to be present, and the token is hardwired into the device. A weakness in this setup noticed by the group is that in the case where a student would want to be able to authenticate further to a public device to gain additional access to SIP calling permissions, this is virtually impossible using current hardware without a flow between the login server and client of some form. Most kiosk-style implementations of web and email servers typically perform a basic authentication to an SSO system at bootup and allow for further, brief authentication as an individual user to the SSO system. The group needs to understand whether to design the ability for challenge/response interactions into flows based on necessities for ease of use and client limitations.

Scenario 3:
Scenario 3 addresses the use case in which a group of users in one room are associated with a single device, such as having one wide camera for a conference room. There are questions here about authentication of the individuals in the room -- precisely which individuals are authenticated, whether all must authenticate or only at least one trusted, or whether no authentication of the users should be performed -- and of the device itself. Several mechanisms could be hard coded into the device to allow for it to authenticate itself, including use of many of the static tickets mentioned in previous sections as well as IP address. IP address spoofing is not a concern in terms of false authentication or session hijacking because in the flows the enterprise security service must send authorization back to the appropriate IP address, circumventing most spoofing attacks. Some spoofing attacks may still present DoS issues, but this seems extremely unlikely to be a problem.

Interrealm scenario 4:
Significantly the most challenging of these four scenarios, scenario 4 requires the authorization of a user from another security domain for use of videoconferencing resources in the local security domain. This will likely be performed by use of proxy-to-proxy communication, and will dovetail into the other interrealm scenarios and use a similar infrastructure.

*Action Items*

1. [AI] 9-Apr-02 Samir offered to revise the scenarios document and recirculate it to the list.