Samir Chatterjee -- CGU
Bengisu Tulu – CGU
Jill Gemmill -- UAB
Bob Morgan – U. Washington
Doug Sicker -- U. Colorado - Boulder
Ameet Kulkarni, Anand Chavali – U. Colorado - Boulder
Mudassir Fajandar, Kim Norton -- U. Colorado - Boulder
Jonathan Tyman – Internet2
Ken Klingenstein – Internet2
Nate Klingenstein – Internet2
Steve Olshansky -- Internet2
Jeanette Fielden -- Internet2

*Discussion*
Reaffirm the key aspects of functionality that should be incorporated in the design approach.

Issue 1: Privacy and anonymity.
Anonymity is defined as being able to initiate a call without an authenticated presence. Privacy is where entity is authenticated but obscured or attributes about the entity are obscured. Are either of these desirable and is there a high cost associated in design with including these?

In Shibboleth anonymity requires the implementation of the handle server. Privacy requires the attribute release policy, neither of which is trivial to do. To provide anonymity in a situation where it would be needed, such as whistle blowing, a fake account could be set up to provide a shield. There are also ways to encrypt for privacy in point-to-point connections.

For handling privacy and anonymity in the SIP protocol, if the information can be conveyed in the SIP initiation mechanisms to the various decision points then it’s not too steep a price to reserve some anonymity. The key is where authorization decisions will be made and what information will be needed. For inter-realm authentication – authentication needs to happen locally and then the SIP proxy moves forward with the invite message from the origin side. Proof of authentication is by the originating SIP proxy choosing to forward invite request. It has only done so because the invitation is from an authenticated valid user. Making callbacks to acquire additional attribute information was discussed but was discarded as requiring considerable additional work to enable it. The key is a reasonable guess about what attributes the target proxy is going to want to make a decision so they can be packaged in the original invite as a MIME type as opposed to having to engineer a callback from target proxy to the origin side.

Consensus was reached that for the first implementation the goal is to pack as much information as possible in the invite message going out, subject to our best estimates of what will prove to be useful and practical, and subject to relevant local attribute release policies. The first Authn/z decision will be made at the origin proxy. The second proxy may need to call back to the first for more info about user, which the first proxy has full access to. The Authn/z decision made at target SIP client is hopefully made with info contained within the flow. If additional information is required it might be available from the target proxy. This might be done through the flows or out of band. Consensus was that trying to incorporate this mechanism at this point would add a great deal of complexity to the design. The functionality should be kept in mind as the design process progresses but they will not be explicitly included at this point.

Issue 2: Calls originating outside the trust space.
Within the trust space inter-realm authentication is handled by saying that if you trust the originating SIP proxy, which has authenticated the caller, that’s sufficient. Where are decisions made for authorization and what information is needed for calls outside the trust space? There are 3 points of authorization. 1) The originating SIP proxy choosing to forward the invite, where it’s decided that authentication has happened and the entity is authorized to make the call. 2) The authorization decision made at the target SIP proxy to receive the call, and 3) the authorization decision made by the target end entity to accept or reject the call.

The group agreed that administrators should have the ability to dictate how outside calls are handled to allow them control over policy, bandwidth, and usage. There is also need is for a mechanism to pass unauthenticated calls to the target client flagged in some manner to indicate that they are not authenticated and allow the client to decide if they wish to accept the call.
The SIP client can distinguish calls that have not been routed through the proxy by the lack of a via header. If the call has gone through an origin proxy but not a target proxy it will still have a via header. A matrix of four conditions was decided upon.
Direct to target client Target proxy vs. Authenticated and Unauthenticated

The next call will focus on understanding these conditions, how theypresent themselves and what options are possible.

Issue 3: Conference vs. point to point.
Should the authentication and authorization for a multi-point call be an extension of what’s been described or should it be done through a pin mechanism where knowing the token, such as a pin, is sufficient to manage the entry into the conference? The MCU is still an end-point that everyone dials into. Rather than the proxy making the decision, the user at the MCU would make the decision by providing a proper authorization code (pin). This means that whatever is being done for initial authentication is still appropriate. For example: Bob is not allowed to join the call until it is authenticated that it is Bob that is trying to join. The MCU case is important to consider because they are going to be introduced to the SIP world shortly. Consensus of the group is to presume there is a control point above the multicast level where there is authentication.

In summary it was decided to keep the issues of privacy and anonymity in mind as the design process moves forward using an attribute based mechanism (including identity) but not to explicitly design for them to avoid additional complexity at this point. Calls outside the trust domain will be enabled with a view towards tagging them and sending them to the target proxy or client for an accept decision. Finally, conference calls will need to rely on a combination of authorization control points.

The next call is August 6, 2002.