Subject: [AVT] Changes in draft-ietf-avt-2833bis-13.txt

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 08 May 2006 23:13:32 -0400

I have submitted an update to draft-ietf-avt-2833bis. It contains the 
following changes.

Abstract
--------
Added sentences indicating what was done with the RFC 2833 event codes, 
in response to Sasha Vainshtein's intervention. Reorganized the existing 
content to flow more smoothly given this change.

Second paragraph of section 1.2 "Overview"
------------------------------------------
Deleted "MIME" in front of "media type registrations" in the existing 
last sentence. Added a new sentence pointing to Appendix A, which lists 
the changes from RFC 2833.

Section 6 "Security Considerations"
-----------------------------------
Added the following text based on comments from Pekka Nikander and 
Magnus Nyström, and reorganized existing text to flow more smoothly into 
it. Added RFC 3711 as a normative reference.

"The telephony-event payload defined in this specification is highly 
compressed. An interchange of just two bits can result in a major change 
in meaning as decoded at the receiver. Thus the telephony-event payload 
type is in particular need of protection of integrity.

"To meet the need for protection both of confidentiality and integrity, 
this specification requires that compliant implementations also 
implement the Secure Real-time Transport Protocol (SRTP) [RFC3711].

"  Note that the appropriate method of key distribution for SRTP
    may vary with the specific application."

Section 9.1 "Normative References"
----------------------------------
Added RFC 3711 (SRTP), as indicated above.

Updated the media type registration procedure reference (was "RFC TBD") 
to point to RFC 4288.

Section 9.2 "Informative References"
------------------------------------
Added references to 2833bisdata and 2833biscas as Works In Progress.

Appendix A (new)
----------------
Describes the differences between RFC 2833 and 2833bis. Includes a table 
indicating what happened to the event codes defined in RFC 2833.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 8 May 2006 20:51:01 -0700

Thank you.

On May 8, 2006, at 8:13 PM, Tom-PT Taylor wrote:

