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

*Participants*

Ken Klingenstein -- Colorado/Internet2(chair)
Tom Barton -- Memphis
Samir Chatterjee -- Claremont
Nadim El-Khoury -- UNC
Michael Gettes -- Georgetown
Karen Krivaa -- RADVISION
Doug Sicker -- Colorado
Ron Tipton -- Tennessee
Ann West -- MTU
Nate Klingenstein -- Internet2(scribe)

*Discussion*

The group reaffirmed its desire to capture the analytic technique used by SAML in its development of flows for interrealm security communications, but will generate a different diagram using the same process to reflect the different pieces in the H.323 and SIP spaces. The SAML diagram is very simplistic in terms of which components perform which functions, but analyzes well which flows precede which flows and how processes interact through an axis of time. This follows what may be called the classic analytic technology for looking at authn/z.

(Mainly) H.323 Flows & Attacks

Ken termed it a "federated analysis" because the document doesn't discuss which component performs what; instead, it discusses only what needs to happen in each domain. This leaves it to implementations to perform the set of functionality necessary in the way which best suits the situation. In H.323, the group will need to understand authentication to MCU's and authentication by MCU's to develop these flows; in the SIP case, a proxy communicating with a remote SIP proxy, or a user-agent to a remote proxy.

In discussion of what needs to be considered about H.323 flows, Ken brought up the idea of MCU's as somewhat different than other endpoints. Several members of the group strongly disagreed, reasoning that for flows, MCU's are treated the same as other endpoints. Ken pointed out that MCU's are susceptible, however, to certain flow-based attacks which other endpoints are not. Denial-of-service attacks can take place on an MCU, and the end result of such an attack is far more devastating because everyone dialing into the MCU is affected. Eavesdropping is another problem that manifests itself at the MCU which would not affect normal endpoints so severely. Given that it is just a box sitting on the network, it is vulnerable to similar attacks as other servers can be. Most of these concerns might be more appropriately addressed at the gatekeeper too. The group thought it might be good to deal with the DoS challenges later, since for current purposes those problems can be considered out of scope.

Another architectural consideration for H.323 flows is whether the group can assume that there will be a gatekeeper involved in all call setup. It would be theoretically possible to go directly from point to point in bilateral H.323 calls, which is a realm which has not yet seen much in the way of authn/z discussion. In terms of real-world fauna, the majority of applications at UNC are performed using a gatekeeper. Nadim was in favor of always assuming the existence of the gatekeeper both to simplify the problem and to add a more intelligent component capable of handling much of the authn/z burden eventually.

A further possibility for H.323 communications mentioned by the group was some use of the ILS location technologies. In typical implementations currently, this contacts a proprietary LDAP directory, which isn't necessarily too useful. However, if there were an OpenLDAP server in the source domain providing some ILS role to the H.323 endpoints on the campus, this could be useful, avoiding the commercial ILS services on the net currently.

A technique currently being developed by the MACE-Dir working group known as affiliated directories may eventually help this problem, allowing directories to propagate information intelligently to directories in other realms, thereby possibly linking together ILS directories in a manner similar to DNS' federation. Ken mentioned that Microsoft will be introducing a proprietary, hard-coded federation server later this summer, but that this was something for the group to keep its eyes on. Discussion followed fleshing out some of the details of the potential diagrams in an experimental way which will be captured in the documents generated by the teams working on each call flow. Michael suggested the idea of allowing for multiple H.323 gatekeepers, which would imply a zone with a number of gatekeepers and terminals within it. A terminal would then choose the proper gatekeeper, ideally authenticating somehow in the same manner to the variety of zones using a single username and password.

This almost suggests externalizing the process of authentication to somewhere else in the domain much like Kerberos does, creating a credential with an initial authentication which is then verified by the server with the login authority of the domain. He couldn't envision a scenario where there would be direct authentication of an endpoint to a gatekeeper outside of the local security domain, but an indirect Shibboleth-like scenario was possible. H.235 does recommend the ability to pass authentication information across domains. The alternative design choice would be to assume that for each endpoint there is a single gatekeeper.

Next Steps

The group wanted to develop a diagram similar to the aforementioned SAML diagrams for each of the H.323 and SIP call flows.

[AI] Samir and Doug Sicker of the University of Colorado thought they could produce an analogous flow document for SIP reasonably well and quickly.

[AI] Nadim offered to lead the effort to develop the set of call flows for H.323. These developed boxes will likely be the subject of debate in subsequent calls, but it will be important to establish a baseline document to revise from. An eventual synthesis of the spaces is important, but could be distant.

*Action Items*

1. Samir and Doug will produce a SIP flow document.
2. Nadim will lead the effort to develop a set of call flows for H.323.