Subject: RE: [AVT] Secure RTP Frequently Asked Questions

From: "Usha Sharma" <[email-masked]>
Date: Thu, 27 Oct 2005 11:28:23 -0700

Hi David

This is very comprehensive information for SRTP. 
For Q11, about the length of MKI, I guess the SDP allows maximum length
of MKI to be 128 bytes instead of 64 bytes.

I have a few other questions regarding the use of AES_CM for encryption
and key generation.

You mentioned that AES_CM does not require padding. Hardware encryption
engines such as (broadcom) BCM5812 require that the input to the
encryption/decryption block should be a multiple of block size. Isn't
that equivalent to mandatory padding? In that case, how do we
interoperate with a device which does encryption w/o padding? (How do we
decrypt the data using BCM5812, which is not a multiple of block size)

Another doubt is about the key derivation using AES_CM. 
The input to the AES_CM PRF is master key (16 byte) and IV (14+2=16
byte). Is this function similar to generating a random number and then
encrypting it using AES_CM with master key and IV! Or is it a fixed
number (which one?) which gets encrypted using AES_CM with master key
and IV.
Can we deterministically generate such a number on both sender and
receiver side as only the master key is known to both sides. Is there
any example code available to generate the session keys.

Thanks a lot
Usha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David A. McGrew
Sent: Wednesday, October 26, 2005 11:49 AM
To: SRTP; AVT
Subject: [AVT] Secure RTP Frequently Asked Questions

Hello,

Mark, Mats, Karl, and I put together an FAQ based on questions that  
we're received about RFC 3711.  It's available online at http:// 
srtp.sourceforge.net/faq.html.

David

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

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

---

From: "David A. McGrew" <[email-masked]>
Date: Thu, 27 Oct 2005 12:17:11 -0700

Usha,

> of MKI to be 128 bytes instead of 64 bytes.

yes, thanks for the correction.

> that equivalent to mandatory padding?

Yes.  It sounds like a limitation of the encryption device; it may  
not natively support counter mode.  Or perhaps it has API quirks in  
how it supports counter mode.

> In that case, how do we

If it doesn't support counter mode, then you will want to implement  
counter mode on top of ECB mode.  One way to do this is to write the  
counters that would be used by counter mode into a data buffer, then  
pass that buffer to the crypto engine to be ECB-mode encrypted.  Then  
take the resulting ciphertext, and exor that into the plaintext.

> number (which one?) which gets encrypted using AES_CM with master key

I'm not sure exactly what you mean.  Have you looked over RFC 3550,  
Appendix B.3, "Key Derivation Test Vectors"?

> any example code available to generate the session keys.

Sure, check out http://srtp.sourceforge.net/srtp.html.

> Usha

You're welcome, and I hope this is useful,

David

> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> Srtp-users mailing list
> [email-masked]
> https://lists.sourceforge.net/lists/listinfo/srtp-users
>

---

From: Mats Näslund <[email-masked]>
Date: Thu, 27 Oct 2005 21:31:20 +0200

Hi,

David A. McGrew wrote:

[snip]

> Appendix B.3, "Key Derivation Test Vectors"?

If I understand the question, Usha wonders what we mean when we say that
"AES_CM is used to derive keys", since AES_CM is an *encryption*
algorithm and not really a "key derivation algorithm", is that a correct
interpretation?

If so, you should view it as follows:

1. Take the inputs to AES_CM (the master key and salt as you mention).
2. Run AES_CM to encrypt the all-zero message (000.....0).
3. Use the produced "ciper text" as session key.

So, you could view it as encrypting the value 000....

Put differently, you use AES_CM to generate key stream, but you
really don't encrypt anything with it.

Hope that was a correct interpreation, if not, please clarify and we 
will try to answer.

Best,

/Mats

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 27 Oct 2005 17:10:26 -0700

Hi David,

Just had a chance to quickly read the SRTP FAQ that you and the other 
authors of 3711 put together.  Thanks.  I do have a request for further 
clarification on Q8 on the MKI field use, specifically on the following text:

