Taste Security

Sip security l.jpg
1 / 50
0
0
637 days ago, 190 views
PowerPoint PPT Presentation
Review. Framework modelThreats and promisesApproacheslower-layer (L3, L4)application-layerborrowed and adjusted ? HTTP Digestnew, SIP-specificshort-term versus long-termAgreeing on security mechanismDenial-of-administration attacksPrivacy. Framework model. . . . . Taste trapezoid. . outbound intermediary. . a@foo.com: 128.59.16.1.

Presentation Transcript

Slide 1

Taste Security Henning Schulzrinne Dept. of Computer Science Columbia University July 2002

Slide 2

Overview System demonstrate Threats and guarantees Approaches bring down layer (L3, L4) application-layer acquired and changed  HTTP Digest new, SIP-particular here and now versus long haul Agreeing on security instrument Denial-of-administration assaults Privacy

Slide 3

System display outbound intermediary SIP trapezoid a@foo.com: 128.59.16.1 enlistment center

Slide 4

Threats Bogus solicitations (e.g., fake From ) Modification of substance REGISTER Contact SDP to divert media Insertion of solicitations into existing discoursed: BYE , re-INVITE Denial of administration (DoS) assaults Privacy Inside versus outside dangers Trust areas – can intermediaries be trusted?

Slide 5

Threats outsider not on way can produce demands uninvolved man-in-center (MIM) tune in, however not adjust dynamic man-in-center replay cut-and-glue

Slide 6

Protection e-e: UA to UA h-h: jump by-bounce (UA to intermediary, intermediary to intermediary) e-m: UA-to-center (intermediary) m-m: intermediary to-intermediary

Slide 7

L3/L4 security choices IPsec Provides keying instrument yet IKE is intricate and has interop issues works for all vehicle convention (TCP, SCTP, UDP, … ) no accreditation bringing API TLS gives keying system great qualification restricting component no support for UDP; SCTP in advance subject to DOS by faking RST

Slide 8

Hop-by-bounce security: TLS Server endorsements settled for web servers Per-client testaments less so email return-address (class 1) declaration not troublesome (Thawte, Verisign) helpful for positive separating Server can challenge customer for testament  last-jump challenge

Slide 9

TLS security: SIPS URI SIPS plot included RFC 3261 sips:alice@example.com All solicitations must utilize TLS, aside from in callee's area does not ensure that each intermediary checks bonafides of next bounce

Slide 10

