Subject: Re: [AVT] RFC3711/3830 on Key derivation rate signalling

From: Mark Baugher <[email-masked]>
Date: Thu, 12 Oct 2006 08:04:09 -0700

mailman/listinfo/avt</A></DIV></BLOCKQUOTE></DIV><BR></DIV></BLOCKQUOTE></=
BLOCKQUOTE></DIV><BR></BODY></HTML>=

--Apple-Mail-6--155609114--

--===============1949870258==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1949870258==--

---

From: Mark Baugher <[email-masked]>
Date: Thu, 12 Oct 2006 08:04:09 -0700

hi Marc

On Oct 12, 2006, at 7:24 AM, Blommaert, Marc wrote:

> Dear Mark
>
> Thanks for the explanation,
>
> The thing i am concerned with is on the SRTP clients side:  
> According to one interpretation of the RFC a client would default  
> all unknown values and use default values if explicit (or proper)  
> signalling has been omitted. According to another interpretation of  
> the RFC the SRTP client expects proper signalling but receives  
> none, and without that would run into problems.

I don't think this is a problem if we agree that there needs to be  
some other system to establish keys.  I think it's clear that this  
other system needs to define how to encode the various parameters  
that go along with the keys.
>
> Your explenation seems to indicate that the use/context in which  
> SRTP (and according Key management) is used, may (re-)define the  
> default handling e.g. by requiring explicit signalling.

I read the defaults as being the minimal interoperability  
requirements for SRTP systems, what all MUST implement.  We see a  
great variety of key management systems that are designed for  
specific applications such as multicast to large groups, broadcast  
with no back-channel, point-to-point with minimal message exchanges,  
etc.  The text in the SRTP specification that addresses how crypto  
contexts get established should admit systems that do key management  
according to application needs IMHO.  SRTP serves as the media plane  
for a great variety of applications.  I don't think it should have  
much to say about whether the parameters use type/length/value  
encoding, whether the key management encodes default values as zero  
as part of its message exchanges, whether the key management requires  
that every parameter be explicitly signaled or not. etc.  I think  
this flexibility is a good thing.  In developing RFC 4568, for  
example, we concluded that providing the SSRC was a problem in the  
signaling based upon how many RTP implementations function; we want  
to support the "bump-in-the-stack" model and this makes it real  
difficult to install an SSRC in an unaware RTP implementation even  
though RFC 3711 says the SSRC "should" be provided by key management  
in section 8.  It turns out that this is not needed if each sender  
has its own master key and we did that instead.
>
> On the other hand you seem to trust that the default mapping is  
> used in products. In that case the text 'Once the key derivation  
> rate is properly signaled at the start of the session, is very  
> misleading.

Perhaps it is.

Mark
>
> Best Regards
> Marc
>
>
>
> From: Mark Baugher [mailto:[email-masked]]
> Sent: donderdag 12 oktober 2006 15:53
> To: Blommaert, Marc
> Cc: [email-masked]
> Subject: Re: [AVT] RFC3711/3830 on Key derivation rate signalling
>
> Marc,
>
> On Oct 11, 2006, at 8:43 AM, Blommaert, Marc wrote:
>
>> Dear AVT subscribers
>>
>> I have a particular point i would like to be clarify i.e.whether  
>> key derivation rate (::= 0) requires explicit signalling or not.
>
> This is a matter for the key management and outside the scope of  
> RFC 3711.  Somehow keys get established and an SRTP cryptographic  
> context is installed.  The system that installs the keys has rules  
> or policies for how it will handle default values.  The two key  
> management systems for SRTP that I'm familiar with will use a  
> default if the particular value is not signaled.  Generally  
> speaking, it should be possible to install a master key and salt  
> and allow everything else to default to the values of section 8.2  
> in RFC 3711.
>
> Mark
>>
>>
>> First quote from RFC3711
>>
>> "4.3.1 Key Derivation Algorithm
>> Regardless of the encryption or message authenticacribe>
Content-Type: multipart/mixed; boundary="===============2116491139=="
Errors-To: [email-masked]

hi Marc

On Oct 12, 2006, at 7:24 AM, Blommaert, Marc wrote:

> Dear Mark
>
> Thanks for the explanation,
>
> The thing i am concerned with is on the SRTP clients side:  
> According to one interpretation of the RFC a client would default  
> all unknown values and use default values if explicit (or proper)  
> signalling has been omitted. According to another interpretation of  
> the RFC the SRTP client expects proper signalling but receives  
> none, and without that would run into problems.

