1. REFER Are security mechanisms beyond those in bis-09 needed?

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

3. Problem INVITE sip:C Referred-By: CB Referred-By <sip:unclaimed-prizes@lottery.state.tx.us Referred-By Can C trust the Referred-By header? Should the header influence logic at C? 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 ACB REFER 202 INVITE 4?? Authenticate Referror Refer-Authenticate: DIGEST (…) NOTIFY 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 ACB REFER (A-signed part containing Refer-To, Referred-By) 202 INVITE (B-signed part protecting entire INVITE (A-signed part containing Refer-To, Referred-By)) 200 OK NOTIFY 200 OK ACK 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 A B C REFER INVITE VERIFY

12. Taking Advantage of the Attended Transfer Triangle A B C 1: Invite/Hold2: Invite/Hold/Refer 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)