Authentication in SIP Jon Peterson NeuStar, Inc Internet2 Member Meeting Los Angeles, CA - Nov 2002

A Crash Course in SIP SIP is a protocol that provides two functions –Discovery: allows endpoints in the Internet that want to share a session to discover one another –Session Management: allows endpoints to exchange session framing messages and other context information about sessions SIP is a rendezvous protocol for setting up real-time communications sessions –Common applications include voice (telephony), video, presence and instant messaging SIP is a control layer used in concert with other protocols that instantiate the session –Session Description Protocol (SDP) –Real-Time Protocol (RTP)

SIP Technology SIP was designed in the IETF, current specification is RFC3261 SIP builds heavily on SMTP and HTTP –SIP carries MIME bodies, like SMTP, and has concepts of user agents and ‘relays’ (SIP proxy servers) MIME is end-to-end in SIP –Uses the To, From, Subject-style headers from SMTP –Supports HTTP-style authentication, response codes (like 404), Request-URI, DNS SRV records Request-URI is hop-by-hop Frequently SIP carries SDP as a MIME body in requests and responses that initiate a dialog Has a concept of registration – a user agent registers itself as a place where a user is available to receive requests –Highly dynamic and scalable

SIP Ontology Proxy Server INVITE RTP User Agent OK INVITE OK User Agent sip.remote.edu sip:phone31.remote.edu Location Server => sip:phone31.remote.edu Alice uses DNS to find the deference the Request-URI (which points to the Proxy-Server) User agent sip:phone31.remote.edu had previously registered itself as a contact for Joe

Security mechanisms in baseline SIP SIP is difficult to secure –Has many different end-to-end and hop-by-hop sec properties Digest –Based on HTTP Digest (Basic has been deprecated) –Can be used to derive authentication properties (based on shared secrets) and some integrity properties –Useful for the SIP registration function (likely to share a secret with the registrar) TLS –Which is of course the new name for SSL –Gets canonical properties: integrity, confidentiality, mutual authN, replay protection) –Authentication requires certificates S/MIME –SIP used to support PGP… –Authentication also requires certificates

What is identity in SIP? A SIP identity is a way that a user can be contacted – the From field of a request –An ‘address of record’ URI, same as used in registration –Important: an identity is a URI in the namespace of some domain, the domain where the user registers A SIP identity also includes an optional display-name –Very similar to a mailto: URL The baseline SIP From field contains an identity –However, most user agents can change the From field arbitrarily –There is no built-in assurance that the user can legitimately claim this identity Cryptographic authentication provides greater assurance than the From field –Several authentication methods in baseline SIP –But not every SIP entity can or should attempt to authenticate

Authentication problems for SIP Shared-secret based authentication only works with a pre- negotiated key –Useful to be able to authenticate yourself to someone with whom you have no previous association Like in the telephone network – Caller-ID functionality is not predicated on previous association When will end-user PKI deployment succeed? –How to build and enroll a PKI for SIP identities? –How to get private keys to all the user agents that a user might employ? –Will underpowered devices (like cellphones) have enough horsepower to use certs? –Self-signed certificate usage for S/MIME suffers from MitM problems

Providing Identity with an Authentication Service An Authentication Service is a logical role played by a SIP entity –Usually an intermediary, like a local proxy SIP user agents send requests through an Authentication Service which: –Authenticates the user according to a set of practices, and then –creates and cryptographically signs an authentication token for the user –and shares that identity with others. –Some caveats here about privacy We believe this dodges many of the PKI issues associated with end- user certificates –Essentially, this is a federated identity model –While remaining compatible with end-user certificates –Also allows opportunities for supervised anonymity – prove identity to Auth Service but hide it from others Now proposed in draft-ietf-sip-identity-00 –One format for authentication tokens defined in draft-ietf-sip-authid- body-00

Routing Requests through an Authentication Service (client redirection model) Auth Service INVITE 428 (w/ auth-id) INVITE (w/ auth-id) User Agent Proxy Server sip.remote.edusip.local.edu User Agent INVITE Joe can now inspect the authentication token create by local.edu for Alice

