[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.

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

Regards
        Steffen




> -----Original Message-----
> From: msec-bounces at securemulticast.org
> [mailto:msec-bounces at securemulticast.org] On Behalf Of Vesa
> Lehtovirta (JO/LMF)
> Sent: Tuesday, February 14, 2006 3:31 PM
> To: msec at securemulticast.org; avt at ietf.org
> 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: internet-drafts at ietf.org
> 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
>
_______________________________________________
msec mailing list
msec at securemulticast.org
http://six.pairlist.net/mailman/listinfo/msec



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