Subject: Re: [AVT] Req for clarification for the use of MKI field in 3711 for "other" things

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 08 Nov 2005 16:26:16 -0800

Some followup notes on this (apologies for the long delay in between):

At 04:05 PM 10/28/2005, Mark Baugher wrote:

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

I am cc'ing Mats; he might care to elaborate on the reason for this.
I am not quite familiar with ROC management, but it may have to do 
with signaling the resetting in-band and ensuring that all members 
receive the ROC-reset message.  So, it is easy to not reset and keep 
the requirement to "rekey" before the counter space is used up.

>>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...
>>>>
>...
>>>>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)
>
>With 128 bytes, I assume that they could find room to put a 10-byte
>MAC yielding a 118 byte maximum MKI string.

Actually that's quite burdensome to include two MACs within each 
single SRTP packet containing the MKI.  It is not the length but the 
"overhead."  It is in fact better to include the payload that 
contains key management information within the already defined 
MAC.  But of course that means a slight change to the SRTP spec.

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

MKI encoding is already in progress elsewhere (e.g., 3GPP2 BCMCS spec 
as mentioned), but integrity protection of that field is efficiently 
done by including the contents in the existing SRTP MAC.  In fact, my 
point in this thread was that the rekeying hints don't belong in the 
MKI field as defined in the SRTP spec, and probably belong in a 
separate payload that can be included in the MAC.

regards,
Lakshminath

>cheers, Mark
>>>>
>>>>Can you please clarify?
>>>>
>>>>thanks and regards,
>>>>Lakshminath
>>>>
>>>>_______________________________________________
>>>>Audio/Video Transport Working Group
>>>><mailto:[email-masked]>[email-masked]
>>>>https://www1.ietf.org/mailman/listinfo/avt

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

---

From: Mats Näslund <[email-masked]>
Date: Wed, 09 Nov 2005 10:55:37 +0100

Hi,

>> sdescriptions.  I don't know what limit there may or may not be in

MIKEY allows MKI to be up to 256 bytes, since the MKI-length field is
8 bits. But I don't think there is any other reason than making MIKEY
payloads always being a multiple of 8 bits.

> I am not quite familiar with ROC management, but it may have to do with 
> signaling the resetting in-band and ensuring that all members receive 
> the ROC-reset message.  So, it is easy to not reset and keep the 
> requirement to "rekey" before the counter space is used up.

The reason for not resetting ROC at rekey is simple, and it has
to do with <From, To> rekeying (based on SRTP index) rather than
MKI-rekeying:

Suppose an SRTP session is about to start and we *pre-distribute*
a bunch of keys, k_1, k_2, .... with associated lifetimes <F_1, T_1>,
<F_2, T_2>, ... (where I guess it is likely that F_(i+1) = T_i + 1).

The Fi, T_i values depend on ROC (and RTP SEQ). Hence, it would be
"odd" if ROC would not maintain its "sequence space" during the
session. If not, the ROC-part of each F_i would always need to be
zero, in turn implying that there may be ambiguity on which key to
use next (e.g. two F_i values might "collide" in the SEQ-part).

With MKI-rekeying this is not a problem, but it seemed simpler
to have the ROC managament independent of the rekeying method.

>>> within a crypto context.  I do understand that keys may be

Which in a sense can be achieved by the <From, To> method where 48
bits (or rather 2*48 bits) is indeed what's needed.

> Actually that's quite burdensome to include two MACs within each single 
> SRTP packet containing the MKI.  It is not the length but the 
> "overhead."  It is in fact better to include the payload that contains 
> key management information within the already defined MAC.  But of 
> course that means a slight change to the SRTP spec.
> 
> MKI encoding is already in progress elsewhere (e.g., 3GPP2 BCMCS spec as 
> mentioned), but integrity protection of that field is efficiently done 
> by including the contents in the existing SRTP MAC.  In fact, my point 
> in this thread was that the rekeying hints don't belong in the MKI field 
> as defined in the SRTP spec, and probably belong in a separate payload 
> that can be included in the MAC.

Another way to do this would be to use a special MAC transform.
The MAC takes three inputs:

- key
- payload
- additional_info

It applies the key to protect

	payload || additional_info

and outputs

	MAC_tag || additional_info.

This would not change the SRTP base-RFC and would allow
basically any side-information (with no confidentiality
requirements) to be securely transfered.

Best,

/Mats

---

From: Mark Baugher <[email-masked]>
Date: Wed, 9 Nov 2005 11:21:10 -0800

hi Lakshminath,
   The appropriate places to discuss use of the MKI are msec, for  
MIKEY, and MMUSIC, for sdescriptions.  RFC 3711 leaves the MKI  
definition to the particular key management system, which is  
specialized for the application and independent of SRTP.  That is, we  
want a variety of key management systems for telephony, broadcast,  
etc. to be able to use SRTP, and the MKI is there for key management  
purposes.

Mark
On Nov 8, 2005, at 4:26 PM, Lakshminath Dondeti wrote:

> receive the ROC-reset message.  So, it is easy to not reset and  
> keep the requirement to "rekey" before the counter space is used up.
>
>
> single SRTP packet containing the MKI.  It is not the length but  
> the "overhead."  It is in fact better to include the payload that  
> MKI encoding is already in progress elsewhere (e.g., 3GPP2 BCMCS  
> spec as mentioned), but integrity protection of that field is  
> efficiently done by including the contents in the existing SRTP  
> MAC.  In fact, my point in this thread was that the rekeying hints  
> don't belong in the MKI field as defined in the SRTP spec, and  
> probably belong in a separate payload that can be included in the MAC.
>
> regards,
> Lakshminath
>
>
>> cheers, Mark
>>>>>
>>>>> Can you please clarify?
>>>>>
>>>>> thanks and regards,
>>>>> Lakshminath
>>>>>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 09 Nov 2005 14:44:09 -0800

Hi Mats,

Thanks for the clarifications.  Some thoughts inline:

>bits (or rather 2*48 bits) is indeed what's needed.

I am not parsing this properly: what is the 2^48 bits referring to?

>>><snip>
>>MKI encoding is already in progress elsewhere 
>>(e.g., 3GPP2 BCMCS spec as mentioned), but 
>>integrity protection of that field is 
>>efficiently done by including the contents in 
>>the existing SRTP MAC.  In fact, my point in 
>>this thread was that the rekeying hints don't 
>>belong in the MKI field as defined in the SRTP 
>>spec, and probably belong in a separate payload 

Right, this makes sense too.  I will think about 
this option some more and follow-up. Thanks Mats.

regards,
Lakshminath

---

From: Mats Näslund <[email-masked]>
Date: Thu, 10 Nov 2005 10:16:17 +0100

Hi Lakshminath,

See inline.

> I am not parsing this properly: what is the 2^48 bits referring to?

Note: I wrote 2*48, not 2**48 ;-)

What I am saying is that a <From, To> pair, specifying key-lifetime
can be done using 48 (From) + 48 (To) bits, corresponding to the
SRTP indexes between which the key is valid. Since (in the worst
case) a rekey occurs per every packet, on the order of this many¨
bits will be enough to uniquely point to the right key.

So, I was trying to be supportive to the argument that 48 bits
(or thereabout) would suffice for an MKI in most practical cases,
unless of course we want to extend the MKI by additional semantics
that it today does not have.

[snip]

Best,

/Mats

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 15 Nov 2005 11:27:09 -0800

Hi Mats,

I am sorry I misread the 2*48 as 2^48 :-(.

Lakshminath