Authentication in SIP

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

2. 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)

3. 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

4. Proxy Server Location Server SIP Ontology sip:joe@remote.edu => sip:phone31.remote.edu sip.remote.edu INVITE (sip:joe@remote.edu) INVITE OK OK sip:phone31.remote.edu RTP User Agent User Agent sip:joe@remote.edu sip:alice@local.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

5. 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

6. 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

7. 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

8. 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

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

10. Usernames and Realms • This work assumes that identities are SIP URIs with optional display-names • “Jon Peterson” <sip:jon.peterson@neustar.biz> • 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

11. 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)

12. 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

13. 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

14. 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

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

16. 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

17. The End 11/02

18. 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

19. 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