Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvc52-0005GJ-TS; Thu, 21 Jul 2005 10:31:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvc51-0005Fr-K1 for avt@megatron.ietf.org; Thu, 21 Jul 2005 10:31:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05533 for ; Thu, 21 Jul 2005 10:31:17 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvcZ3-0003he-Oy for avt@ietf.org; Thu, 21 Jul 2005 11:02:23 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6LETro7024260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Jul 2005 07:29:54 -0700 (PDT) Received: from NAEXBR01.na.qualcomm.com (naexbr01.qualcomm.com [172.30.32.40]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6LETpN2024009; Thu, 21 Jul 2005 07:29:51 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 07:29:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [AVT] SRTP: question about MKI length Date: Thu, 21 Jul 2005 07:25:38 -0700 Message-ID: Thread-Topic: [AVT] SRTP: question about MKI length Thread-Index: AcWN/X6koPuhztdEQjKj3eNusLoapAAApIkL From: "Dondeti, Lakshminath" To: "Mark Baugher" , "Usha Sharma" X-OriginalArrivalTime: 21 Jul 2005 14:29:51.0268 (UTC) FILETIME=[A795BE40:01C58E00] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1288442388==" Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============1288442388== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58E00.A6BEEFEA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58E00.A6BEEFEA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: avt-bounces@ietf.org on behalf of Mark Baugher Sent: Thu 7/21/2005 7:04 AM To: Usha Sharma Cc: avt@ietf.org Subject: Re: [AVT] SRTP: question about MKI length =20 hi RFC 3711 assumes that the key management system will set the maximum=20 length for the MKI. The use of an MKI function is common in video=20 broadcasting where a key gets rotated at rates that may be less than=20 one second. TV conditional access vendors operate proprietary systems=20 that rotate the key according to application needs (there is really no=20 cryptographic need to rotate a 128-bit AES counter-mode key until 2^64=20 packets have been encrypted using it - a very long time). The MKI was=20 added for this application - and vendors in this industry use various=20 sizes for the key index, particularly to convey a variety of key=20 management information over a broadcast channel. In general, there is no need to use an MKI. If there is, I would=20 expect that a small, one-byte MKI would suffice to handle cases where=20 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=20 > range of MKI value. SDP (draft-ietf-mmusic-sdescriptions-11.txt)=20 > defines that MKI value is a positive integer and MKI length could be=20 > up to 128 byte. Is it worthwhile to use such big MKI value for voice=20 > applications, considering the bandwidth overhead introduced by it.=20 > What would be the optimal value of MKI length for most applications? > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt ------_=_NextPart_001_01C58E00.A6BEEFEA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AVT] SRTP: question about MKI length

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: avt-bounces@ietf.org on behalf of Mark Baugher
Sent: Thu 7/21/2005 7:04 AM
To: Usha Sharma
Cc: avt@ietf.org
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
> avt@ietf.org
> https://www1.ietf.org= /mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org= /mailman/listinfo/avt

------_=_NextPart_001_01C58E00.A6BEEFEA-- --===============1288442388== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============1288442388==--