Subject: [AVT] RE: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt

From: "Fries, Steffen" <[email-masked]>
Date: Fri, 3 Mar 2006 16:28:48 +0100

Hi Vesa,

I just read your draft regarding the SRTP/MIKEY extension. It is a good enhancement to transmit the ROC in parts pof the SRTP payload. 
Nevertheless, I have a comment/question to the transform described in section 2. It is stated that TAG = ROC_sender || MAC. What is the reason that the TAG is constructed in that way, rather than TAG = MAC || ROC_sender?

>From my point of view there is an advantage for the latter case. This approach would provide a better backward compatibility for terminals which are not aware of the SRTP extension you are describing. If they get the ROC information by other means (e.g., seperate messages) there still would be able to handle the MAC verification correctly, as the MAC starts at the same position as described in RFC3711. When inserting the ROC before the MAC in the packet, older terminaly would take a part of the ROC as MAC, which would lead to errors in the MAC verification.

Would it influence the security in any way by choosing the TAG = MAC || ROC_sender?

Regards
	Steffen

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vesa 
> Lehtovirta (JO/LMF)
> Sent: Tuesday, February 14, 2006 3:31 PM
> To: [email-masked]; [email-masked]
> Cc: Magnus Westerlund (KI/EAB)
> Subject: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt
> 
> Dear all,
> 
> Forwarding on behalf of Karl.
> 
> -----Original Message-----
> From: Karl Norrman (KI/EAB)
> Sent: 13. helmikuuta 2006 18:04
> To: [email-masked]
> Cc: Vesa Lehtovirta (JO/LMF); Mats Näslund (KI/EAB)
> Subject: Submission of draft-lehtovirta-srtp-rcc-01.txt
> 
> Dear Editor,
> 
> Please submit the new version of draft-lehtovirta-srtp-rcc-01.txt.
> 
> Best Regards,
> Karl Norrman
> Ericsson
> 

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 03 Mar 2006 15:54:27 -0800

Hi Steffen,

Just some thoughts on this as WG contributor:

RCC would be signalled as a new MAC algorithm 
anyway and that would imply that receivers that 
don't understand the new MAC construction would 
need to decide against joining the secure 
group.  Furthermore, if I recall the semantics 
correctly, the received ROC and not the stored 
ROC would be used in the MAC verification process.

For those reasons, I don't think the proposed 
construction is a problem.  Your proposal is also 
ok.  I guess one way to look at it is if R is 
sufficiently high (i.e., RCC packets are 
infrequent), receivers that don't support the new 
extension can also listen in as long as the key 
management semantics are revised to allow that.

That said, once again if memory serves me the 
reason for the current design of RCC is to have 
the MAC at the end.  The EKT work adds new payloads at the end, however.

In conclusion, I think if the RCC extension is to 
support what you propose, we may need to specify 
the RCC extension to keep the MAC algorithm the 
same and signal the extension differently.

regards,
Lakshminath

At 07:28 AM 3/3/2006, Fries, Steffen wrote:
>  Hi Vesa,
>
>I just read your draft regarding the SRTP/MIKEY 
>extension. It is a good enhancement to transmit 
>the ROC in parts pof the SRTP payload.
>Nevertheless, I have a comment/question to the 
>transform described in section 2. It is stated 
>that TAG = ROC_sender || MAC. What is the reason 
>that the TAG is constructed in that way, rather than TAG = MAC || ROC_sender?
>
> >From my point of view there is an advantage 
> for the latter case. This approach would 
> provide a better backward compatibility for 
> terminals which are not aware of the SRTP 
> extension you are describing. If they get the 
> ROC information by other means (e.g., seperate 
> messages) there still would be able to handle 
> the MAC verification correctly, as the MAC 
> starts at the same position as described in 
> RFC3711. When inserting the ROC before the MAC 
> in the packet, older terminaly would take a 
> part of the ROC as MAC, which would lead to errors in the MAC verification.
>
>msec mailing list
>[email-masked]
>http://six.pairlist.net/mailman/listinfo/msec

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 05 Mar 2006 14:16:20 -0500

You mention how 3GPP is using the MKI. Could you provide any more details or
references on this? Do you foresee interop problems if an 3GPP device was
talking to a devices that was using MKI more the way that SRTP specified it?

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 05 Mar 2006 18:57:33 +0900

Hi Cullen,

MKI use in different ways is a known problem that folks in OMA BCAST 
have been working to resolve for a few months now.

3GPP MBMS MKI field is defined as (MSK ID || MTK ID).  MSK = MBMS 
Service key (long term key) and MTK = MBMS Traffic key (short term key)

In 3GPP2 BCMCS, MKI field was/is defined as  (4-bit Reserved||4-bit 
BAK_ID||32-bit ROC||32-bit SK_RAND).  BAK is the long term key and 
SK_RAND is used to compute the short term key.

I have worked with my colleagues in 3GPP2 recently to have that 
changed to (4-bit Reserved||4-bit BAK_ID||32-bit SK_RAND), and send 
the ROC as part of the auth_tag as defined in the RCC I-D.

My recollection is DVB sends TEK ID in the MKI (not sure about that, 
so please cross-check).

As you note this leads to interop problems, for instance, a 
broadcaster (OMA context) will have to prepare multiple SRTP streams 
for multiple broadcast distribution systems (e.g., BCMCS, MBMS, 
etc.,) and people are now trying to resolve that.  I will have an 
update on this later this week (we are meeting in Seoul in part to 
resolve some of this), if you care.

All of this is in the context of broadcast though.  Is that what you 
have in mind?  Or, are you looking for information on unicast SRTP usage?

regards,
Lakshminath

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 07 Mar 2006 22:44:02 -0500

Thanks - yes, that was type of info I was looking for. Do you know if 3GPP,
OMA, others, are using MKI when doing unicast stuff? and if so, how do they
use it?

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 08 Mar 2006 00:35:37 -0800

Cullen,

To give you a quick answer, I don't know.  From what I can tell, OMA 
and 3GPP2 don't use SRTP for unicast.  I don't know about 
3GPP.  Folks from Ericsson might have some insight into that.  I will 
also check.

cheers,
Lakshminath