"For large video packets, however, some vendors may choose to use the MKI 
to convey additional information (see the answer about MKI length 
<http://srtp.sourceforge.net/faq.html#MKI-length>below), and this is 
analogous to features found in some of the proprietary conditional access 
systems today. "

Are you advocating that the MKI field may be used to convey information 
other than a key identifier?  I think the properties of the MKI field make 
it inappropriate (no integrity protection, since if used correctly none is 
needed) yet very attractive (variable length) to overload it.

I was wondering if you can provide references to where that field is being 
used to convey information other than a key ID.  Thanks in advance.

I was pointed to the 3GPP2 BCMCS specification which uses the MKI field as 
follows:

The Master Key Index (MKI) shall be used for distributing the SK_RAND2. The 
MKI shall be 72
bits and consist of 4-bit reserved field, 4-bit BAK_ID, 32-bit ROC, and 
32-bit SK_RAND, as
specified in Figure 10-2. The reserved field is the 4 most significant bits 
in the MKI and is set to
'0000'. The MS shall ignore the reserved field. The MKI is included in 
every encrypted RTP packet

There was a requirement of integrity protection for an MKI field designed 
as above and my take was that perhaps there should be a separate field in 
SRTP for sending such information and the MKI field as defined in 3711 is 
not well-suited for such purposes.  The FAQ makes me rethink that 
interpretation.

Can you please clarify?

thanks and regards,
Lakshminath

---

From: Mark Baugher <[email-masked]>
Date: Fri, 28 Oct 2005 09:03:39 -0700

Lakshminath,
   I posted a note recently to AVT that I think addresses some of you  
questions and concerns:

Begin forwarded message:

> From: Mark Baugher <[email-masked]>
> Date: July 21, 2005 7:04:34 AM PDT
> To: "Usha Sharma" <[email-masked]>
> Cc: <[email-masked]>
> Subject: Re: [AVT] SRTP: question about MKI length
>
>
> hi
>   RFC 3711 assumes that the key management system will set the  
> maximum length for the MKI.  The use of an MKI function is common  
> in video broadcasting where a key gets rotated at rates that may be  
> less than one second.  TV conditional access vendors operate  
> proprietary systems that rotate the key according to application  
> needs (there is really no cryptographic need to rotate a 128-bit  
> AES counter-mode key until 2^64 packets have been encrypted using  
> it - a very long time).  The MKI was added for this application -  
> and vendors in this industry use various sizes for the key index,  
> particularly to convey a variety of key management information over  
> a broadcast channel.
>
>   In general, there is no need to use an MKI.  If there is, I would  
> expect that a small, one-byte MKI would suffice to handle cases  
> where key rotation might be useful.
>
> Mark
> On Jul 20, 2005, at 11:18 PM, Usha Sharma wrote:
>
>
>> There is no description in RFC 3711 for upper limit of MKI length  
>> and range of MKI value. SDP (draft-ietf-mmusic- 
>> sdescriptions-11.txt) defines that MKI value is a positive integer  
>> and MKI length could be up to 128 byte. Is it worthwhile to use  
>> such big MKI value for voice applications, considering the  
>> bandwidth overhead introduced by it. What would be the optimal  
>> value of MKI length for most applications?

You asked for references for where the MKI is being used.  I don't  
know of any.  That's not surprising since it is designed to support  
current keying practices of conditional access systems (see the  
PowerVu link in the SRTP FAQ), all of which are proprietary.

Does this answer your question?

Mark

Begin forwarded message:

> From: Lakshminath Dondeti <[email-masked]>
> Date: October 27, 2005 5:10:26 PM PDT
> To: "David A. McGrew" <[email-masked]>
> Cc: AVT <[email-masked]>
> Subject: [AVT] Req for clarification for the use of MKI field in  
> 3711 for "other" things
>
>
> Hi David,
>
> Just had a chance to quickly read the SRTP FAQ that you and the  
> other authors of 3711 put together.  Thanks.  I do have a request  
> for further clarification on Q8 on the MKI field use, specifically  
> on the following text:
>
> "For large video packets, however, some vendors may choose to use  
> the MKI to convey additional information (see the answer about MKI  
> length <http://srtp.sourceforge.net/faq.html#MKI-length>below), and  
> this is analogous to features found in some of the proprietary  
> conditional access systems today. "
>
> Are you advocating that the MKI field may be used to convey  
> information other than a key identifier?  I think the properties of  
> the MKI field make it inappropriate (no integrity protection, since  
> if used correctly none is needed) yet very attractive (variable  
> length) to overload it.
>
> I was wondering if you can provide references to where that field  
> is being used to convey information other than a key ID.  Thanks in  
> advance.
>
> I was pointed to the 3GPP2 BCMCS specification which uses the MKI  
> field as follows:
>
> The Master Key Index (MKI) shall be used for distributing the  
> SK_RAND2. The MKI shall be 72
> bits and consist of 4-bit reserved field, 4-bit BAK_ID, 32-bit ROC,  
> and 32-bit SK_RAND, as
> specified in Figure 10-2. The reserved field is the 4 most  
> significant bits in the MKI and is set to
> '0000'. The MS shall ignore the reserved field. The MKI is included  
> in every encrypted RTP packet
>
> There was a requirement of integrity protection for an MKI field  
> designed as above and my take was that perhaps there should be a  
> separate field in SRTP for sending such information and the MKI  
> field as defined in 3711 is not well-suited for such purposes.  The  
> FAQ makes me rethink that interpretation.
>
> Can you please clarify?
>
> thanks and regards,
> Lakshminath
>

---

From: "David A. McGrew" <[email-masked]>
Date: Fri, 28 Oct 2005 11:18:26 -0700

Hi Lakshminath,

On Oct 27, 2005, at 5:10 PM, Lakshminath Dondeti wrote:

> information other than a key identifier?

no, absolutely not.

> I think the properties of the MKI field make it inappropriate (no  
> integrity protection, since if used correctly none is needed) yet  
> very attractive (variable length) to overload it.
>

Mark would know better than I; it's a video application.

> in every encrypted RTP packet

Yes, IIRC I've seen this in draft form.  It clearly violates RFC 3711  
and is *not* interoperable with implementations that conform to the  
RFC.  (For example, a conformant receiver will except to use a  
different master key for each different MKI value, and a conformant  
sender will not set the ROC subfield in the MKI.)

> FAQ makes me rethink that interpretation.

Then I want to change the FAQ :-)

Best regards,

David

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 28 Oct 2005 12:04:14 -0700

Hi David,

Thanks for the clarifications.  AFAIK there is a group of folks involved 
with the BCMCS spec to do what they want to do right and not overload the 
MKI field.  I think perhaps SRTP (and IPsec for that matter) should have a 
provisions to carry some key management info in each packet (or a subset of 
packets, as required by application and communication environment needs) so 
that key updates can be easily synchronized.  I wrote a strawman proposal 
explaining the problem in an I-D 
http://tools.ietf.org/wg/msec/draft-dondeti-msec-inband-key-updates-01.txt. 
Please review and let me know your thoughts on that proposal.  Thanks in 
advance.

More on this thread below:

>>information other than a key identifier?

Thanks.  That's good to know.

>Mark would know better than I; it's a video application.

I'll follow-up with Mark's email on this thread.

>sender will not set the ROC subfield in the MKI.)

