Presence, Security and Privacy

VON The Current Environment Many Faces of Security Authentication Verify someone is who they say they are Authorization Determine what someone is allowed to do Integrity Verify that the message sent is unchanged Confidentiality Make sure no one can observe a message Anonymity Do not reveal anything to someone else about your identity or whereabouts Traffic Analysis Do not reveal any information about yourself through observation of traffic

VON The Current Environment What does Privacy mean for Presence? SUBSCRIBE Authorization Need authentication to work Only allow certain people to subscribe Only provide certain information to certain people NOTIFY Confidentiality Only subscribers can see my presence Requires peer-to-peer if you dont trust your own server to see presence! SUBSCRIBE Anonymity Ask for subscriptions but dont say who you are PSTN analogy: Caller-ID blocking Authorization may prevent anonymous subscriptions NOTIFY Anonymity Not a contradiction… Reveal my status (available) but not my location Anonymity at odds with confidentiality Presence leakage through traffic analysis Can examine responses to subscriptions I make to gauge on- line or off-line status Example: if subscriptions are authorized by people, and subscribers notified of rejections, a rejected subscription implies on- line!

VON The Current Environment SIP for Presence SUBSCRIBE Authorization Authentication Hop-by-hop security Possible Digest Protocol mechanisms for authorization by client NOTIFY Confidentiality PGP and S/MIME SUBSCRIBE Anonymity SIP anonymization servers SIP extensions for privacy Same problem for VoIP! NOTIFY Anonymity Back-end presence filters Presence leakage through traffic analysis Smart protocol design Approval/disapproval of subscriptions are not revealed to subscriber in any way

VON The Current Environment HTTP Basic and Digest Challenge Response Client sends request Server responds with 401 or 407 with challenge Client ACKs Client sends request again (higher Cseq) with credentials If OK, server processes, else sends 401/407 again Mechanism is Stateless Dont need to know that a challenge was issued Requests just contain credentials Credentials can be cached Subsequent requests to the same server can contain same credentials If they expire, server issues 401/407 Two relationships Proxy Server challenges UAC UAS challenges UAC Multiple credentials Any number of proxies and a UAS can issue challenge Credentials are accumulated

VON The Current Environment HTTP Basic Authentication Cleartext Password Base64 encoded Not useful alone May be useful within a TLS connection from client to server Emulates http usage of client authentication Not widely implemented INVITE 401 Authorize Yourself WWW-Authenticate: Basic realm=mufasa INVITE Authorization: Basic QWxhZGRpbjpvcGVuI== 200 OK

VON The Current Environment HTTP Digest Authentication Server challenge Realm (keyword for password) Nonce (random number, rotates periodically) UAC Response Hash of username, password, realm and nonce, and also method Can also include body in hash Specifically, its H(H(username:realm:password):n once:H(method:URI)) Why double hashing? Server can store H(user:realm:pass); doesnt change Computes H(method:URI) combines with first No password or username on disk! Response Authorization Responses can also contain credentials that authenticate callee

VON The Current Environment PGP RFC2543 specified security based on PGP Provided Client to server authentication Client to server encryption Server to client authentication Server to client encryption Uses public keys Requires PGP community General problem with PGP Requires request to be canonicalized Standardized format over which signature is computed Requires devices to maintain order of headers and parameters Deprecated! No implementations Canonicalization a pain Other approaches more mature

VON The Current Environment Coming soon: S/MIME S/MIME is an IETF standard for security Provides authentication and encryption Based on X.409 Public Key Certificates The kind you get from Verisign Some infrastructure in place Can be shipped with message Big overhead Message contains payload, signed piece, and signature, maybe certificate Requires multipart SDP INVITE SIP/2.0 From: To: Content-Type: multipart INVITE SIP/2.0 From: To: Content-Type: SDP SDP text signature certificate

VON The Current Environment Transport Security Previous mechanisms allow for E2E Security Works through any number of proxies Proxies dont need to be trusted Security within SIP layer Hop by Hop Security Possible as well Proxies have trust relationship with each other E2E security by transitivity Relies on all hops doing security Proxy UA1 UA2 Secure Tunnel

VON The Current Environment Transport Security IPSec UDP also Not widely implemented IKE barely supported Resides in OS Requires no SIP extensions Several techniques TLS/SSL IPSec TLS/SSL Firewall and NAT Traversal Widely implemented Key exchange works Resides in application layer TCP only

Information Resource Jonathan Rosenberg