1 / 25

Peeking into IETF Security Standardization

Peeking into IETF Security Standardization. 3rd ETSI Security Workshop, Jan. 2008 Hannes Tschofenig Hannes.Tschofenig@nsn.com. The IETF. 110+ working groups in 8 areas Security work in the Security Area and also in other working groups. Internet Area. General Area. RAI Area. O & M

emele
Télécharger la présentation

Peeking into IETF Security Standardization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Internet Area General Area RAI Area O & M Area Applications Area Routing Area RAI Transport Area … AVT GEOPRIV SIPPING MMUSIC SIMPLE SIP Security Area

  3. Identity in SIP • SIP Identity • RFC 4474 SIP SAML RFC 3261 S/MIME UA-Driven Privacy Mechanism for SIP RFC 3323 SIP Privacy RFC 3261 Connected Identity RFC 3325 P-Asserted-Identity SIP CERT

  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. Proxy A Proxy B SIP/SDP SIP/SDP SIP/SDP SIP / RTP / RTCP Alice 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. Sends a SIP requestand adds SIP AORof the sender intothe From header SIPcloud Authentication Service within local SIP proxy Fetches thecertificate ofhome.com andvalidates it.Verifies thesignature andsender’s identity.Checks Date hdr. Authenticates theuser with HTTP Digest, verifies the From URI and adds a signature to the request AuthenticationService ofhome.com TLS INVITE sip:user@dot.com SIP/2.0 From: sip:USERA@home.com Authorization: …. Content-Type: application/SDP 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/SDP Remote UA UA Adds alsoa referenceto home.comcertificate tothe request Checks thevalue of Dateheader or addssuch if missing https://home.com/cerstoring the certificate

  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-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. Credential Service in SIP SUBSCRIBE/NOTIFY w/ Digest + TLS Event: credential (certificate & private key) SUBSCRIBEsip:bob@ewing.com Event: certificate ewing.com ewing.com SUBSCRIBEsip:bob@ewing.com Event: certificate User Agent X Authentication Credential sip:bob@ewing.com Service Service NOTIFY Event: certificate (Bob’s certificate) PUBLISH w/ Digest + TLSEvent: credential (certificate & private key) NOTIFY+Identity Event: certificate (Bob’s certificate) User Agent sip:alice@barnes.com User Agent Y sip:bob@ewing.com

  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. Auth Proxy Service Server SIP SAML INVITE + Identity & Identity-Info sip.local.edu sip.remote.edu INVITE + Identity & Identity-Info referring to SAML assertion INVITE Resolve URL to SAML assertion User Agent User Agent sip:alice@remote.edu sip:bob@local.edu

  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. Example of Identity Info Consumers Consent Framework • Common • Policy • RFC 4745 Authorization Policies RFC 5025 Presence Authorization Rules Geolocation Policy Identity RFC 4568 Security Descriptions • MIKEY • RFC 3830 Media Security • DTLS-SRTP

  17. Alice Biloxli Bob INVITE, Alice_Send Key INVITE, Alice_Send Key 200 OK, Bob_Send Key 200 OK, Bob_Send Key SRTP 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

  18. Alice Biloxli Bob INVITE: DHAlice, Sig(KAlice, MSG) INVITE: DHAlice, Sig(KAlice, MSG) 200OK: DHBob, Sig(KBob, MSG) 200OK: DHBob, Sig(KBob, MSG) SRTP 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

  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. Alice Biloxli Bob INVITE (fingerprint Alice) INVITE (fingerprint Alice) DTLS Handshake SRTP 200 OK, fingerprint Bob 200 OK (fingerprint Bob) 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

  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 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. SIP/SDP SIP/SDP SIP-proxyMIDCOM-agent Filter rules,NAT bindings DTLSHandshake Media DTLSHandshake Media Middlebox Alice Bob

  23. Example Message Flow from [Framework]

  24. Middlebox Impact for DTLS-SRTP X

  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

More Related