RE: [AVT] FEC and SRTP, some clarifications

["Elisabetta Carrara (KI/EAB)" <elisabetta.carrara at ericsson.com>]

Vinay,
the decryption is independent, in the sense that e.g. you 
can decrypt one without decrypting the other, if this is what 
you meant. (This is not the case if RFC2198 is used, because
the FEC and the original RTP are in the same payload). 

You can use different encryption algorithms.
(Note: currently, SRTP has 3 defined encryption transforms:
AES-f8, AES-CM, NULL. Hence the only open possibility to use
different ciphers is to use f8 for one, and CM for the other, 
and I don't really see the reason why one would want to do 
that..You shall not use NULL, see the previous mail.)

I'm not sure what you mean with "key management algorithms".

Cheers
/Elisabetta



> -----Original Message-----
> From: vsathe@san.rr.com [mailto:vsathe@san.rr.com]
> Sent: den 26 april 2004 19:11
> To: avt@ietf.org
> Cc: Elisabetta Carrara (KI/EAB)
> Subject: Re: [AVT] FEC and SRTP, some clarifications
> 
> 
> Please also clarify whether the FEC stream and the RTP stream can be
> decrypted independent of each other and can possibly use different
> encryption/key management algorithms. 
> 
> Thank you.
> Vinay
> 
> 
> -----Original Message-----
> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of
> Elisabetta Carrara (KI/EAB)
> Sent: Monday, April 26, 2004 9:37 AM
> To: 'avt@ietf.org'
> Cc: Mats Näslund (KI/EAB); Karl Norrman (KI/EAB); 'Mark 
> Baugher' (E-mail);
> David A. McGrew (E-mail)
> Subject: [AVT] FEC and SRTP, some clarifications
> 
> Hi,
> we have lately received some questions about the combined use 
> of SRTP and
> FEC. We thought of bringing them to the mailing list.
> 
> SRTP only defines the default order of the combined 
> processing (first FEC,
> then SRTP, at sender side).
> 
> First of all, the SRTP spec misses to specify normative 
> language about the
> case when the FEC stream is separated from the original RTP 
> stream (one
> possibility in RFC2733) and the latter uses encryption. 
> For this case, the normative language needed is:
> the separate FEC stream MUST be encrypted if the original RTP
> stream(s) is encrypted.
> This text is needed because if the FEC stream (related to a separate
> encrypted RTP stream) is sent unencrypted, there is a 
> security leakage.
> RFC2733 discusses the issue and uses a SHOULD. It has to be a 
> MUST, and
> should have been present explicitly in SRTP.
> 
> Second, there are constraints on the key usage according to how the
> "separate stream" is implemented. We were asked on this, so here is a
> summary.
> SRTP mandates that different RTP sessions must use separate 
> master keys,
> and the sharing of the master key within the same RTP session requires
> unique SSRC.
> RFC2733 is very open in the definition of what the "separate stream"
> is. Possible key settings:
> 
> C1) if the RTP stream and the FEC stream have different 
> SSRCs, and are in
> the same RTP session, then they MAY share the same master key.
> Note, in case they share it, the FEC stream and the original 
> RTP stream
> simply use the same session keys.
> 
> C2) if the RTP stream and the FEC stream have the same SSRC, 
> and are in
> different RTP sessions, they use different master keys.
> 
> We hope this has answered some of the questions we got.
> 
> Cheers
> /the SRTP authors
> 
> 
> 
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://mail2web.com/ .
> 
> 

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