Dan Wing | 21 Nov 2007 08:17
Picon
Favicon

SRTP Key Disclosure

Business requirements of some businesses require recording certain
phone calls.  For example, stock brokers, banks, mail-order catalog
companies, travel agencies, and so on, find it useful to record calls
with customers.  With PSTN gateways and RTP this is trivially 
accomplished today.  Tomorrow, where PSTN gateways are replaced
with SIP trunking, and SRTP is preferred over RTP (especially for
transactions with your bank, stockbroker, and doctor), this 
business need will become more difficult to meet.

To meet this need for recording SRTP-encrypted calls, we 
wrote "Disclosing Secure RTP (SRTP) Session Keys with a SIP 
Event Package", draft-wing-sipping-srtp-key-02, abstract:
   Many Secure RTP (SRTP) key exchange mechanisms do not disclose the
   SRTP session keys to intermediate SIP proxies.  However, these key
   exchange mechanisms cannot be used in environments where transcoding,
   monitoring, or call recording are needed.  This document specifies a
   secure mechanism for a cooperating endpoint to disclose its SRTP
   master keys to an authorized party.

If there is sufficient interest I would like to present
draft-wing-sipping-srtp-key-02 at the upcoming SIPPING meeting in Vancouver.

Comments welcome.

-d

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
(Continue reading)

Dean Willis | 24 Nov 2007 02:41
Favicon

Re: SRTP Key Disclosure


On Nov 21, 2007, at 1:17 AM, Dan Wing wrote:
>
> If there is sufficient interest I would like to present
> draft-wing-sipping-srtp-key-02 at the upcoming SIPPING meeting in  
> Vancouver.
>

I concur, but would like to focus the discussion clearly on the  
requirements. Yes, you have a proposed solution, and looking at that  
solution is a good way to understand both the stated and unstated  
requirements you had in mind. Hopefully, that has now given you a  
very good understanding of the requirements.

This is good, because I expect the working group to stumble on the  
solution verbiage unless we have been taken through the requirements  
very carefully.

--
dean

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

Adam Roach | 29 Nov 2007 22:12
Favicon

Re: Re: SRTP Key Disclosure


On 11/23/07 7:41 PM, Dean Willis wrote:
>
> On Nov 21, 2007, at 1:17 AM, Dan Wing wrote:
>>
>> If there is sufficient interest I would like to present
>> draft-wing-sipping-srtp-key-02 at the upcoming SIPPING meeting in 
>> Vancouver.
>>
>
> I concur, but would like to focus the discussion clearly on the 
> requirements.

I agree with Dean.

I have some relatively minor concerns about the way the current document 
uses RFCs 3903 and 3265, but will withhold them until we have a better 
grasp of the problem (there's no use doing a lot of protocol work on a 
solution that may change radically once we understand the real 
requirements).

/a

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

(Continue reading)

peter_blatherwick | 21 Nov 2007 14:26
Favicon

Re: SRTP Key Disclosure


Hi Dan, all,

I have not read this in detail, and unclear if it represents a "right" approach or not, but I do believe the topic deserves discussion.  Since it is flagged -sipping- I assume that's the target WG, and it would not be presented elsewhere.  So, I would support a slice of time in SIPPING if it can be worked.  

-- Peter Blatherwick




"Dan Wing" <dwing <at> cisco.com>

21.11.07 02:17

       
        To:        <sipping <at> ietf.org>
        cc:        ietf-rtpsec <at> imc.org, 'Francois Audet' <audet <at> nortel.com>, "'Fries,        Steffen'" <steffen.fries <at> siemens.com>
        Subject:        [Sipping] SRTP Key Disclosure



Business requirements of some businesses require recording certain
phone calls.  For example, stock brokers, banks, mail-order catalog
companies, travel agencies, and so on, find it useful to record calls
with customers.  With PSTN gateways and RTP this is trivially
accomplished today.  Tomorrow, where PSTN gateways are replaced
with SIP trunking, and SRTP is preferred over RTP (especially for
transactions with your bank, stockbroker, and doctor), this
business need will become more difficult to meet.

To meet this need for recording SRTP-encrypted calls, we
wrote "Disclosing Secure RTP (SRTP) Session Keys with a SIP
Event Package", draft-wing-sipping-srtp-key-02, abstract:
  Many Secure RTP (SRTP) key exchange mechanisms do not disclose the
  SRTP session keys to intermediate SIP proxies.  However, these key
  exchange mechanisms cannot be used in environments where transcoding,
  monitoring, or call recording are needed.  This document specifies a
  secure mechanism for a cooperating endpoint to disclose its SRTP
  master keys to an authorized party.

If there is sufficient interest I would like to present
draft-wing-sipping-srtp-key-02 at the upcoming SIPPING meeting in Vancouver.

Comments welcome.

-d



_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

Gmane