*Attendees*
Ken Klingenstein, Internet2 (Chair)
Scott Cantor, OSU
Jill Gemmill, UAB
Jon Peterson, NeuStar
Samir Chatterjee, CGU
Tarun Abhichandani, CGU
Jonathan Tyman, Internet2
Steve Olshansky, Internet2
Doug Sicker, U. Colorado
Bob Morgan, U. Washington
Nadim El-Khoury, U. North Carolina - Chapel Hill
Ameet Kulkarni, Mudassir Fajandar, U. Colorado - Boulder
Jeanette Fielden - Internet2

*Discussion*
There are two options for handling invites and potential responses:
1) Creating an assertion that contains authentication data. One property of putting the information in an assertion is that it contains a directive for who is going to use the assertion and therefore does not need to have the surrounding security apparatus that is more explicit about restricting its distribution. The assertion is placed in a message and sent out with signed statement that essentially states that if you’re not the recipient you should ignore this. This option is similar to picking up the phone to make a call; it’s not immediately clear whom the recipient is. This creates a security issue, since intermediaries may look at it to route.
2) Sending an artifact is a reference that you associate with a particular relying party. When that relying party asks for the full assertion you then say prove to me you’re that party and I’ll give it to you. It’s more secure but you need to know who the relying party/recipient is. With an artifact any party that receives it can inspect it. The party doesn’t know if it should try the reference the artifact represents unless the artifact is protected by other security properties. As a result the artifact’s usage can be ambiguous. Another issue is that artifacts have not been introduced into the web services arena. Vulnerabilities of artifacts include:
a. A third party “stealing” the artifact and exploiting it.
b. Some preexisting relationship needs to exist between the recipient of the artifact and the issuer.
c. Vulnerabilities are dependent on how the artifacts are created. If they are created in a predictable way then it might be possible to duplicate them.
What is the minimum to provide reasonable security around the artifact?

One model is: a SIP user agent client sends a request to an authentication service, inspects the request and credentials, and creates an assertion, an authenticated identity body, which contains what the server believes to be the identity of the originator of the request. It also contains a number of SIP headers that are there for integrity reference. Someone receives the authenticated identity body later and can compare headers for verification. This model allows the authentication service to see whom the request is for. Presumably it could choose an action based on the destination.

The danger with this approach is the scenario where you’re inserting merely a reference and expect that later a secure interaction will occur to pull the actual assertion. You will have to authenticate the requester to verify that whoever is asking for the assertion is the one that should be requesting the assertion. As a result, when the reference to the assertion is created there has to be an association between the assertion and the authenticated identity of what/who is going to ask for it later. This means the originating party later becomes the relying party.

The consensus is that both approaches need to be available and the differences in security between the approaches can be mitigated.

The recommendation is to use an artifact in an authenticated entity body rather than in a normal SIP header that does not have any integrity or confidentiality security properties.

Questions for consideration as development progresses:
1. If a Kerberos authentication is done first is there any way to use that to provide an authenticated SAML artifact or assertion for use within SIP?
2. Most of this was web based Authn first with SAML flowing from that. If Kerberos and nothing with web at all what are the mechanisms for getting SAML assertions for use in SIP?
3. If no prior authentication, how tell people to authenticate? Can people initiate SIP calls without prior authentication? If you use a challenge to authenticate how do you handle cases where there are no credentials to present?

There are also three conditions we want to differentiate for in policy:
1. The authenticated call.
2. The unauthenticated anonymous guest call.
3. User is authenticated to origin security domain but is anonymous to the target.

The next call is Tuesday August 27, 2002.