I don't think this is a problem if we agree that there needs to be  
some other system to establish keys.  I think it's clear that this  
other system needs to define how to encode the various parameters  
that go along with the keys.
>
> Your explenation seems to indicate that the use/context in which  
> SRTP (and according Key management) is used, may (re-)define the  
> default handling e.g. by requiring explicit signalling.

I read the defaults as being the minimal interoperability  
requirements for SRTP systems, what all MUST implement.  We see a  
great variety of key management systems that are designed for  
specific applications such as multicast to large groups, broadcast  
with no back-channel, point-to-point with minimal message exchanges,  
etc.  The text in the SRTP specification that addresses how crypto  
contexts get established should admit systems that do key management  
according to application needs IMHO.  SRTP serves as the media plane  
for a great variety of applications.  I don't think it should have  
much to say about whether the parameters use type/length/value  
encoding, whether the key management encodes default values as zero  
as part of its message exchanges, whether the key management requires  
that every parameter be explicitly signaled or not. etc.  I think  
this flexibility is a good thing.  In developing RFC 4568, for  
example, we concluded that providing the SSRC was a problem in the  
signaling based upon how many RTP implementations function; we want  
to support the "bump-in-the-stack" model and this makes it real  
difficult to install an SSRC in an unaware RTP implementation even  
though RFC 3711 says the SSRC "should" be provided by key management  
in section 8.  It turns out that this is not needed if each sender  
has its own master key and we did that instead.
>
> On the other hand you seem to trust that the default mapping is  
> used in products. In that case the text 'Once the key derivation  
> rate is properly signaled at the start of the session, is very  
> misleading.

Perhaps it is.

Mark
>
> Best Regards
> Marc
>
>
>
> From: Mark Baugher [mailto:[email-masked]]
> Sent: donderdag 12 oktober 2006 15:53
> To: Blommaert, Marc
> Cc: [email-masked]
> Subject: Re: [AVT] RFC3711/3830 on Key derivation rate signalling
>
> Marc,
>
> On Oct 11, 2006, at 8:43 AM, Blommaert, Marc wrote:
>
>> Dear AVT subscribers
>>
>> I have a particular point i would like to be clarify i.e.whether  
>> key derivation rate (::= 0) requires explicit signalling or not.
>
> This is a matter for the key management and outside the scope of  
> RFC 3711.  Somehow keys get established and an SRTP cryptographic  
> context is installed.  The system that installs the keys has rules  
> or policies for how it will handle default values.  The two key  
> management systems for SRTP that I'm familiar with will use a  
> default if the particular value is not signaled.  Generally  
> speaking, it should be possible to install a master key and salt  
> and allow everything else to default to the values of section 8.2  
> in RFC 3711.
>
> Mark
>>
>>
>> First quote from RFC3711
>>
>> "4.3.1 Key Derivation Algorithm
>> Regardless of the encryption or message authentication transform  
>> that is employed (it may be an SRTP pre-defined transform or newly  
>> introduced according to Section 6), interoperable SRTP
>> implementations MUST use the SRTP key derivation to generate  
>> session keys. Once the key derivation rate is properly signaled at  
>> the start of the session, there is no need for extra communication  
>> between the parties that use SRTP key derivation. "
>>
>> Interpretation: Here i assume  ('Properly signalled....') that it  
>> is mandatory to include the key derivation rate in the SRTP policy  
>> (even if a zero derivation rate is intended)
>>
>> From 3.2.1
>>
>> "an integer in the set {1,2,4,...,2^24}, the  
>> "key_derivation_rate", where an unspecified value is treated as  
>> zero. The constraint to be a power of 2 simplifies the session-key  
>> derivation
>> implementation, see Section 4.3."
>>
>>
>>
>> And somewhat further in the RFC:
>>
>> "8.2 Key Management parameters
>> The table below lists all SRTP parameters that key management can  
>> supply. For reference, it also provides a summary of the default  
>> and mandatory-to-support values for an SRTP implementation as  
>> described in Section 5. "
>>
>> "key derivation rate                 0                  0"
>>  Interpretation: Here is coould assume that the default "mandatory- 
>> to-support" rate is Zero But 4.3.1 section suggestes that the  
>> signalling needs to be explicit via SRTP policy.
>>
>>  Also RFC3830 states that Section 6.10.1:
>> "Note that if a Type/Value is not set, the default is used (according
>>    to SRTP's own criteria). Note also that, if "Session Encr. key
>>    length" is set, this should also be seen as the Master key length
>>    (otherwise, the SRTP default Master key length is used)."
>>
>> Summary: Is section 4.3.1 RFC3711 'properly signalled' an unlucky  
>> formulation ? Is default handling used ? If yes what does properly  
>> signalled mean i.e. does
>> the sentence (Once the key derivation rate is properly signaled at  
>> the start of the session) overrule the default handling?
>> The cases i consider
>> a) rate is not contained in the policy --> take Zero (default)  
>> value or case can not happen if explicit signalling is required (???)
>> b) rate is contained in the policy (signalled explicitly)
>>      b1) contained in the set --> take the value as received
>>      b2) not contained in the set  --> Take the Zero (default) value.
>>
>>
>> Best Regards
>> Marc
>>
>>
>>

