SAML for SIP Hannes Tschofenig, Jon Peterson, James Polk, Douglas Sicker, Marcus Tegnander

IETF#61 Current Status The SIP header may either carry an Artifact or a CID URI. The draft also allows the Asserting Party to add a URL to point to the Assertion to prevent this level of indirection. The SIP body may carry one or more SAML Assertions. The MIME type of this SAML Assertion is defined in [I-D.hodges-saml- mediatype].[I-D.hodges-saml- mediatype]

IETF#61 What prevents us from finalizing the draft? A few identified problems: Assertion Constraints and Scope: Reference Integrity Canonicalization versus Replication: Related to reference integrity and how fields are hashed. Placement of Assertions in Messages: Header vs. Body, technical mechanisms (e.g., SIP content indirection mechanism) Related draft of importance: Peterson, J., "Security Considerations for Impersonation and Identity in Messaging Systems", draft-peterson-message- identity-00 (work in progress), October 2004.Security Considerations for Impersonation and Identity in Messaging Systems

IETF#61 Assertion Constraints and Scope - Motivation Auth Service INVITITE + Assertion INVITE + Assertion User Agent Proxy Server sip.remote.edusip.local.edu User Agent Malicious Proxy Server can impersonate Alice towards Joe INVITITE + Assertion

IETF#61 Assertion Constraints and Scope Solution Approaches Placing some restrictions in the Assertion (e.g., sender, receiver, lifetime) Reference Integrity Binding the Assertion/Artifact to a particular session (based on a number of selected fields) using a digest From, Call-ID, Date and Contact header Usage of "Holder-of-the-Key" Binds a key (symmetric or asymmetric) to the assertion Allows the SIP UA to actively participate in the exchange. Might be very interesting in relationship with.

IETF#61 Routing Requests through an Authentication Service (proxy model) Auth Service INVITE INVITE (w/Artifact) User Agent Proxy Server sip.remote.edusip.local.edu User Agent INVITE Auth Service attaches Artifact to the SIP message Joe (or even the Proxy Server) need to fetch the Assertion from the Auth Server in order to inspect it.

IETF#61 Routing Requests through an Authentication Service (client redirection model) Auth Service INVITE 428 (w/Artifact-or Assertion)) INVITE (w/Artifact-or-Assertion) User Agent Proxy Server sip.remote.edusip.local.edu User Agent INVITE Joe (or even the Proxy Server) can inspect the Artifact/Assertion Auth Service attaches Artifact or Assertion to the SIP message

IETF#61 Issues for further investigation Which parameters do you use to compute the Reference integrity? Binding the Assertion to the From-To field allows you to reuse the Assertion between (, ) [considering some other constraints] This might, in some scenarios, not be desired. You might want to include the Call-ID in some other scenarios. How does the Authentication Service know what you would like to have?

IETF#61 Going a step further.. Auth Service HTTP INVITE (w/Artifact-or-Assertion) User Agent Proxy Server sip.remote.edusip.local.edu User Agent INVITE Joe (or even the Proxy Server) can inspect the Artifact/Assertion Fetching an Assertion/Artifact using HTTP (or other protocols) What fields do you include in the Assertion to provide Reference Integrity?

IETF#61 Please send us comments! Questions ?