> I have submitted an update to draft-ietf-avt-2833bis. It contains  
> the following changes.
>
> Abstract
> --------
> Added sentences indicating what was done with the RFC 2833 event  
> codes, in response to Sasha Vainshtein's intervention. Reorganized  
> the existing content to flow more smoothly given this change.
>
> Deleted "MIME" in front of "media type registrations" in the  
> existing last sentence. Added a new sentence pointing to Appendix  
> A, which lists the changes from RFC 2833.
>
> Magnus Nyström, and reorganized existing text to flow more smoothly  
> into it. Added RFC 3711 as a normative reference.
>
> "The telephony-event payload defined in this specification is  
> highly compressed. An interchange of just two bits can result in a  
> major change in meaning as decoded at the receiver. Thus the  
> telephony-event payload type is in particular need of protection of  
> integrity.
>
> "To meet the need for protection both of confidentiality and  
> integrity, this specification requires that compliant  
> implementations also implement the Secure Real-time Transport  
> Protocol (SRTP) [RFC3711].
>
> Updated the media type registration procedure reference (was "RFC  
> TBD") to point to RFC 4288.
>
> Describes the differences between RFC 2833 and 2833bis. Includes a  
> table indicating what happened to the event codes defined in RFC 2833.

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 9 May 2006 08:18:21 +0300

> Section 6 "Security Considerations"

Looks good enough to me, other than that instead of "An interchange  
of just two bits..." I would write "A flip of just one bit from one  
to zero or vice versa ...".

As I mentioned in my review, if a stream cipher is used to protect  
the confidentiality of the data, if an attacker knows the structure  
of the data, they can change the value of any single bit.  Such a  
change cannot be detected unless some integrity protection mechanism  
is used.  Especially, a linear or cyclic checksum is _not_ good  
enough, as the attacker can anticipate the effect of bit flipping to  
the checksum and send a few variants of the modified packet, with a  
high probability of having one of them to decipher with the correct  
checksum.

This problem is not so bad if a block cipher is used, but as far as I  
understand, media streams are quite often protected with stream  
ciphers.  OTOH, I don't know what people usually use with SRTP.

>    may vary with the specific application."

Ok from my point of view.

--Pekka Nikander

---

From: Magnus Nyström <[email-masked]>
Date: Tue, 9 May 2006 10:39:38 +0200 (W. Europe Daylight Time)

Thanks for this, Tom.

I have one comment. You write:

> "To meet the need for protection both of confidentiality and integrity, this 
> specification requires that compliant implementations also implement the 
> Secure Real-time Transport Protocol (SRTP) [RFC3711].

If this is a normative statement (and it looks like it), perhaps it should 
be rephrased to:

"To meet the need for protection both of confidentiality and integrity, 
compliant implementations MUST also implement [or support] the Secure 
Real-time Transport Protocol (SRTP) [RFC3711]."

-- Magnus

On Mon, 8 May 2006, Tom-PT Taylor wrote:

> Added sentences indicating what was done with the RFC 2833 event codes, in 
> response to Sasha Vainshtein's intervention. Reorganized the existing content 
> to flow more smoothly given this change.
>
> Deleted "MIME" in front of "media type registrations" in the existing last 
> sentence. Added a new sentence pointing to Appendix A, which lists the 
> changes from RFC 2833.
>
> Added the following text based on comments from Pekka Nikander and Magnus 
> Nyström, and reorganized existing text to flow more smoothly into it. Added 
> RFC 3711 as a normative reference.
>
> compressed. An interchange of just two bits can result in a major change in 
> meaning as decoded at the receiver. Thus the telephony-event payload type is 
> in particular need of protection of integrity.
>
> "To meet the need for protection both of confidentiality and integrity, this 
> specification requires that compliant implementations also implement the 
> Secure Real-time Transport Protocol (SRTP) [RFC3711].
>
> Updated the media type registration procedure reference (was "RFC TBD") to 
> point to RFC 4288.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 09 May 2006 11:22:11 +0200

Magnus Nyström wrote:
>> integrity, this specification requires that compliant implementations 
>> also implement the Secure Real-time Transport Protocol (SRTP) [RFC3711].
> 
> If this is a normative statement (and it looks like it), perhaps it 
> should be rephrased to:
> 

Hi Magnus,

There is one problem with mandating SRTP as the security mechanism. It 
is not suitable for all deployment scenarios that RTP is used in. Due to 
this we have been very cautious to mandate. We gladly recommend SRTP as 
it works in most deployments. RTPs wide deployment potential do create 
an issue here.

I think we are getting to a situation where we might need to clarify the 
usage of security mechanism for RTP and for which cases they are 
suitable to adapt for different applications.

cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 09 May 2006 09:36:42 -0400

Magnus Nyström is correct as far as my intent was concerned -- I goofed. 
However, I think I'll keep my head down while the broader issues are 
thrashed out. I do think, now that I've looked at it, that the Security 
Considerations section of RFC 3550 could have been more thoroughly 
developed, but as a member of the AVT WG, I have to take some 
responsibility for that.

Earlier in this thread Magnus W. mentioned 
draft-westerlund-avt-rtp-howto-00. I'll try to contribute when that is 
reissued, to make amends for my earlier neglect.

Magnus Westerlund wrote:
>> integrity, compliant implementations MUST also implement [or support] 
>> the Secure Real-time Transport Protocol (SRTP) [RFC3711]."
>>
> 
> Hi Magnus,
>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 9 May 2006 14:49:01 +0100

I agree with Magnus Westerlund: it makes sense to say one SHOULD  
implement SRTP, since it provides appropriate security for many  
environments, but we cannot absolutely mandate it, since there are  
valid uses of RTP where SRTP isn't the right security solution.

Colin

On 9 May 2006, at 14:36, Tom-PT Taylor wrote:
> Magnus Nyström is correct as far as my intent was concerned -- I  
> goofed. However, I think I'll keep my head down while the broader  
> issues are thrashed out. I do think, now that I've looked at it,  
> that the Security Considerations section of RFC 3550 could have  
> been more thoroughly developed, but as a member of the AVT WG, I  
> have to take some responsibility for that.
>
> Earlier in this thread Magnus W. mentioned draft-westerlund-avt-rtp- 
> howto-00. I'll try to contribute when that is reissued, to make  
> amends for my earlier neglect.
>
> Magnus Westerlund wrote:
>> Magnus Nyström wrote:
>>> Thanks for this, Tom.
>>>
>>> If this is a normative statement (and it looks like it), perhaps  
>>> it should be rephrased to:
>>>
>>> integrity, compliant implementations MUST also implement [or  
>>> support] the Secure Real-time Transport Protocol (SRTP) [RFC3711]."
>>>
>> Hi Magnus,
>> There is one problem with mandating SRTP as the security  
>> mechanism. It is not suitable for all deployment scenarios that  
>> RTP is used in. Due to this we have been very cautious to mandate.  
>> We gladly recommend SRTP as it works in most deployments. RTPs  
>> wide deployment potential do create an issue here.
>> I think we are getting to a situation where we might need to  
>> clarify the usage of security mechanism for RTP and for which  
>> cases they are suitable to adapt for different applications.
>> cheers
>> Magnus Westerlund

---

From: David R Oran <[email-masked]>
Date: Tue, 9 May 2006 10:15:09 -0400

> valid uses of RTP where SRTP isn't the right security solution.
I agree in general, but I'm having a hard time coming up with a use  
case where one is using rfc2833 (which goes to great lengths to save  
bandwidth) and where another security approach would be superior to  
SRTP. However, I don't think this is worth obsessing over given how  
much attention imlementors and deployers aFrom [email-masked] Tue May 09 11:19:42 2006
Date: Tue, 9 May 2006 07:31:09 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Subject: [AVT] Call for Papers || ICSEA 2006 || ICSNS 2006 || Tahiti,
 October 29 - November 4, 2006

Apologies if you receive multiple copies
 
========================== 
CALL FOR PAPERS
 
International Conference on Software Engineering Advances, ICSEA 2006 
October 29 -November 1, 2006, Tahiti.
 
Call for Papers: http://www.iaria.org/conferences/CfPICSEA06.html
Submission: Go to http://www.iaria.org/conferences/ICSEA06.html and click "Submit a paper"

Deadlines:
Submission deadline: June 1, 2006
Notification: July 1, 2006
Camera ready: July 15, 2006 

The conference has the following tracks:

Track 1
  Advances in fundamentals for software development 
 
Track 2
  Advanced mechanisms for software development 
 
Track 3
  Advanced design tools for developing software 
 
Track 4
  Advanced facilities for accessing software 
 
Track 5
  Software performance 
 
Track 6
  Software security, privacy, safeness
 
Track 7
  Advances in software testing
 
Track 8
  Specialized software advanced applications 
 
Track 9
  Open source software 
 
Track 10
  Agile software techniques 
 
Track 11
  Software deployment and maintenance 
 
Track 12
  Software economics, adoption, and education
 
========================== 
CALL FOR PAPERS
 
International Conference on  Systems and Networks Communications, ICSNC 2006 
November 2 - November 4, 2006, Tahiti.
 
Call for Papers: http://www.iaria.org/conferences/CfPICSNC06.html
Submission: Go to http://www.iaria.org/conferences/ICSNC06.html and click "Submit a paper"

Deadlines:
Submission deadline: June 1, 2006
Notification: July 1, 2006
Camera ready: July 15, 2006 

The conference has the following specialized topics (mini-conferences): 

WINET 2006       Wireless networks                            

HSNET 2006       High speed networks                            

SENET 2006       Sensor networks

MHNET 2006     Mobile and Ad hoc networks                

SESYS 2006       Security systems

MCSYS 2006      Multimedia communications systems   

POSYS 2006       Policy-based systems                           ctually pay to the nuances  
of these things.

Perhaps what we need to say is that the rfc2833 stream MUST have some  
form of secure integrity protection, SHOULD have encryption where  
sensitive data is carried (e.g. PINs as DTMF) and that SRTP is a  
natural fit for both of these functions.

Dave.

>> Earlier in this thread Magnus W. mentioned draft-westerlund-avt- 
>> rtp-howto-00. I'll try to contribute when that is reissued, to  
>> make amends for my earlier neglect.
>>
>> Magnus Westerlund wrote:
>>> Magnus Nyström wrote:
>>>> Thanks for this, Tom.
>>>>
>>> RTP is used in. Due to this we have been very cautious to  
>>> mandate. We gladly recommend SRTP as it works in most  
>>> deployments. RTPs wide deployment potential do create an issue here.

 

PESYS 2006        Pervasive education systems      

========================= 
 
Looking for your submissions.
For more information: [email-masked] 

==========================
To be removed from this announcement list, please reply to this email with UNSUBSCRIBE in the subject line.

---

From: David R Oran <[email-masked]>
Date: Tue, 9 May 2006 10:15:09 -0400

much attention imlementors and deployers actually pay to the nuances  
of these things.

Dave.

---

From: Colin Perkins <[email-masked]>
Date: Tue, 9 May 2006 16:17:03 +0100

On 9 May 2006, at 15:15, David R Oran wrote:
> case where one is using rfc2833 (which goes to great lengths to  
> save bandwidth) and where another security approach would be  
> superior to SRTP. However, I don't think this is worth obsessing  
> over given how much attention imlementors and deployers actually  
> pay to the nuances of these things.

I'm not sure I can see superior alternatives, but I wouldn't want to  
prohibit use of IPsec or DTLS if they were suitable for the environment.

> Perhaps what we need to say is that the rfc2833 stream MUST have  
> some form of secure integrity protection, SHOULD have encryption  
> where sensitive data is carried (e.g. PINs as DTMF) and that SRTP  
> is a natural fit for both of these functions.

That's a good phrasing, and in-line with previous payload formats.

Colin

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 09 May 2006 17:05:27 -0400

Particularly since it is pretty clear that even a willing implementor 
would find it very difficult today to build an interoperable system that 
does SRTP key exchange. See the report from the last SIPit for some 
evidence, as well as the various discussions in the IETF of how to 
address this problem. Mandating security that isn't ready for prime time 
seems kind of bold...

Brian Rosen wrote:
> I don't really know why I suddenly find myself in "what reality are you in
> now?" mode, but the idea that anything over, say .1% of the SIP user agents
> who implement 2833bis providing any sort of integrity protection outside of
> the actual codec (the MUST) strikes me as more than a little wishful
> thinking.
> 
> This is like marking a piece of dual carriage, limited access roadway with a
> 15KM speed limit.  Yes, you can do that.  Yes, some law abiding citizens
> will obey.  No, you won't get the behavior you are looking for in general.
> 
> I fully understand why we feel MUST is appropriate.  If I got to wave a
> magic wand, I'd MUST a lot of security things into reality.  There is no
> magic wand.  It isn't going to get implemented, MUST or no MUST.
> 
> If we were serious about it, we would define THE CODEC with integral
> integrity protection.  That would have a much better chance of getting
> implemented.
> 
> Now, I really, really, really would be tickled pink if SRTP was widely
> implemented and widely deployed.  But I don't see that reality happening any
> time soon, and MUSTing integrity protection here is, I think, pointless.
> 
> Unless of course we have an RFP in development for the protocol police
> 
> Brian
> 
> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]] 
> Sent: Tuesday, May 09, 2006 11:17 AM
> To: David R Oran
> Cc: Cullen Jennings; Magnus Westerlund; Pekka Nikander; IETF AVT WG; Tom-PT
> Taylor; Michael A. Patton; [email-masked]; Sasha Vainshtein; Henning
> Schulzrinne
> Subject: Re: [AVT] Re: Changes in draft-ietf-avt-2833bis-13.txt
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 9 May 2006 16:59:36 -0400

