html5-img
1 / 13

REFER

REFER. Are security mechanisms beyond those in bis-09 needed?. Problem. REFER sip:B Refer-To: sip:C Referred-By: <sip:A>. INVITE sip:C Referred-By: <sip:A>. Can C trust the Referred-By header? Should the header influence logic at C?. A. B. C. Problem. INVITE sip:C

anastacia-manella
Télécharger la présentation

REFER

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. REFER Are security mechanisms beyond those in bis-09 needed?

  2. Problem REFER sip:B Refer-To: sip:C Referred-By: <sip:A> INVITE sip:C Referred-By: <sip:A> • Can C trust the Referred-By header? • Should the header influence logic at C? A B C

  3. Problem INVITE sip:C Referred-By: <sip:A> • Can C trust the Referred-By header? • Should the header influence logic at C? B C • Referred-By <sip:unclaimed-prizes@lottery.state.tx.us • Referred-By <sip:chair@ietf.org> • Referred-By <sip:audits@irs.gov> • INVITE sip:C?Replaces=1234%40C%3Bto-tag=1234%3Bfrom-tag=3994%3B

  4. Choices for Path Forward • Remove Referred-By from REFER • Specify transfer specific mechanism in the transfer draft • Specify REFER specific mechanism in the REFER draft • Solve general problem of passing authorization tokens through intermediaries.

  5. Possible Mechanisms • Use Referred-By generic-params • Use Authorization header • Use S/MIME body parts • Have C directly contact A

  6. Use generic-params • Add a signature/hash over the information to protect to the Referred-By header • This was the original PGP-based proposal

  7. Use Authorization header • Refer-To: sip:C?Authorization=DIGEST&realm=… • How does A provide meaningful credentials? • Needs a challenge from C • Challenge can be carried from B to A using NOTIFY • How does challenge get from C to B?

  8. Use Authorization header A B C REFER INVITE 202 NOTIFY 4?? Authenticate Referror Refer-Authenticate: DIGEST (…) 4?? Authenticate Referror Refer-Authenticate: DIGEST (…) ACK 200 REFER Refer-To: sip:c?Authorization=DIGEST(…) INVITE Authorization: DIGEST(…)

  9. Use S/MIME Body Parts • Provide a S/MIME protected sipfrag containing Referred-By • In Refer-To URL as a ?body= component • In Body Part • REFER recipients add that part to the body of the triggered request (probably making it multipart). • Likely to be more efficient that challenge/response since both A and B’s identity can be proven to C in the initial message to C

  10. Using S/MIME Body Parts A B C REFER (A-signed part containing Refer-To, Referred-By) INVITE (B-signed part protecting entire INVITE (A-signed part containing Refer-To, Referred-By)) 202 200 OK NOTIFY ACK 200 OK 200

  11. Contact A directly • Have C send a request to A asking “Did you ask B to do this” • Use URI from Referred-By as RURI • C can authenticate A using bis-09 mechanisms B INVITE REFER VERIFY A C

  12. Taking Advantage of the Attended Transfer Triangle 1: Invite/Hold 2: Invite/Hold/Refer B A C 3: Invite

  13. Proposal • Add an S/MIME-based mechanism for carrying proof of identity and content of the Refer* headers from A to C • Add security discussion of some use cases (particularly the screening form of attended transfer)

More Related