_______________________________________________
Audio/Video Tr6">the signalling needs to be explicit via =
SRTP policy.</SPAN></PRE></SPAN>  </DD></FONT></FONT><DD><FONT =
size=3D"+0"><FONT size=3D"+0"><FONT color=3D"#0000ff" =
size=3D"2"></FONT></FONT></FONT>=A0</DD></DIV><FONT size=3D"+0"><FONT =
size=3D"+0"><FONT size=3D"2"></FONT>  <DIV><FONT size=3D"2"></FONT><FONT =
size=3D"2"></FONT><FONT size=3D"2"></FONT></DIV><SPAN =
class=3D"556174014-26092006"><PRE>Also RFC3830 states that Section =
6.10.1:</PRE><PRE>"Note that if a Type/Value is not set, the default is =
used (according<BR>=A0=A0 to SRTP's own criteria). Note also that, if =
"Session Encr. key<BR>=A0=A0 length" is set, this should also be seen as =
the Master key length<BR>=A0=A0 (otherwise, the SRTP default Master key =
length is used)."</PRE><PRE>=A0</PRE><PRE>Summary: Is section 4.3.1 =
RFC3711 'properly signalled' an unlucky formulation ? Is default =
handling used ? If yes what does properly signalled mean i.e. does =
</PRE><PRE><SPAN class=3D"327043109-28092006"><FONT face=3D"Arial" =
color=3D"#0000ff" size=3D"2">the sentence=A0(<EM><U><FONT =
color=3D"#000000">Once the key derivation rate is properly signaled at =
the start of the session</FONT></U></EM>) overrule the default handling? =
</FONT></SPAN></PRE><PRE><SPAN class=3D"327043109-28092006"><FONT =
face=3D"Arial" color=3D"#0000ff" size=3D"2">The cases i =
consider</FONT></SPAN></PRE><PRE><DIV dir=3D"ltr" align=3D"left"><SPAN =
class=3D"327043109-28092006"><FONT face=3D"Arial" color=3D"#0000ff" =
size=3D"2">a) <SPAN class=3D"169322415-11102006">rate is </SPAN>not =
contained in the policy --&gt; <SPAN class=3D"169322415-11102006">take =
</SPAN>Zero (default) value<SPAN class=3D"169322415-11102006"> or case =
can not happen if explicit signalling is required =
(???)</SPAN></FONT></SPAN></DIV><DIV dir=3D"ltr" align=3D"left"><SPAN =
class=3D"327043109-28092006"><FONT face=3D"Arial" color=3D"#0000ff" =
size=3D"2">b) <SPAN class=3D"169322415-11102006">rate is =
</SPAN>contained in the policy=A0(signalled =
explicitly)</FONT></SPAN></DIV><DIV dir=3D"ltr" align=3D"left"><SPAN =
class=3D"327043109-28092006"><FONT face=3D"Arial" color=3D"#0000ff" =
size=3D"2">=A0=A0=A0=A0 b1) contained in the set --&gt; take the value =
as received</FONT></SPAN></DIV><DIV dir=3D"ltr" align=3D"left"><SPAN =
class=3D"327043109-28092006"><FONT face=3D"Arial" color=3D"#0000ff" =
size=3D"2">=A0=A0=A0=A0 b2) not=A0contained in the set=A0=A0--&gt; Take =
the Zero (default) value.</FONT></SPAN></DIV><DIV dir=3D"ltr" =
align=3D"left"><SPAN class=3D"327043109-28092006"><FONT face=3D"Arial" =
color=3D"#0000ff" size=3D"2"></FONT></SPAN>=A0</DIV><DIV dir=3D"ltr" =
align=3D"left"><SPAN class=3D"327043109-28092006"><SPAN =
class=3D"169322415-11102006"><FONT face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></FONT></SPAN></SPAN>=A0</DIV><DIV dir=3D"ltr" =
align=3D"left"><SPAN class=3D"327043109-28092006"><SPAN =
class=3D"169322415-11102006"><FONT face=3D"Arial" color=3D"#0000ff" =
size=3D"2">Best Regards</FONT></SPAN></SPAN></DIV><DIV dir=3D"ltr" =
align=3D"left"><SPAN class=3D"327043109-28092006"><SPAN =
class=3D"169322415-11102006"><FONT face=3D"Arial" color=3D"#0000ff" =
size=3D"2">Marc</FONT></SPAN></SPAN></DIV></PRE><PRE>=A0</PRE><PRE> =
</PRE></SPAN></FONT></FONT></FONT>  <DIV><FONT face=3D"Arial" =
size=3D"2"><FONT size=3D"+0"><FONT size=3D"+0"><FONT =
size=3D"2"></FONT></FONT></FONT></FONT>=A0</DIV>  <DIV style=3D"MARGIN: =
0px">_______________________________________________</DIV>  <DIV =
style=3D"MARGIN: 0px">Audio/Video Transport Working Group</DIV>  <DIV =
style=3D"MARGIN: 0px"><A =
href=3D"mailto:[email-masked]">[email-masked]</A></DIV>  <DIV style=3D"MARGIN:=
 0px"><A =
