1 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: Peeking into IETF Security Standardization 3rd ETSI Security Workshop, Jan Hannes Tschofenig

2 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: The IETF 110+ working groups in 8 areas Security work in the Security Area and also in other working groups. Applications Area General Area RAI Area Internet Area Routing Area Security Area Transport Area SIP SIPPING AVTGEOPRIV RAI SIMPLEMMUSIC … O & M Area

3 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: SIP Identity RFC 4474 RFC 3261 S/MIME RFC 3325 P-Asserted-Identity SIP SAML SIP CERT RFC 3261 Connected Identity RFC 3323 SIP Privacy Identity in SIP UA-Driven Privacy Mechanism for SIP

4 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: SIP in a Nutshell Session Initiation Protocol (SIP) [RFC 3261] : SIP is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. SIP / RTP / RTCP Proxy B SIP/SDP Alice Proxy A SIP/SDP Bob

5 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: Early Approaches RFC 3261 S/MIME: Provides a way to sign the headers and encrypt the body of a SIP request – Copy of the SIP headers can be added to the body and signed with sender’s private key – Relies on the sender and recipient to have common trust anchors Proxies using mutual TLS connections may build a chain of trust so that only the first proxy in the chain has to authenticate the sender. RFC 3325: P-Asserted-Identity After authenticating the sender, the proxy can add P-Asserted-Identity header to the SIP message. This header carries the authenticated identity (SIP URI) of the sender. P-Asserted-Identity header is protected only in a hop-by-hop fashion between the SIP proxies along the path. The mechanism can only be used within a trust domain in which the SIP proxies and UAs communicate securely and the proxies share a mutual trust. RFC 3893: SIP Authenticated Identity Body (AIB) Format Defines contents of digitally signed message/sipfrag body to authenticate the sender

6 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: RFC 3323: Privacy in SIP Guidelines for providing maximal user-provided privacy Using anonymous values for display names and URIs in From header and user part of the Contact header Concept of Privacy Service provided by the network Often provided by the local outbound proxy but if hiding the domain of the sender is needed, then 3 rd party Privacy Service should be used. Works as a B2BUA. UA adds a Privacy header to communicate privacy requirements to the network – Values specified in RFC 3323: “header”, “session”, “user”, “none”, “critical” Privacy Service consumes values of Privacy header and provides requested services – “header”: obscures/removes e.g. Via, Contact & Record-Route headers – “session”: modifies SDP to hide the addresses and ports of the user – “user”: replaces display names and URIs in From and Contact like the UA could do, removes also Subject, Call-Info, Organization, User-Agent, Reply-To and In- Reply-To. – “critical”: rejects the requests if requested privacy can not be provided – “id”: (RFC 3325) remove P-Asserted-Identity header at the edge of trust domain

7 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: RFC 4474: An overview of operation Sending SIP requests over an Authentication Service The sender has to populate the From header with the registered AoR When sending the request, the sender contacts a SIP proxy in his local domain providing authentication service securely (e.g. over TLS) Operation of an Authentication Service within the user’s domain The authentication service authenticates the sender (e.g. by HTTP Digest) and verifies the SIP identity written into the From header of the SIP request The authentication service authorizes population of From header and digitally signs the message before forwarding it towards the ultimate recipient, using Identity header Within the forwarded SIP request the authentication service also provides a reference (HTTP URI) to its own domain certificate, using Identity-Info header Actions by the recipient of the request to verify the authenticated identity Fetches and validates the certificate of the authentication service Verifies the signature of the SIP request and the identity of the sender Checks the value of signed Date header to protect against replay attacks

8 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: Authentication Service within local SIP proxy Authentication Service of home.com SIP cloud INVITE SIP/2.0 From: Authorization: …. Content-Type: application/SDP Sends a SIP request and adds SIP AOR of the sender into the From header Authenticates the user with HTTP Digest, verifies the From URI and adds a signature to the request TLS Fetches the certificate of home.com and validates it. Verifies the signature and sender’s identity. Checks Date hdr. INVITE SIP/2.0 From: Date: Fri, 1 Jun :29:00 GMT Identity: Identity-Info: Content-Type: application/SDP Adds also a reference to home.com certificate to the request Checks the value of Date header or adds such if missing storing the certificate UA Remote UA

