Subject: [AVT] draft-ietf-avt-topologies-03.txt

From: David McGrew <[email-masked]>
Date: Tue, 12 Dec 2006 08:59:30 -0800

Hi Magnus and Stephan,

draft-ietf-avt-topologies-03.txt is very useful, thanks for  
undertaking the work.  I have some comments on interactions with the  
Secure RTP profile.  Mark Baugher kindly brought the draft to my  
attention and we had an extended discussion about issues w.r.t. media  
translators and SRTP.  This is a tricky area and I think that it  
would be good to have some explicit guidance.  I suggest replacing  
paragraph 3 of the Security Considerations section with something  
like the following.  The new text is more directive, and it points  
out an architectural implication.

Best regards,

David

--

Transport translators have no interactions with SRTP, since that sort  
of translator leaves the RTP header and payload unaltered.  There are  
no restrictions on how transport translators can be used with SRTP.

Media translators have strong interactions with SRTP, since they  
alter the RTP payload.  A media translator in a session using the  
SRTP profile MUST apply SRTP processing to both inbound and outbound  
RTP and RTCP packets.

A media translator using the SRTP profile MUST use different SRTP  
keys for the inbound and outbound SRTP processing.  This is because  
an RFC 3550 media translator leaves the SSRC unchanged during its  
packet processing, and SRTP key sharing is only allowed when distinct  
SSRCs can be used to protect distinct packet streams.  In an SRTP  
session that includes a media translator, session participants cannot  
rely on the SSRC to identify the SRTP crypto context and master key  
to use when processing an inbound packet, since the translator and  
the original source will use different keys.  Each session  
participant will need to need to be given the appropriate key,  
depending on whether they are listening to the translator or the  
original source.  These keys could be provided by the signaling  
system, or by a multi-party key management system, like Encrypted Key  
Transport (EKT) for SRTP.  (Note that there is an architectural  
difference between RTP media translation, in which participants can  
rely on the RTP Payload Type field of a packet to determine  
appropriate processing, and SRTP media translation, in which  
participants must use on information that is not carried in the packet.)

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Dec 2006 16:58:11 +0100

Hi David,

Thanks for proposing text. However I think this text is taking the 
document in the wrong direction. We need to be general and talk about 
issues that may arise. Sure SRTP is an important security mechanism but 
it is not the only one. I am in fact rather split about providing 
anything more than generic requirements. This is an informational 
document, not a protocol specification document. Thus I would prefer if 
the SRTP specific details ends up in the updated SRTP spec rather then 
here.

Cheers

Magnus

