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