Authentication: User secret word INVITE sip:alice:secret@example.com Can show up into , From , Request-URI Treated as a major aspect of client name Obviously, not secure unless e2e way encryption Can be effortlessly included on site page or in Contact header But (somewhat) valuable for spam aversion: clients with watchword get the chance to talk specifically others need to experience auto-orderly ("press 39 in case you're a person'')

Slide 11

Authentication: HTTP-determined instruments RFC 2617 for HTTP/1.1 HTTP Basic confirmation: in RFC 2543 plain-content watchword:  401 Authentication Required WWW-Authenticate: Basic realm="WallyWorld"  Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ= Removed from RFC 3261 as shaky Also maintains a strategic distance from some downsize assaults

Slide 12

HTTP Digest validation Challenge-reaction: hash nonce  SIP/2.0 401 Unauthorized WWW-Authenticate: Digest realm="biloxi.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41"  Authorization: Digest username="bob", realm="biloxi.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:alice@atlanta.com", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41"

Slide 13

HTTP Digest verification Allows client to-client (recorder) confirmation for the most part customer to-server additionally server-to-customer ( Authentication-Info ) Also, Proxy-Authenticate and Proxy-Authorization May be stacked for numerous intermediaries on way

Slide 14

HTTP Digest confirmation

Slide 15

HTTP Digest verification REGISTER To: sip:alice@example.com 401 Unauthorized WWW-Authenticate: Digest realm="alice@example.com ", qop=auth, nonce="dcd9" REGISTER To: sip:alice@example.com Authorization: Digest username="alice", nc=00000001, cnonce="defg", response="9f01" REGISTER To: sip:alice@example.com Authorization: Digest username="alice", nc=00000002, cnonce="abcd", response="6629"

Slide 16

HTTP Digest confirmation reaction = H(H(A1): nonce : nc : cnonce : qop :H(A2)) A1 = username : domain : secret word A2 = technique : URI or strategy : URI :H( body ) where H( x ) = MD5( x )

Slide 17

HTTP Authentication-Info Included in 200 reaction Can be utilized to verify reaction Provides next nonce (challenge) Authentication-Info: nextnonce="abcde", qop=auth-int, rspauth="3974" For qop=auth-int: A2= uri :H( body )

Slide 18

Problems with Digest Authentication Replay assaults Masquerade assaults: trick customer into giving certifications Some man-in-center assaults: minimize security (alter or evacuate qop) picked plaintext assaults  utilize cnonce Does not secure SIP ask for or reaction headers especially awful for REGISTER: change Contact header to divert calls

Slide 19

HTTP Digest: headers Extend Digest with rundown of secured headers: headers="To From Call-ID Contact" Problem: require accepted header structures or byte-by-byte duplicate

Slide 20

HTTP Digest: burrowing Tunneling: utilize substance body insurance REGISTER sip:example.com SIP/2.0 To: sip:alice@example.com From: sip:alice@example.com Authorization: Digest qop=auth-int, response="284e", … Content-Length: 123 Content-Type: message/taste REGISTER sip:example.com SIP/2.0 Contact: sip:alice@128.59.16.1 To: sip:alice@example.com From: sip:alice@example.com Content-Length: 0

Slide 21

HTTP Digest: burrowing No requirement for authoritative frame No augmentations of RFC 2617 required Backward-perfect – old intermediaries can't botch up solicitations Header duplication: To , From , Call-ID , Content-Length , Content-Type

Slide 22

Extensions to Digest draft-undery-taste auth-01 Authentication-Info header included "realm" parameter embedded by UAS to secure reactions future nonces Proxy-Authentication-Info embedded as a substitute to secure reaction future nonces message/taste and message/sipfrag for securing headers utilizing qop=auth-int

Slide 23

Enhanced SIP Digest: nonce calculation nonce calculation not indicated in RFC 2617 nonce="( alg , sort ) time-stamp "- " H( time-stamp ":" ask for uri ":" private-key )" Client thinks about alg,type to those in nonce  grumble if distinctive Server likewise checks nonce

Slide 24

Agreeing on security methods draft-ietf-taste sec-concur 04 disclosure and transaction of security system: HTTP Digest, Digest with respectability, IPsec, S/MIME, TLS, EAP, ... keep away from offer down assaults Security-Client, Security-Server, Security-Verify

Slide 25

Security revelation: message stream intermediary UAC OPTIONS sip:proxy.example.com SIP/2.0 Security-Client: tls Security-Client: process respectability Require: sec-concur Proxy-Require: sec-concur SIP/2.0 494 Security Agreement Required Security-Server: ipsec-ike;q=0.1 Security-Server: tls;q=0.2 INVITE sip:proxy.example.com SIP/2.0 Security-Verify: ipsec-ike;q=0.1 Security-Verify: tls;q=0.2 Route: sip:callee@domain.com Require: sec-concur Proxy-Require: sec-concur

Slide 26

Security disclosure Relies on check and that even weakest component offers uprightness assurance aggressor can expel solid crypto from customer or server ability sign! distinguished amid check Does not forestall dissent of-administration assaults e.g., make customer and server contradictory

Slide 27

Last jump verification UAS might need to determine personality of last intermediary last intermediary executes call sifting – did the call truly experience there? Proposition 401 test with constrained Via HMAC (H(shared secret,request)) intermediary must know to do this (yet unavoidable) replay and cut-and-glue aversion? various intermediaries?

Slide 28

End-to-end validation What do we have to demonstrate? Individual sending BYE is same as sending INVITE Person calling today is same as yesterday Person is surely "Alice Wonder, working for Deutsche Bank" Person would somebody say somebody is with record at MCI Worldcom

Slide 29

End-to-end validation Why end-to-end confirmation? forestall telephone/IM spam disturbance guests trust: is this truly some person from my organization getting some information about the new gadget? Issue: bland personalities are shoddy separating bozo@aol.com doesn't keep calls from jerk@yahoo.com (new day, sam individual)

Slide 30

End-to-end verification and classification Shared privileged insights just scales ( N 2 ) to little gatherings OpenPGP chain of trust S/MIME-like epitome CA-marked (Verisign, Thawte) each end direct needs toward have rundown of Cas need CRL checking ssh-style

Slide 31

Ssh-style confirmation Self-marked (or unsigned) declaration Allows dynamic man-in-center to supplant with possess testament dependably require secure (against alteration) approach to pass on open key However, safe once settled

Slide 32

S/MIME illustration INVITE sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: BigGuy <sip:UserA@here.com> To: LittleGuy <sip:UserB@there.com> Call-ID: 12345601@here.com CSeq: 1 INVITE Content-Type: multipart/marked; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 - boundary42 Content-Type: message/taste

Slide 33

S/MIME case (2) INVITE sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: BigGuy <sip:UserA@here.com> To: LittleGuy <sip:UserB@there.com> Call-ID: 12345601@here.com CSeq: 1 INVITE Contact: <sip:UserA@100.101.102.103> Content-Type: application/sdp Content-Length: 147 v=0 … - boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: connection; filename=smime.p7s ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 … 7GhIGfHfYT64VQbnj756 - boundary42- -

Slide 34

Other SIP security issues REFER security auth

SPONSORS