9 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: Connected Identity (RFC 4916) SIP request is targeted to a specific callee (SIP URI) but ultimately the connection may be created with someone else SIP proxies may retarget the request for several reasons Call might be transferred automatically or manually after the initial answer Connected Identity describes the solution Reuses the mechanisms defined in RFC 4474 for an UPDATE or re- INVITE request sent by the callee mid-dialog UA supporting this extension must add “from-change” tag to Supported header Allows the callee to change the value of From header to identify him/herself, instead of using the original value of the To header used when the dialog was created. The caller must update the value of To header accordingly for the subsequent requests within the dialog.

10 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: SIP Cert: draft-ietf-sip-certs Assumptions client certificates will be self-signed and users will have many devices per identity Solution: User managed credential storage Upload to the credentials (certificate & private key) in storage using PUBLISH Download to other devices using SUBSCRIBE/NOTIFY: event package “credential” – The private key within the NOTIFY might be encrypted with a shared secret Certificate discovery mechanism – for retrieving certificates of other users SUBSCRIBE/NOTIFY: event package “certificate” SIP Identity offers binding the self-signed certificate to a known certificate authority – Therefore, a hybrid model Certificate revocation as a byproduct Subscription refreshes Asynchronous certificate push to replace a revoked certificate

11 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: Credential Service in SIP Credential Service User Agent Y ewing.com User Agent User Agent X PUBLISH w/ Digest + TLS Event: credential (certificate & private key) SUBSCRIBE/NOTIFY w/ Digest + TLS Event: credential (certificate & private key) NOTIFY Event: certificate (Bob’s certificate) Authentication Service NOTIFY+ Identity Event: certificate (Bob’s certificate) SUBSCRIBE Event: certificate ewing.com SUBSCRIBE Event: certificate

12 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: SIP SAML: draft-ietf-sip-saml Based on requirements and scenarios defined in RFC 4484 Defines a SAML profile and SAML binding in collaboration with SIP To accommodate richer authorization mechanisms and enable trait-based authorization based on roles or traits instead of (or in addition to) SIP Identity Defines how SAML works together with SIP in alignment to SIP Identity Solution Approach: Like in SIP Identity the Authentication Service adds the Identity-Info header to the SIP request after authenticating the user – In SIP Identity the Identity-Info points to the certificate of the Authentication Service In SIP SAML the Identity-Info points instead to a SAML assertion conveying both the AS's certificate and user profile attributes The verification performed by the UAS performs (as specified for SIP Identity) is extended to cover verification of relevant SAML statements

13 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: SIP SAML Auth Service INVITE INVITE + Identity & Identity- Info User Agent Proxy Server sip.remote.edusip.local.edu User Agent INVITE + Identity & Identity-Info referring to SAML assertion Resolve URL to SAML assertion

14 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: UA-Driven Privacy Mechanism for SIP: draft-ietf- sip-ua-privacy Allows user agent to conceal privacy-sensitive information without the need for aid from the privacy service, as defined in RFC Uses recent work in the IETF to accomplish this goal: – Traversal Using Relay NAT (TURN) – Globally Routable User Agent (UA) URIs (GRUU) TURN allows UA to obtain an IP address and to route traffic via the TURN relay. GRUU allows the UA to mint URIs on the fly. These URIs are then used in the SIP messages.

15 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: Challenges SBCs/B2BUAs break SIP Identity since the digital signature is computed over parts of the SIP message that are changed by these boxes. SIP Identity not widely implemented and deployed due to the way how the current peering agreements are setup.  SPEERMINT working group Proposals for alternative SIP Identity handling have been proposed to the IETF. – Example: draft-wing-sip-identity-media Problems with the usage of E.164 numbers: Ownership of an E.164 number for a particular domain difficult to show.