Usernames and Realms This work assumes that identities are SIP URIs with optional display-names –“Jon Peterson” –Typically this will already appear in the From field Each Authentication Service has a ‘domain’ that corresponds to its domain name (“neustar.biz”) –Method in which usernames and display names are determined for each identity are dependent on the authentication method (“jon.peterson”) This realm appears in challenges for Digest authentication, and should be the same as the Authentication Service hostname Authentication Service must also hold a certificate corresponding to the domain, so that the signature on an authentication token matches the domain of the identity

What is privacy for SIP? In SIP, privacy is the withholding of an identity from potential recipients of a SIP message –Private requests can still lead to a dialog, but should not allow the originator of a message to be contacted outside of the dialog by the recipient Recipients of requests might also keep information such as their contact addresses private Important questions: –When is privacy necessary? How much privacy do you need? –When can the user agent provide privacy itself? Intermediaries may need to provide some privacy functions All addressed in draft-ietf-sip-privacy-02 (will be RFC3323)

How not to share authentication tokens Usually identity is withheld at the request of a user Ideally, an Authentication Service shouldn’t generate or send authentication token when privacy is needed –Simplest, most secure solution If identity must be shared amongst a community of entities which are ‘trusted’ by the Authentication Service, it could: Remove the identity (cleartext) –Hope that someone downstream removes NAI when necessary This is only secure when the policies of downstream entities can be anticipated by the authentication service – including who is trusted Hence meaningful for federated networks Encrypt the identity –Only holders of the decryption key will be able to view identity Authentication service trusts that decryption key has been appropriately distributed

Routing Requests through Privacy/Authentication Services Services like network authentication and privacy need to be inserted into the path of SIP requests –While some privacy functions can be completed by the client, others are the responsibility of the network Best if these services are co-located with a local outbound proxy for an administrative domain –Although privacy may require services provided outside the local administrative domain (onion routing) –Authentication Services should use the same credentials that are provided when a user registers Suggests that an Authentication Service and a registrar might be co-located Forcing requests to pass through an Auth Service creates a sort of single sign-on for SIP –Pre-loaded Route headers

Proxying vs. Rejecting for Retry Authentication Service can choose to add an auth-id body to requests itself –One less RTT –However, intermediaries should not tamper with bodies Possible that this could trip e2e integrity mechanisms Authentication Service can reject the request with a new status code (428) containing an auth-id that should be used by the client –Redirection is always more secure than proxying –Data can be hidden from originator by encrypting the auth-id body if necessary SIP ‘content indirection’ may also help –Client anticipates a URI where the Authentication Service will make the token available –Maybe it’s the best of both worlds

Routing Requests through an Authentication Service (proxy model) Auth Service INVITE INVITE (w/ auth-id) User Agent Proxy Server sip.remote.edusip.local.edu User Agent INVITE Joe can now inspect the authentication token create by local.edu for Alice

The SAML proposition for SIP A SAML assertion can be a type of authentication token that might be created by an Auth Service –Auth Service essentially also acts as an assertion server –Presumably Auth Service would also accept subsequent attribute requests Carrying the assertion in SIP by reference or by value –SIP has a concept of ‘content indirection’ that allows large MIME bodies to be carried by reference Essentially a MIME type for URLs pointing to MIME bodies Draft on using SAML with SIP in this fashion is currently under development –Not uncontroversial in the IETF –SOAP support for SIP endpoints is also somewhat controversial

The End 11/02

Identity in a Header or a Body Old SIP Privacy mechanisms proposed a header –Headers are easy to add/remove for intermediaries –Difficult to stage the desired security properties in a header Security requires signature over multiple headers –In addition to identity, need Call-ID and a timestamp at least Negotiating security properties is difficult Need certificates for a complete solution –Easier to stage Digest-ish security in a header New identity mechanism proposes an ‘auth-id’ body –Problem: How does an intermediary add the body? Possibly appended to an existing MIME body with MIME multipart –No length concerns (but who supports MIME multipart?) –Can reuse S/MIME / PKI (but who supports S/MIME now?) –Easy to record multiple headers worth of data

History of SIP Privacy Telephone networks have a concept of privacy –Caller-ID features in recent PSTN networks Unavailable, blocked Number and/or name –“presentation restriction” in ISUP –Multiple ways of representing identity of the caller Varying degrees of verification/screening Early SIP privacy proposals followed the PSTN –Controversial because they were anti-privacy –No cryptographic identity assurance –Relied on ‘trust domains’ that were imperfectly defined Different philosophy for Internet privacy, usually The result: split out privacy and identity into new work