headers
Dan Wing | 16 Feb 2008 01:12
Picon
Favicon

DTLS-SRTP Key Transport

I just submitted -01 of DTLS-SRTP Key Transport, which allows optimizing SRTP
encryption in several SRTP scenarios.  The changes from -00 to -01 include:

   o  more closely aligned with RTP Topologies [RFC5117]
   o  added multicast scenario
   o  added voicemail storage/retrieval scenario
   o  added delete_srtp_key
   o  added your_new_srtp_key
   o  aligned SDP for DTLS-SRTP with draft-ietf-mmusic-sdp-dtls-00
   o  key change rules are now discussed in Security Considerations

http://www.ietf.org/internet-drafts/draft-wing-avt-dtls-srtp-key-transport-01.
txt

I have requested agenda time in Philadelphia to present this draft to AVT, but
I would also appreciate any comments before then.

Thanks,
-d

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
http://www.ietf.org/mailman/listinfo/avt
Permalink | Reply | 0 comments |
headers
Cullen Jennings | 13 Feb 2008 17:54
Picon
Favicon
Gravatar

Status updated on discussions with 3GPP on RTPSec topics


The SA3 group is looking at the draft-sipping-stucker-media-path- 
middleboxes draft as well as  trying to get us a requirements list of  
which types of media  they would like to secure. My understanding is  
this is targeted around Release 9 work. SA3 is meeting in a few weeks  
and the 3GPP/IETF liaisons will help get information fed back to  
appropriate WG chairs after this.

Cullen <with my RAI AD hat on>
Permalink | Reply | 0 comments |
headers
Martin Vladić | 13 Jan 2008 17:54
Picon

Re: One "record" per datagram when the "use_srtp" extension is in effect


---------- Forwarded message ----------
From: Martin Vladić <martin.vladic <at> gmail.com>
Date: Jan 13, 2008 5:53 PM
Subject: Re: One "record" per datagram when the "use_srtp" extension
is in effect
To: Eric Rescorla <ekr <at> networkresonance.com>

On Jan 13, 2008 4:24 PM, Eric Rescorla <ekr <at> networkresonance.com> wrote:
>
> We want to preserve the one RTP packet in one RTP packet out semantics
> of SRTP.
>

It's not clear to me whether this rule applies to the DTLS handshake
datagrams also. Because, during DTLS handshake multiple DTLS records
may be placed in a single datagram (each record contains DTLS
handshake message or message fragment).

--
Martin
Permalink | Reply | 1 comment |
headers
Martin Vladić | 13 Jan 2008 15:35
Picon

One "record" per datagram when the "use_srtp" extension is in effect


Hi,

I have a question for the authors of draft-ietf-avt-dtls-srtp. In
section 4.1 of this draft it states:

"When the "use_srtp" extension is in effect, implementations MUST NOT
place more than one "record" per datagram. (This is only meaningful
from the perspective of DTLS because SRTP is inherently oriented
towards one payload per packet, but is stated purely for
clarification.)"

For what reason implementations must not place more than one "record"
per datagram?

Thanks,
Martin
Permalink | Reply | 1 comment |
headers
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)

Permalink | Reply | 0 comments |
headers
Dan Wing | 12 Nov 2007 08:22
Picon
Favicon

dtls-srtp-kt


RTPSEC,

DTLS-SRTP-KT proposes a solution to conferencing SRTP sessions for audio
mixers and video switchers to eliminate the need to re-encrypt payloads for
every listener.

Comments welcome.
-d

-----Original Message-----
From: Internet-Drafts <at> ietf.org [mailto:Internet-Drafts <at> ietf.org] 
Sent: Sunday, November 11, 2007 9:00 PM
To: i-d-announce <at> ietf.org
Subject: I-D Action:draft-wing-avt-dtls-srtp-key-transport-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Datagram TLS Secure RTP (DTLS-SRTP) Key Transport
	Author(s)       : D. Wing
	Filename        : draft-wing-avt-dtls-srtp-key-transport-00.txt
	Pages           : 15
	Date            : 2007-11-11

The existing DTLS-SRTP specification allows SRTP keys to be
established between a pair of SRTP endpoints.  However, when there
are more than two participants in an RTP session, DTLS-SRTP is unable
to provide a single key for all of the participants.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Wing | 5 Sep 2007 00:50
Picon
Favicon

Security Analysis of Voice-over-IP Protocols


I expect this paper will be of interest.

  http://www.cyber-ta.org/pubs/shmat_csf071.pdf

-d
Permalink | Reply | 0 comments |
headers
Attila Sipos | 16 Jul 2007 16:38

RE: Sending SIP packet over TCP


