Subject: RE: [AVT] SRTP: question about MKI length

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Thu, 21 Jul 2005 07:25:38 -0700

Hi Mark,

I am curious about using the MKI to convey "a variety of key management information."  Could you please elaborate?  I know of the MKI being used in 3GPP2 to send key management information also, but with the concern that the MKI field is not integrity protected.  If the MKI is used to send a key index, we know that no integrity protection is required, but if it is intended for sending arbitrary key management information, then perhaps integrity protecting that field would be necessary.

Thoughts?

thanks and regards,
Lakshminath

-----Original Message-----
From: [email-masked] on behalf of Mark Baugher
Sent: Thu 7/21/2005 7:04 AM
To: Usha Sharma
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?
> _______________________________________________
> 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

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

---

From: Mark Baugher <[email-masked]>
Date: Thu, 21 Jul 2005 08:14:51 -0700

hi Lakshminath,
    I heard from NDS (and also Nagra, I think) that they put as much key 
management information as they can into the broadcast stream, such as 
an MPEG-2 Transport Stream.  Since they don't publish their key 
management protocols, conditional access companies typically don't 
explain why they do things.  But a couple of years ago, it was 
announced in the press that a large satellite vendor gradually 
downloaded code and re-programmed the conditional access system in the 
settop boxes of its entire customer base to disable unauthorized 
receivers.  This was an NDS system if I recall correctly.  So, there 
are shenanigans like that going on and probably the same sorts of key 
management things that LKH and similar systems might do.

Mark
On Jul 21, 2005, at 7:25 AM, Dondeti, Lakshminath wrote:

> Hi Mark,
>
>  I am curious about using the MKI to convey "a variety of key 
> management information."  Could you please elaborate?  I know of the 
> MKI being used in 3GPP2 to send key management information also, but 
> with the concern that the MKI field is not integrity protected.  If 
> the MKI is used to send a key index, we know that no integrity 
> protection is required, but if it is intended for sending arbitrary 
> key management information, then perhaps integrity protecting that 
> field would be necessary.
>
>  Thoughts?
>
>  thanks and regards,
>  Lakshminath
>
>