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

From: "Blommaert, Marc" <[email-masked]>
Date: Wed, 11 Oct 2006 17:43:55 +0200

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. 

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> ." 

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 <http://www.apps.ietf.org/rfc/rfc3711.html#sec-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 Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Mark Baugher <[email-masked]>
Date: Thu, 12 Oct 2006 06:52:53 -0700

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
> 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
>
> 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."
>
>
>
> 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. "
>
> Interpretation: Here is coould assume that the default "mandatory- 
> to-support" rate is Zero But 4.3.1 section suggestes that the  
> 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 (???)

---

From: Mats Näslund (KI/EAB) <[email-masked]>
Date: Thu, 12 Oct 2006 21:00:59 +0200

Hi

I agree Mark, but still one can ask why the key derivation rate is the _only_ parameter for which we talk about being "properly signaled". After all, there are many parameters for which we define a default, yet for these we do not highlight the issue of "proper signaling".
 
I tried to search my memory from the spec. drafting days for a reason, and here is my best guess:
 
The derivation rate is relevant for the key refresh mechanism.
 
If key derivation rate is zero (the default) the whole key refresh is "bypassed" since only one initial derivation takes place (this is the effect of the way we define DIVIDE-BY-ZERO). Thus, if one only supports the default value, one can basically omit all the "<index> DIV <derivation_rate>" stuff and get a somewhat simpler implementation. Thus, while the normative text indeed works for _any_ value of the derivation rate (zero or nonzero), it is only when it is "properly" (= non-default) signaled that one really needs to care about using the parameter at all.
 
For all other SRTP-parameters, using the default values does not have the same "function bypass" effect, and that is probably why their proper signaling is not mentioned.
 
Perhaps it would have been better to say "...once derivation rate is _explicitly_ signaled"... I don't know...
 
Anyway, this is my (probable) explanation for why we mentioned this in the RFC.
 
/Mats

________________________________

	From: Mark Baugher [mailto:[email-masked]] 
	Sent: den 12 oktober 2006 15:53
	To: Blommaert, Marc
	Cc: [email-masked]
	Subject: Re: [AVT] RFC3711/3830 on Key derivation rate signalling 

	Marc, 

		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 <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.

		
		 
		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

---

From: Mark Baugher <[email-masked]>
Date: Thu, 12 Oct 2006 14:15:00 -0700

hi Mats,
On Oct 12, 2006, at 12:00 PM, Mats Näslund (KI/EAB) wrote:

> Hi
>
>
> I agree Mark, but still one can ask why the key derivation rate is  
> the _only_ parameter for which we talk about being "properly  
> signaled". After all, there are many parameters for which we define  
> a default, yet for these we do not highlight the issue of "proper  
> signaling".

I just assumed that it was an artifact of the writing committee and  
harried editing.
>
> I tried to seFrom [email-masked] Fri Oct 13 02:44:03 2006
From: Mark Baugher <[email-masked]>
Subject: Re: [AVT] RFC3711/3830 on Key derivation rate signalling 
Date: Thu, 12 Oct 2006 14:15:00 -0700
To: =?ISO-8859-1?Q?Mats_Näslund_(KI/EAB)?= <[email-masked]>
Cc: IETF AVT WG <[email-masked]>

hi Mats,
On Oct 12, 2006, at 12:00 PM, Mats Näslund (KI/EAB) wrote:

> Hi
>
>
> I agree Mark, but still one can ask why the key derivation rate is  
> the _only_ parameter for which we talk about being "properly  
> signaled". After all, there are many parameters for which we define  
> a default, yet for these we do not highlight the issue of "proper  
> signaling".

I just assumed that it was an artifact of the writing committee and  
harried editing.
> If key derivation rate is zero (the default) the whole key refresh  
> is "bypassed" since only one initial derivation takes place (this  
> is the effect of the way we define DIVIDE-BY-ZERO). Thus, if one  
> only supports the default value, one can basically omit all the  
> "<index> DIV <derivation_rate>" stuff and get a somewhat simpler  
> implementation. Thus, while the normative text indeed works for  
> _any_ value of the derivation rate (zero or nonzero), it is only  
> when it is "properly" (= non-default) signaled that one really  
> needs to care about using the parameter at all.

This sounds like a very plausible explanation to me.
>
> For all other SRTP-parameters, using the default values does not  
> have the same "function bypass" effect, and that is probably why  
> their proper signaling is not mentioned.
>
> Perhaps it would have been better to say "...once derivation rate  
> is _explicitly_ signaled"... I don't know...

I personally think it's fine.  There are no MUSTs, SHALLs, MAYs or  
SHOULDs surrounding the text.  But I shouldn't criticizing others'  
readings - there are at least a few things in that spec that we know  
are confusing.

Mark
> 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
>>
>> "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
>> signalling needs to be explicit varch my memory from the spec. drafting days for a  
> reason, and here is my best guess:
>
> If key derivation rate is zero (the default) the whole key refresh  
> is "bypassed" since only one initial derivation takes place (this  
> is the effect of the way we define DIVIDE-BY-ZERO). Thus, if one  
> only supports the default value, one can basically omit all the  
> "<index> DIV <derivation_rate>" stuff and get a somewhat simpler  
> implementation. Thus, while the normative text indeed works for  
> _any_ value of the derivation rate (zero or nonzero), it is only  
> when it is "properly" (= non-default) signaled that one really  
> needs to care about using the parameter at all.

This sounds like a very plausible explanation to me.
>
> For all other SRTP-parameters, using the default values does not  
> have the same "function bypass" effect, and that is probably why  
> their proper signaling is not mentioned.
>
> Perhaps it would have been better to say "...once derivation rate  
> is _explicitly_ signaled"... I don't know...

I personally think it's fine.  There are no MUSTs, SHALLs, MAYs or  
SHOULDs surrounding the text.  But I shouldn't criticizing others'  
readings - there are at least a few things in that spec that we know  
are confusing.

Mark
> 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
>>
>> "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