If you got socket descriptor 9 when creating the socket, and to
poll you need the socket descriptor (and if you really need to poll)
then poll socket descriptor 9.
Or is this not possible?

Regards,
Attila

-----Original Message-----
From: Rathod Subhashchandra [mailto:rathod <at> tataelxsi.co.in] 
Sent: 16 July 2007 15:15
To: sip <at> ietf.org
Cc: ietf-rtpsec <at> imc.org
Subject: [Sip] Sending SIP packet over TCP

Hi Guys,

I am facing a problem in following scenario on WinCE 5.0. Please let me
know if you got an answer for this ASAP.

In SIP Client
1.  I have opened server TCP and UDP on 5060 port for polling responses
aswell as request 2.  To send a SIP packet, I have opened a TCP client
socket 5060 for destination. I got a socket descriptor as 9

SIP request goes on dest port as 5060, src port as 1997.
Server is responding on src port 1997. Hence my polling is failing as it
is for TCP and UDP sockets.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rathod Subhashchandra | 16 Jul 2007 16:14
Picon

Sending SIP packet over TCP

Hi Guys,

I am facing a problem in following scenario on WinCE 5.0. Please let me know if you got an answer for this ASAP.

In SIP Client
1.  I have opened server TCP and UDP on 5060 port for polling responses aswell as request
2.  To send a SIP packet, I have opened a TCP client socket 5060 for destination. I got a socket descriptor as 9

SIP request goes on dest port as 5060, src port as 1997.
Server is responding on src port 1997. Hence my polling is failing as it is for TCP and UDP sockets.

Src port 1997 is not constant. It is just random. for me to poll, I need socket descriptor. How to get this
logical port number given TCP? If I can get this, I can create a socket and get the descriptor and add to
polling list

Waiting a quick response if possible.

Thanks !
Rathod.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 0 comments |
headers
Dan Wing | 10 Jul 2007 09:31
Picon
Favicon

FW: [MMUSIC] ICE-TCP issue: DTLS-SRTP over TCP?


> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen <at> cisco.com] 
> Sent: Monday, July 09, 2007 1:15 PM
> To: IETF MMUSIC WG
> Cc: 'avt <at> ietf.org'
> Subject: [MMUSIC] ICE-TCP issue: DTLS-SRTP over TCP?
> 
> My apologies for cc'ing AVT. However this is a cross-WG issue that 
> impacts ICE and its usage with DTLS-SRTP.
> 
> ICE-tcp:
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-04.txt
> DTLS-srtp:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-dtls-srtp-00.txt
> 
> 
> One of the really nice features of ICE-tcp is that you can 
> offer, for an 
> RTP-based media stream, either UDP or TCP candidates. The TCP 
> ones are 
> tried as a last resort, so that you get RTP over UDP when it 
> works, and 
> RTP over TCP when it doesn't. This choice is made dynamically 
> based on 
> the results of the connectivity checks.
> 
> So, the interesting question is, what happens if the media is secure? 
> Well, clearly if UDP is selected, we end up with DTLS-SRTP. In that 
> case, the SDP offer would contain the fingerprint and setup
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Wing | 4 Jul 2007 19:37
Picon
Favicon

FW: IPR Statement RE: draft-wing-sip-identity-media-00.txt

> -----Original Message-----
> From: Rachel Albright [mailto:ralbrigh <at> cisco.com] 
> Sent: Monday, July 02, 2007 1:03 PM
> To: ietf-ipr <at> ietf.org
> Cc: dwing <at> cisco.com
> Subject: IPR Statement RE: draft-wing-sip-identity-media-00.txt
> 
> Cisco is the owner of one or more pending unpublished patent 
> applications relating to the subject matter of "SIP Identity 
> using Media Path" <draft-wing-sip-identity-media-00.txt>. 
>  
> If technology in this document is included in a standard 
> adopted by IETF and any claims of any Cisco patents are 
> necessary for practicing the standard, any party will have 
> the right to use any such patent claims under reasonable, 
> non-discriminatory terms, with reciprocity, to implement and 
> fully comply with the standard.
>  
> The reasonable non-discriminatory terms are:
>  
> If this standard is adopted, Cisco will not assert any 
> patents owned or controlled by Cisco against any party for 
> making, using, selling, importing or offering for sale a 
> product that implements the standard, provided, however that 
> Cisco retains the right to assert its patents (including the 
> right to claim past royalties) against any party that asserts 
> a patent it owns or controls (either directly or indirectly) 
> against Cisco or any of Cisco's affiliates or successors in 
> title or against any products of Cisco or any products of any 
> of Cisco's affiliates either alone or in combination with
(Continue reading)

Permalink | Reply | 0 comments |

Gmane