1

Peeking into IETF Security Standardization

3rd ETSI Security Workshop, Jan. 2008

Hannes Tschofenig

Hannes.Tschofenig@nsn.com

2

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

AreaSIP SIPPING AVT GEOPRIV

RAI

SIMPLEMMUSIC

…

O & M

Area

3

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

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 BSIP/SDP

Alice

Proxy A

SIP/SDP SIP/SDP

Bob

5

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

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

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

Authentication Service within local SIP proxy

AuthenticationService ofhome.com

SIPcloud

INVITE sip:user@dot.com SIP/2.0

From: sip:USERA@home.com

Authorization: ….

Content-Type: application/SDP

Sends a SIP requestand adds SIP AORof the sender intothe From header

Authenticates theuser with HTTP Digest, verifies the From URI and adds a signature to the request

TLS

Fetches thecertificate ofhome.com andvalidates it.Verifies thesignature andsender’s identity.Checks Date hdr.

INVITE sip:user@dot.com SIP/2.0

From: sip:USERA@home.com

Date: Fri, 1 Jun 2007 13:29:00 GMT

Identity: <signed hash of sipfrag>

Identity-Info: https://home.com/cer

Content-Type: application/SDPAdds alsoa referenceto home.comcertificate tothe request

Checks thevalue of Dateheader or addssuch if missing

https://home.com/cerstoring the certificate

UARemote

UA

9

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

SIP Cert: draft-ietf-sip-certsAssumptions

• 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

Credential Service in SIP

CredentialService

User Agent Y

sip:bob@ewing.com

ewing.com

User Agent

sip:alice@barnes.com

User Agent X

sip:bob@ewing.com

PUBLISHw/ Digest + TLSEvent: credential(certificate & private key)

SUBSCRIBE/NOTIFYw/ Digest + TLSEvent: credential(certificate & private key)

NOTIFYEvent: certificate(Bob’s certificate)

AuthenticationService

NOTIFY+IdentityEvent: certificate(Bob’s certificate)

SUBSCRIBEsip:bob@ewing.com Event: certificate

ewing.com

SUBSCRIBEsip:bob@ewing.com Event: certificate

12

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

SIP SAML

AuthService

INVITE

INVITE +Identity & Identity-Info

User Agent

sip:bob@local.edu

ProxyServer

sip.remote.edusip.local.edu

User Agent

sip:alice@remote.edu

INVITE + Identity &

Identity-Info referring to SAML assertionResolve

URL toSAML assertion

14

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

• 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

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

Common

Policy

RFC 4745RFC 5025

Presence Authorization Rules

Geolocation

Policy

Consent

Framework

RFC 4568

Security

Descriptions

MIKEY

RFC 3830DTLS-SRTP

Identity

Example of Identity Info Consumers

Authorization

Policies

Media

Security

17

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

INVITE, Alice_Send Key

200 OK, Bob_Send Key

SRTP

BobBiloxliAlice

200 OK, Bob_Send Key

18

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: DHAlice, Sig(KAlice, MSG)

SRTP

BobBiloxliAlice

INVITE: DHAlice, Sig(KAlice, MSG)

200OK: DHBob, Sig(KBob, MSG)200OK: DHBob, Sig(KBob, MSG)

19

Changes in Key Management

•15+ key management proposals submitted to the IETF by end of 2006.

• 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

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)

INVITE (fingerprint Alice)

200 OK, fingerprint Bob

200 OK (fingerprint Bob)

SRTP

DTLS Handshake

21

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

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

Alice Bob

SIP-proxyMIDCOM-agent

SIP/SDP

DTLSHandshake

Media

Filter rules,NAT bindings

DTLSHandshake

Media

SIP/SDP

Middlebox

23

Example Message Flow from [Framework]

INVITE (offer)INVITE(offer)

DTLS – Hello

DTLS – Hello

Media

DTLS – Finished

DTLS – Finished

Media

200 OK200 OK

ACKACK

24

Middlebox Impact for DTLS-SRTP

X

INVITE (offer)INVITE(offer)

DTLS – Hello

DTLS – Hello

Media

DTLS – Finished

DTLS – Finished

Media

200 OK200 OK

ACKACK

DTLS - Hello

25

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