href=3D"https://www1.ietf.org/mailman/listinfo/avt">https://www1.ietf.org/=
mailman/listinfo/avt</A></DIV></BLOCKQUOTE></DIV><BR></DIV></BLOCKQUOTE></=
DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-74--177860111--

---

From: "Blommaert, Marc" <[email-masked]>
Date: Thu, 12 Oct 2006 16:24:28 +0200

Dear Mark

The thing i am concerned with is on the SRTP clients side: According to
one interpretation of the RFC a client would default all unknown values
and use default values if explicit (or proper) signalling has been
omitted. According to another interpretation of the RFC the SRTP client
expects proper signalling but receives none, and without that would run
into problems. 
 
Your explenation seems to indicate that the use/context in which SRTP
(and according Key management) is used, may (re-)define the default
handling e.g. by requiring explicit signalling.
 
On the other hand you seem to trust that the default mapping is used in
products. In that case the text 'Once the key derivation rate is
properly signaled at the start of the session, is very misleading. 
 
Best Regards
Marc

________________________________

Marc, 

	Dear AVT subscribers

This is a matter for the key management and outside the scope of RFC
3711.  Somehow keys get established and an SRTP cryptographic context is
installed.  The system that installs the keys has rules or policies for
how it will handle default values.  The two key management systems for
SRTP that I'm familiar with will use a default if the particular value
is not signaled.  Generally speaking, it should be possible to install a
master key and salt and allow everything else to default to the values
of section 8.2 in RFC 3711.

Mark

	First quote from RFC3711

	"4.3.1 Key Derivation Algorithm 
	Regardless of the encryption or message authentication transform
that is employed (it may be an SRTP pre-defined transform or newly
introduced according to Section 6
<http://www.apps.ietf.org/rfc/rfc3711.html#sec-6> ), interoperable SRTP 
	implementations MUST use the SRTP key derivation to generate
session keys. Once the key derivation rate is properly signaled at the
start of the session, there is no need for extra communication between
the parties that use SRTP key derivation. "

	Interpretation: Here i assume  ('Properly signalled....') that
it is mandatory to include the key derivation rate in the SRTP policy
(even if a zero derivation rate is intended)

	From 3.2.1

	"an integer in the set {1,2,4,...,2^24}, the
"key_derivation_rate", where an unspecified value is treated as zero.
The constraint to be a power of 2 simplifies the session-key derivation 
	implementation, see Section 4.3
<http://www.apps.ietf.org/rfc/rfc3711.html#sec-4.3> ." 

	"8.2 Key Management parameters 
	The table below lists all SRTP parameters that key management
can supply. For reference, it also provides a summary of the default and
mandatory-to-support values for an SRTP implementation as described in
Section 5 <http://www.apps.ietf.org/rfc/rfc3711.html#sec-5> . "

	Interpretation: Here is coould assume that the default
"mandatory-to-support" rate is Zero But 4.3.1 section suggestes that the
signalling needs to be explicit via SRTP policy.

	
	Also RFC3830 states that Section 6.10.1:
	"Note that if a Type/Value is not set, the default is used
(according
	   to SRTP's own criteria). Note also that, if "Session Encr.
key
	   length" is set, this should also be seen as the Master key
length
	   (otherwise, the SRTP default Master key length is used)."
	 
	Summary: Is section 4.3.1 RFC3711 'properly signalled' an
unlucky formulation ? Is default handling used ? If yes what does
properly signalled mean i.e. does 
	the sentence (Once the key derivation rate is properly signaled
at the start of the session) overrule the default handling? 
	The cases i consider
	
	     b2) not contained in the set  --> Take the Zero (default)
value.

	Best Regards
	Marc