FWIW, I agree and it should be done correctly.  But as 3711 stands now, I 
guess 3GPP2 folks had no real choice and bent the rules for v1.0 of their 
BCMCS spec.  I think if there is a right way to do it, they can be 
convinced to use SRTP so that implementations of that protocol are in fact 
interoperable.  As it stands now, it appears that BCMCS compliant 
implementations won't interoperate with strictly 3711 compliant 
implementations.

Thanks David.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 28 Oct 2005 13:30:27 -0700

>   I posted a note recently to AVT that I think addresses some of you 

Thanks Mark.  This helps.  But, I have some follow-up questions below.

>Begin forwarded message:
>
>>From: Mark Baugher <<mailto:[email-masked]>[email-masked]>
>>To: "Usha Sharma" <<mailto:[email-masked]>[email-masked]>
>>Cc: <<mailto:[email-masked]>[email-masked]>
>>   RFC 3711 assumes that the key management system will set the maximum 
>> length for the MKI.  The use of an MKI function is common in video 
>> broadcasting where a key gets rotated at rates that may be less than one 
>> second.  TV conditional access vendors operate proprietary systems that 
>> rotate the key according to application needs (there is really no 
>> cryptographic need to rotate a 128-bit AES counter-mode key until 2^64 
>> packets have been encrypted using it - a very long time).  The MKI was 
>> added for this application - and vendors in this industry use various 
>> sizes for the key index, particularly to convey a variety of key 
>> management information over a broadcast channel.