David McGrew skrev:
> Hi Magnus and Stephan,
> 
> draft-ietf-avt-topologies-03.txt is very useful, thanks for undertaking 
> the work.  I have some comments on interactions with the Secure RTP 
> profile.  Mark Baugher kindly brought the draft to my attention and we 
> had an extended discussion about issues w.r.t. media translators and 
> SRTP.  This is a tricky area and I think that it would be good to have 
> some explicit guidance.  I suggest replacing paragraph 3 of the Security 
> Considerations section with something like the following.  The new text 
> is more directive, and it points out an architectural implication.
> 
> Best regards,
> 
> David
> 
> -- 
> 
> Transport translators have no interactions with SRTP, since that sort of 
> translator leaves the RTP header and payload unaltered.  There are no 
> restrictions on how transport translators can be used with SRTP.
> 
> Media translators have strong interactions with SRTP, since they alter 
> the RTP payload.  A media translator in a session using the SRTP profile 
> MUST apply SRTP processing to both inbound and outbound RTP and RTCP 
> packets.
> 
> A media translator using the SRTP profile MUST use different SRTP keys 
> for the inbound and outbound SRTP processing.  This is because an RFC 
> 3550 media translator leaves the SSRC unchanged during its packet 
> processing, and SRTP key sharing is only allowed when distinct SSRCs can 
> be used to protect distinct packet streams.  In an SRTP session that 
> includes a media translator, session participants cannot rely on the 
> SSRC to identify the SRTP crypto context and master key to use when 
> processing an inbound packet, since the translator and the original 
> source will use different keys.  Each session participant will need to 
> need to be given the appropriate key, depending on whether they are 
> listening to the translator or the original source.  These keys could be 
> provided by the signaling system, or by a multi-party key management 
> system, like Encrypted Key Transport (EKT) for SRTP.  (Note that there 
> is an architectural difference between RTP media translation, in which 
> participants can rely on the RTP Payload Type field of a packet to 
> determine appropriate processing, and SRTP media translation, in which 

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
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: David McGrew <[email-masked]>
Date: Thu, 14 Dec 2006 08:53:31 -0800

Hi Magnus,

On Dec 14, 2006, at 7:58 AM, Magnus Westerlund wrote:

> document in the wrong direction. We need to be general and talk  
> about issues that may arise. Sure SRTP is an important security  
> mechanism but it is not the only one. I am in fact rather split  
> about providing anything more than generic requirements. This is an  
> informational document, not a protocol specification document.

yeah, I guess that I got carried away for an informative RFC.  But  
the paragraph that I suggest replacing has a qualified MUST, which  
most readers would not understand.  My goal was to replace it with  
simpler guidance, and I still think that is a worthwhile change.   
Below is a rewrite of my proposal, which makes the guidance more  
generic and which uses only a single unqualified MUST.

<new>
Transport translators have no interactions with cryptography works  
above the transport layer, such as SRTP, since that sort of  
translator leaves the RTP header and payload unaltered.  Media  
translators, on the other hand, have strong interactions with  
cryptography, since they alter the RTP payload.  A media translator  
in a session that uses cryptographic protection will need to perform  
cryptographic processing to both inbound and outbound packets.

A media translator may need to use different cryptographic keys for  
the inbound and outbound processing.  For SRTP, different keys MUST  
be used, because an RFC 3550 media translator leaves the SSRC  
unchanged during its packet processing, and SRTP key sharing is only  
allowed when distinct SSRCs can be used to protect distinct packet  
streams.

When the media translator uses different keys to process inbound and  
outbound packets, each session participant will need to need to be  
given the appropriate key, depending on whether they are listening to  
the translator or the original source.  (Note that there is an  
architectural difference between RTP media translation, in which  
participants can rely on the RTP Payload Type field of a packet to  
determine appropriate processing, and cryptographically protected  
media translation, in which participants must use information that is  
not carried in the packet.)
</new>

What do you think?

> Thus I would prefer if the SRTP specific details ends up in the  
> updated SRTP spec rather then here.

Agreed, that it would be good for the 3711 update to provide the  
guidance on translators and mixers.

David

>> undertaking the work.  I have some comments on interactions with  
>> the Secure RTP profile.  Mark Baugher kindly brought the draft to  
>> my attention and we had an extended discussion about issues w.r.t.  
>> media translators and SRTP.  This is a tricky area and I think  
>> that it would be good to have some explicit guidance.  I suggest  
>> replacing paragraph 3 of the Security Considerations section with  
>> something like the following.  The new text is more directive, and  
>> it points out an architectural implication.
>> Best regards,
>> David
>> -- 
>> Transport translators have no interactions with SRTP, since that  
>> sort of translator leaves the RTP header and payload unaltered.   
>> There are no restrictions on how transport translators can be used  
>> with SRTP.
>> SRTP profile MUST apply SRTP processing to both inbound and  
>> outbound RTP and RTCP packets.
>> keys for the inbound and outbound SRTP processing.  This is  
>> because an RFC 3550 media translator leaves the SSRC unchanged  
>> during its packet processing, and SRTP key sharing is only allowed  
>> when distinct SSRCs can be used to protect distinct packet  
>> streams.  In an SRTP session that includes a media translator,  
>> session participants cannot rely on the SSRC to identify the SRTP  
>> crypto context and master key to use when processing an inbound  
>> packet, since the translator and the original source will use  
>> different keys.  Each session participant will need to need to be  
>> given the appropriate key, depending on whether they are listening  
>> to the translator or the original source.  These keys could be  
>> provided by the signaling system, or by a multi-party key  
>> management system, like Encrypted Key Transport (EKT) for SRTP.   
>> (Note that there is an architectural difference between RTP media  
>> translation, in which participants can rely on the RTP Payload  
>> Type field of a packet to determine appropriate processing, and  
>> SRTP media translation, in which participants must use on  
>> information that is not carried in the packet.)
>
>
> -- 
>
> Magnus Westerlund
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Dec 2006 10:34:45 +0100

David McGrew skrev:
>> issues that may arise. Sure SRTP is an important security mechanism 
>> but it is not the only one. I am in fact rather split about providing 
>> document, not a protocol specification document.
> 
> yeah, I guess that I got carried away for an informative RFC.  But the 
> paragraph that I suggest replacing has a qualified MUST, which most 
> readers would not understand.  My goal was to replace it with simpler 
> guidance, and I still think that is a worthwhile change.  Below is a 
> rewrite of my proposal, which makes the guidance more generic and which 
> uses only a single unqualified MUST.
> 
> <new>
> Transport translators have no interactions with cryptography works above 

I think there is need for a "that" in the above sentence: ... with 
cryptography that works above ...

> the transport layer, such as SRTP, since that sort of translator leaves 
> the RTP header and payload unaltered.  Media translators, on the other 
> hand, have strong interactions with cryptography, since they alter the 
> RTP payload.  A media translator in a session that uses cryptographic 
> protection will need to perform cryptographic processing to both inbound 
> and outbound packets.
> 
> A media translator may need to use different cryptographic keys for the 
> inbound and outbound processing.  For SRTP, different keys MUST be used, 
> because an RFC 3550 media translator leaves the SSRC unchanged during 
> its packet processing, and SRTP key sharing is only allowed when 
> distinct SSRCs can be used to protect distinct packet streams.

I think we could change the MUST to a require. To my understanding the 
normative wording for this is already present in RFC 3711. Thus only 
pointing on the restriction as the above text does would be sufficient. 
The reason is that the proposed MUST would be okay in a standards track 
document. I don't really like it in this informative document. I would 
prefer to be completely without RFC 2119 language. So what about 
changing "MUST be used" to "are required to be used"?

> outbound packets, each session participant will need to need to be given 
> the appropriate key, depending on whether they are listening to the 
> translator or the original source.  (Note that there is an architectural 
> difference between RTP media translation, in which participants can rely 
> on the RTP Payload Type field of a packet to determine appropriate 
> processing, and cryptographically protected media translation, in which 
> participants must use information that is not carried in the packet.)
> </new>
> 
> What do you think?

I do like the text. With the above proposed massages I think it is much 
better than my text. You only intended these paragraphs to replace the 
3rd paragraph?

Cheers

Magnus Westerlund

---

From: David McGrew <[email-masked]>
Date: Wed, 20 Dec 2006 04:41:39 -0800

Hi Magnus,

On Dec 20, 2006, at 1:34 AM, Magnus Westerlund wrote:

>>> Thanks for proposing text. However I think this text is taking  
>>> the document in the wrong direction. We need to be general and  
>>> talk about issues that may arise. Sure SRTP is an important  
>>> security mechanism but it is not the only one. I am in fact  
>>> rather split about providing anything more than generic  
>>> requirements. This is an informational document, not a protocol  
>>> specification document.
>> above

My bad.

>
>> the transport layer, such as SRTP, since that sort of translator  
>> leaves the RTP header and payload unaltered.  Media translators,  
>> on the other hand, have strong interactions with cryptography,  
>> since they alter the RTP payload.  A media translator in a session  
>> that uses cryptographic protection will need to perform  
>> A media translator may need to use different cryptographic keys  
>> for the inbound and outbound processing.  For SRTP, different keys  
>> MUST be used, because an RFC 3550 media translator leaves the SSRC  
>> unchanged during its packet processing, and SRTP key sharing is  
>> only allowed when distinct SSRCs can be used to protect distinct  
>> packet streams.
>
> I think we could change the MUST to a require. To my understanding  
> the normative wording for this is already present in RFC 3711. Thus  
> only pointing on the restriction as the above text does would be  
> sufficient.

Agreed.

> The reason is that the proposed MUST would be okay in a standards  
> track document. I don't really like it in this informative  
> document. I would prefer to be completely without RFC 2119  
> language. So what about changing "MUST be used" to "are required to  
> be used"?

Sure.

>
>> When the media translator uses different keys to process inbound  
>> and outbound packets, each session participant will need to need  
>> to be given the appropriate key, depending on whether they are  
>> listening to the translator or the original source.  (Note that  
>> there is an architectural difference between RTP media  
>> cryptographically protected media translation, in which  
> I do like the text. With the above proposed massages I think it is  
> much better than my text. You only intended these paragraphs to  
> replace the 3rd paragraph?
>

Yes, that's right.

David

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Dec 2006 13:56:22 +0100

David,

Great, I think we are in agreement. We will add this to update coming 
after the last call has ended.

Cheers

Magnus

David McGrew skrev:
>>> leaves the RTP header and payload unaltered.  Media translators, on 
>>> the other hand, have strong interactions with cryptography, since 
>>> they alter the RTP payload.  A media translator in a session that 
>>> uses cryptographic protection will need to perform cryptographic 
>>> processing to both inbound and outbound packets.
>> track document. I don't really like it in this informative document. I 
>> would prefer to be completely without RFC 2119 language. So what about 

-- 

Magnus Westerlund