Brian

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Tuesday, May 09, 2006 11:17 AM
To: David R Oran
Cc: Cullen Jennings; Magnus Westerlund; Pekka Nikander; IETF AVT WG; Tom-PT

Colin

---

From: Colin Perkins <[email-masked]>
Date: Wed, 17 May 2006 12:14:09 +0100

Okay, to summarise: there appears to be push back against making  
integrity protection via SRTP a "MUST" strength requirement. This is  
because:

1) SRTP keying is still in a state of flux, which makes  
implementation difficult

2) there are valid alternative architectures which do not use SRTP  
but which can provide appropriate security/integrity protection (e.g.  
with IPsec or DTLS)

As a result, I believe the draft needs revision to make SRTP a  
"SHOULD" level requirement.

Does this accurately state the consensus?

Colin

On 9 May 2006, at 22:05, Henning Schulzrinne wrote:
> Particularly since it is pretty clear that even a willing  
> implementor would find it very difficult today to build an  
> interoperable system that does SRTP key exchange. See the report  
> from the last SIPit for some evidence, as well as the various  
> discussions in the IETF of how to address this problem. Mandating  
> security that isn't ready for prime time seems kind of bold...
>
> Brian Rosen wrote:
>> From: Colin Perkins [mailto:[email-masked]] Sent: Tuesday, May  
>> 09, 2006 11:17 AM
>> To: David R Oran
>>>> I agree with Magnus Westerlund: it makes sense to say one  
>>>> SHOULD  implement SRTP, since it provides appropriate security  
>>>> for many  environments, but we cannot absolutely mandate it,  
>>>> since there are  valid uses of RTP where SRTP isn't the right  
>>>> security solution.
>>>>
>>> I agree in general, but I'm having a hard time coming up with a  
>>> use  case where one is using rfc2833 (which goes to great lengths  
>>> to  save bandwidth) and where another security approach would be   
>> I'm not sure I can see superior alternatives, but I wouldn't want  
>> to  prohibit use of IPsec or DTLS if they were suitable for the  
>> environment.
>>> where sensitive data is carried (e.g. PINs as DTMF) and that  
>>> SRTP  is a natural fit for both of these functions.

---

From: David R Oran <[email-masked]>
Date: Wed, 17 May 2006 09:30:07 -0400

On May 17, 2006, at 7:14 AM, Colin Perkins wrote:

> integrity protection via SRTP a "MUST" strength requirement. This  
> is because:
>
> but which can provide appropriate security/integrity protection  
> (e.g. with IPsec or DTLS)
>
I'm OK with this.

>>>> use  case where one is using rfc2833 (which goes to great  
>>>> lengths to  save bandwidth) and where another security approach  
>>>> would be  superior to SRTP. However, I don't think this is worth  
>>>> obsessing  over given how much attention imlementors and  
>>>> deployers actually  pay to the nuances of these things.
>>>> Perhaps what we need to say is that the rfc2833 stream MUST  
>>>> have  some form of secure integrity protection, SHOULD have  
>>>> encryption  where sensitive data is carried (e.g. PINs as DTMF)  
>>>> and that SRTP  is a natural fit for both of these functions.