Right, I understand key rotation due to access control requirements.  The 
question is how frequently does that need to be done and how does that 
influence the maximum length of the MKI field.

>> expect that a small, one-byte MKI would suffice to handle cases where 
>> key rotation might be useful.
>>
>>Mark
>>>There is no description in RFC 3711 for upper limit of MKI length and 
>>>range of MKI value. SDP (draft-ietf-mmusic-sdescriptions-11.txt) defines 
>>>that MKI value is a positive integer and MKI length could be up to 128 
>>>byte. Is it worthwhile to use such big MKI value for voice applications, 
>>>considering the bandwidth overhead introduced by it. What would be the 
>>>optimal value of MKI length for most applications?

I was wondering about the requirements that influenced the 128 B size of 
the MKI field.  My 3711 may be rusty, and the following info is on a quick 
rereading of the spec:

MKI based rekeying does not reset the ROC, so even if keys change within a 
crypto context, the context itself needs to be reestablished via MIKEY, 
Sdesc or something else before at most 2^48 SRTP packets are sent.  So, 
even if the MKI changes every packet, 48 bits should be sufficient to 
identify master keys within a crypto context.  I do understand that keys 
may be identified by various means, and the number of keys is not the only 
factor influencing the size of the MKI field -- but I am wondering about 
what the authors of Sdesc took into account in coming up with 128 B.

regards,
Lakshminath

>>><mailto:[email-masked]>[email-masked]
>You asked for references for where the MKI is being used.  I don't know of 
>any.  That's not surprising since it is designed to support current keying 
>practices of conditional access systems (see the PowerVu link in the SRTP 
>FAQ), all of which are proprietary.
>
>>From: Lakshminath Dondeti 
>><<mailto:[email-masked]>[email-masked]>
>>To: "David A. McGrew" 
>><<mailto:[email-masked]>[email-masked]>
>>Cc: AVT <<mailto:[email-masked]>[email-masked]>
>>Subject: [AVT] Req for clarification for the use of MKI field in 3711 for 
>>"other" things
>>
>>
>>Hi David,
>>
>><<http://srtp.sourceforge.net/faq.html#MKI-length>http://srtp.sourceforge.net/faq.html#MKI-length>below), 
>>and this is analogous to features found in some of the proprietary 
>>other than a key identifier?  I think the properties of the MKI field 
>>make it inappropriate (no integrity protection, since if used correctly 
>>none is needed) yet very attractive (variable length) to overload it.
>>
>>I was wondering if you can provide references to where that field is 
>>being used to convey information other than a key ID.  Thanks in advance.
>>
>>I was pointed to the 3GPP2 BCMCS specification which uses the MKI field 
>>as follows:
>>
>>The Master Key Index (MKI) shall be used for distributing the SK_RAND2. 
>>The MKI shall be 72
>>specified in Figure 10-2. The reserved field is the 4 most significant 
>>bits in the MKI and is set to
>><mailto:[email-masked]>[email-masked]

---

From: Mark Baugher <[email-masked]>
Date: Fri, 28 Oct 2005 17:05:26 -0700

hi Lakshminath,

On Oct 28, 2005, at 1:30 PM, Lakshminath Dondeti wrote:

...
>>> in video broadcasting where a key gets rotated at rates that may  
>>> be less than one second.  TV conditional access vendors operate  
>>> particularly to convey a variety of key management information  
>>> over a broadcast channel.
>>>
>
> Right, I understand key rotation due to access control  
> requirements.  The question is how frequently does that need to be  
> done and how does that influence the maximum length of the MKI field.