16 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: Common Policy RFC 4745 RFC 5025 Presence Authorization Rules Geolocation Policy Consent Framework RFC 4568 Security Descriptions MIKEY RFC 3830 DTLS-SRTP Identity Example of Identity Info Consumers Authorization Policies Media Security

17 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: Security Description: RFC4568 Both endpoints announce their encryption keys in SDP A media-level attribute "a=crypto" describes the cryptographic suite, key parameters, and session parameters for the preceding unicast media line Lawful interception node can pick the key from the INVITE INVITE, Alice_Send Key 200 OK, Bob_Send Key SRTP BobBiloxliAlice 200 OK, Bob_Send Key

18 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: MIKEY Different authentication modes: – MIKEY: pre-shared key mode – MIKEY: public key mode – MIKEY: RSA-Diffie-Hellman mode Further authentication modes proposed. An overview can be found in draft-ietf-msec-mikey-applicability INVITE: DH Alice, Sig(K Alice, MSG) SRTP BobBiloxliAlice INVITE: DH Alice, Sig(K Alice, MSG) 200OK: DH Bob, Sig(K Bob, MSG)

19 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: Changes in Key Management 15+ key management proposals submitted to the IETF by end of draft-ietf-sip-media-security-requirements contains: – Challenging topics and scenarios for key management protocols (e.g., retargeting and forking) – Detailed list of requirements – Overview and evaluation of keying mechanisms March 2007: Three main proposals – DTLS-SRTP – MIKEYv2 – ZRTP Decision for DTLS-SRTP

20 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: SRTP - DTLS Certificate fingerprint is changed in SDP DTLS handshake is performed in the media channel and certificates are changed Encryption keys are derived from the handshake DTLS is multiplexed to the same ports as RTP Lawful interception requires Man-in-the-middle attack BobBiloxliAlice INVITE (fingerprint Alice) 200 OK, fingerprint Bob 200 OK (fingerprint Bob) SRTP DTLS Handshake

21 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: New Challenges Detailed work on a specification requires design decisions to be made. Investigations by the 3GPP revealed problems with middleboxes along the path. – Problems document in draft-sipping-stucker-media-path-middleboxes – Accepted as WG item for MMUSIC Lawful interception requirements are confusing but might be a problem. – Solution proposal for media recording (with cooperating end point) specified in draft-wing-sipping-srtp-key Problems with SIP Identity and SBCs/B2BUAs cause problems for media security as well.

22 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: Middleboxes in the Media Path Functions of the middleboxes (cf. [Middleboxes]): gating/pinholing: block all flows that are not allocated by the MIDCOM-agent NAT/media relay: For a bidirectional flow A  B, allocate a pair of transport addresses, one representing B towards A, one representing A towards B, and relay traffic accordingly Focus of the presentation is on firewalling. AliceBob SIP-proxy MIDCOM-agent SIP/SDP DTLSHandshake Media Filter rules, NAT bindings DTLSHandshake Media SIP/SDP Middlebox

23 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: Example Message Flow from [Framework]

24 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: Middlebox Impact for DTLS-SRTP X

25 R 255 G 211 B 8 R 255 G 175 B 0 R 127 G 16 B 162 R 163 G 166 B 173 R 137 G 146 B 155 R 175 G 0 B 51 R 52 G 195 B 51 R 0 G 0 B 0 R 255 G 255 B 255 Primary colours:Supporting colours: Conclusion Different stakeholders that are part of the Internet milieu have interests that may be adverse to each other, and these parties each vie to favor their particular interests. These tussels are reflected during the design, re-design, configuration and also during run-time. Protocol design is complicated since tussels are not resolved during design time in standards organizations alone anymore. We are currently seeing these ongoing tussels causing protocol re-design, both for media security and for SIP Identity. The term “tussel” was introduced in D. Clark, J. Wroclawski, K. Sollins, B. Braden: “Tussle in Cyberspace: Defining Tomorrow’s Internet”, in IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 13, NO. 3, JUNE 2005