1 / 7

Security “ Negotiation ” Open Issues - and draft-arkko-sip-sec-agree-01.txt

Security “ Negotiation ” Open Issues - and draft-arkko-sip-sec-agree-01.txt. Jari Arkko jari.arkko@ericsson.com Co-authored with Vesa Torvinen (Ericsson), Tao Haukka (Nokia), Sanjoy Sen, Lee Valerius (Nortel). An example network. Client 1: TLS, Dig. TLS. Server: TLS, Dig. Client 2:

kforest
Download Presentation

Security “ Negotiation ” Open Issues - and draft-arkko-sip-sec-agree-01.txt

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. Security “Negotiation”Open Issues- and draft-arkko-sip-sec-agree-01.txt Jari Arkko jari.arkko@ericsson.com Co-authored with Vesa Torvinen (Ericsson), Tao Haukka (Nokia), Sanjoy Sen, Lee Valerius (Nortel)

  2. An example network Client 1: TLS, Dig TLS Server: TLS, Dig Client 2: Digest Digest TLS Client 3: TLS, Dig • Multiple security mechanisms • No network-wide policy control • Different software versions

  3. An example network – Attack Client 1: TLS, Dig Digest Server: TLS, Dig Attacker Client 2: Digest Digest Digest Client 3: TLS, Dig

  4. Potential Solutions • (1) TLS, IKE have internal protection • Limited only to the case where we have already decided to use them • (2) Enhanced HTTP Digest has bidding down protection • Again limited in the same manner • (3) Sips: makes sure TLS is used • Assumes URLs have learned securely • Either (a) limits users to talking to TLS-capable nodes or (b) allows a bidding down attack • Can ensure complete path secured, but hop-by-hop • (4) Draft-arkko-sip-sec-agree-01 • Server lists its mechanisms, client picks one • Once security is on, client repeats the list => modifications detected • Full solution, but assumes at least integrity protection is used from day one

  5. Issues • Is the bidding down attack a problem? • Yes • There are realistic upgrade cases where this would be useful • Internal protection in TLS etc enough? • Not if we have multiple mechanisms • Sips: doesn’t help either unless we only use TLS • Proposal? • We should do something about this! • Sip-sec-agree sufficient? • Integrity protection required from day one, but can we do any better? • Lowest acceptable integrity protection must not be vulnerable • Any attacks that we haven’t thought of?

  6. Detailed Solution Issues • Stateless vs. stateful approach? • => Stateless! • Possible to use Support/Require? • Seem to have different semantics, not good match • => New header • Target identified e2e (OPTIONS) or along-the-path (header) • => Include along-the-path negotiation for less RTT’s • SIP layer response when the list was modified?

  7. Way forward • Do something! • Proposal: new small RFC by SIP WG • Needed for 3GPP • Time pressure

More Related