If you're talking about cryptographic necessity, an AES-128 key is  
good for 2^48 SRTP packets and that's a long time.  But the MKI is  
there for other purposes as well.  Fig. 2 of http://www.sciatl.com/ 
products/customers/white%2Dpapers/originator%5Fp2.pdf shows a key  
that gets rotated twice a second.  This is not cryptographically  
necessary but it is done as a protection measure.  I don't think it's  
needed, but Fig. 2 illustrates that it is practiced in the industry.
>
>
>
>>>   In general, there is no need to use an MKI.  If there is, I  
>>> would expect that a small, one-byte MKI would suffice to handle  
>>> cases where key rotation might be useful.
>>>
>>> Mark
>>>> There is no description in RFC 3711 for upper limit of MKI  
>>>> length and range of MKI value. SDP (draft-ietf-mmusic- 
>>>> sdescriptions-11.txt) defines that MKI value is a positive  
>>>> integer and MKI length could be up to 128 byte. Is it worthwhile  
>>>> to use such big MKI value for voice applications, considering  
>>>> the bandwidth overhead introduced by it. What would be the  
> I was wondering about the requirements that influenced the 128 B  
> size of the MKI field.

Some people wanted a upper limit placed on it so we added that - in  
sdescriptions.  I don't know what limit there may or may not be in  
MIKEY.

> My 3711 may be rusty, and the following info is on a quick  
> rereading of the spec:
>
> MKI based rekeying does not reset the ROC,

Yes, Mats put that into 3.3.1 and it seemed important at the time.   
But we did not document the reason and I forget why.

> so even if keys change within a crypto context, the context itself  
> needs to be reestablished via MIKEY, Sdesc or something else before  
> at most 2^48 SRTP packets are sent.  So, even if the MKI changes  
> every packet, 48 bits should be sufficient to identify master keys  
> within a crypto context.  I do understand that keys may be  
> identified by various means, and the number of keys is not the only  
> factor influencing the size of the MKI field -- but I am wondering  
> about what the authors of Sdesc took into account in coming up with  
> 128 B.

As I said, the intention with the MKI was to support different key  
management systems including proprietary ones as found (but hardly  
documented) in certain conditional access systems.  I asked some of  
the Vendors' designers and some said they wanted that flexibility if  
they were to extend their systems to key SRTP.  Since these are  
proprietary and not standard, the MKI is opaque (and not integrity  
protected) in SRTP.  But someone (my coauthors?  ADs? I can't  
remember) thought it was important to have an upper bound and we  
chose 128.

Also, please see my final remark on your earlier posting below...
...
>>> information other than a key identifier?  I think the properties  
>>> of the MKI field make it inappropriate (no integrity protection,  
>>> since if used correctly none is needed)

With 128 bytes, I assume that they could find room to put a 10-byte  
MAC yielding a 118 byte maximum MKI string.

>>> yet very attractive (variable length) to overload it.

I would not want to standardize this practice.  I think it's too  
complex.  Unnecessary for two-way internets and has little to do with  
real security (see the "Black Sunday Attack" in http:// 
www.answers.com/topic/pirate-decryption)

>>> is being used to convey information other than a key ID.  Thanks  
>>> in advance.
>>>
>>> bits and consist of 4-bit reserved field, 4-bit BAK_ID, 32-bit  
>>> ROC, and 32-bit SK_RAND, as
>>> '0000'. The MS shall ignore the reserved field. The MKI is  
>>> included in every encrypted RTP packet
>>>
>>> field as defined in 3711 is not well-suited for such purposes.   
>>> The FAQ makes me rethink that interpretation.

Since encoding of the MKI beyond using a simple integer is in no  
standard AFAIK we don't need to worry about that.  If someone chooses  
to standardize an MKI structure in a future SRTP key management  
protocol, crypto suite, etc. then integrity protecting the MKI would  
be their problem.  For sdescriptions purposes, if some attacker is  
able to modify the MKI of a packet that's in transit, then the lookup  
for the key will fail or the SRTP packet will simply fail the  
integrity check at the receiver.

cheers, Mark