*Authn/z Conference Call*
2-July-2002

*Attendees*
Steve Olshansky -- Internet2
Tom Barton -- U. Memphis
Samir Chatterjee -- CGU
Jill Gemmill -- UAB
Doug Sicker - U. Colorado - Boulder
Ameet Kulkarni, Anand Chavali, Kim Norton, and Mudassir Fajandar, U.
Colorado - Boulder
Ken Klingenstein, Internet2
Jeanette Fielden - Internet2
Nate Klingenstein - Internet2
Ann West, Internet2/Educause
Bob Morgan, U. Washington

*Discussion*

Samir provided an update on the video client development. The client works but the quality of the video in the client still needs refinement. There is a setup delay of up to15 seconds and the frames per second varies from 5-15.
Doug’s client is functional as well. The client is SIP enabled, with H.323 and gateway functionality. Currently big setup delays have not occurred.

There was a meeting yesterday to discuss the VC flow diagrams and how to tie together signaling and Authn/z. The discussion also covered issues of how best make use of passing information between the two with the goal of rewriting as little code as possible.

There are two areas of concern with a web-based environment: 1. How to pass parameters in video clients? Will it happen on the client side or between the servers associated with the client? 2. What are the security implications using a web based approach with Shibboleth? Are there avenues for DoS attacks by those coming directly to the port?

There was a discussion of open ports and possible vulnerabilities. The consensus was that some ports must be open, others are assigned dynamically after a call setup and if the underlying protocols have vulnerabilities it may not be possible to fix them but it may be possible to add another layer of control to guard against unauthorized connections. In SIP and H.323 clients can be made to only respond to requests coming through a SIP proxy or an MCU. The client can be locked down to only a single entry point. If the entry port is secured then the client is secured. Denial of service issues in doing this as a web-based application does not appear to increase risk.

Another issue is should unauthorized calls to get to the target? Should the target never be connected or should the user have control over that decision. The best solution would be to have the option to work in secured or unsecured mode. A variety of proxy’s and policies may have to be implemented to meet a given organizations needs.

* Flow Diagrams Discussion*
Are the flows going between points that know how to originate and receive the flows? Are there sufficient identifiers in the flow so it can be redirected to where it needs to go, such as a web client?
The 4 SIP diagrams represent two models with two variations.
1. Attribute authentication authority in initial phase, with a connection intercept and without a connection intercept. 2. Attribute authentication authority in middle of the flow, with a connection intercept and without a connection intercept.

The H.323 diagram shows an attribute authentication authority and a connection intercept.

Call Flow shibea1u1
Steps 1 and 2: Single sign-on, browser based authentication at a web ISO, cookie is deposited the Shibboleth client. Steps 3 - 5 are trying to populate information into video directories. It needs to be defined what attributes are concerned and how should they be populated. Steps 6-7 are where registration occurs against a SIP proxy and registrar. Where does authentication occur? It needs to be resolved where this will happen and what process and information is involved. In steps 8 and 9 the SHIB SHIRE intercepts the invitation. Another option would be: the proxy gets the invite at step 9, stops the process, runs through the rest of the steps and then passes the unadulterated invite to the client. The consensus was this would be the preferred approach. The issue was raised that between the steps 6/7 registration and the steps 8/9 invite there could be a big gap of time between steps 7 and 8. If this is kept unchallenged, how will it be authenticated? Step 10: A push cannot be made into the browser. The precise location of the browser is not known since the proxy has been handling things. What kind of information is being carried to 8 and can it be enhanced for steps 9 and beyond?
A conference call will be set up to continue refining the diagrams.