Subject: [AVT] draft-lehtovirta-srtp-rcc-01.txt for broadcast use

From: "Dallard, Nigel" <[email-masked]>
Date: Wed, 26 Apr 2006 14:13:00 +0100

It is being proposed in the DVB standards group that this Internet draft
be adopted in their specifications for broadcasting to mobile devices
(DVB-H).

Currently their specification A100 "Service Purchase and Protection"
(see http://www.dvb-h-online.org/technology.htm) defines use of SRTP
with authentication being optional.

This internet draft appears to to enhance SRTP operation in a useful way
for this application but, as it instatiates the Rollover Counter
Carrying transform as an SRTP Authentication algorithm, its use seems to
require that authentication becomes mandatory. The minimum level of
authentication apparently allowed is authentication of every Rth SRTP
packet using HMAC-SHA-1-80.

Is this right, or have I misunderstood?

For this broadcasting application, I would like to retain the use of
authentication as optional, whilst using the method of carrying the ROC
defined in this internet draft. It seems that the only way to do this
would be to define an additional version of the RCC transform, which I
shall call "RCCv3".

I would envisage that RCCv3 would be similar to RCCv1, in that the
authentication tag field would only be present in every Rth RTP packet.
However, the content of the authentication tag field would consist only
of ROC_sender, rather than ROC_sender || MAC.

Would this be a sensible addition to the current draft, or is there a
better solution?

Regards,

Nigel

** Nigel Dallard                 e-mail: [email-masked]  ** 
** Senior Member                    www: http://www.nds.com  ** 
**   of Technical Staff             tel: +44 23 8030 7151    ** 
** NDS Ltd, Southampton, UK.     mobile: +44 7881 913151     ** 

This email message and any attachments thereto are intended only for use by the addressee(s) named above, and may contain legally privileged and/or confidential information. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the [email-masked] and destroy the original message

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

---

From: "Karl Norrman \(KI/EAB\)" <[email-masked]>
Date: Thu, 27 Apr 2006 09:47:29 +0200

Hello!

The ROC needs to be integrity protected to ensure that it is
not maliciously modified or subject to transmission bit errors
en route.  If the receiver starts using a ROC that has been modified
during transmission, the receiver will be out of synch.
Since in "normal" SRTP operation, the ROC is never transmitted 
in-band, an unprotected transmission of ROC would therefore _add_ 
a vulnerability that is -_not_ present in RFC3711.

You are correct when you say that it is necessary to include the MAC
on each R:th packet.  If one is worried about the bandwidth consumption
of a MAC of 80 bits per R:th packet, one could put the length of the MAC
(n_tag parameter in SRTP) to something less, e.g., 32 bits.  Note that
it is not mandatory to integrity protect every packet, only the ones 
carrying the ROC. 

Regards,
Karl

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dallard, Nigel
> Sent: den 26 april 2006 15:13
> To: [email-masked]; [email-masked]
> Subject: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use
> 
> 
> It is being proposed in the DVB standards group that this 
> Internet draft be adopted in their specifications for 
> broadcasting to mobile devices (DVB-H).
> 
> (see http://www.dvb-h-online.org/technology.htm) defines use 
> of SRTP with authentication being optional.
> 
> This internet draft appears to to enhance SRTP operation in a 
> useful way for this application but, as it instatiates the 
> Rollover Counter Carrying transform as an SRTP Authentication 
> algorithm, its use seems to require that authentication 
> becomes mandatory. The minimum level of authentication 
> apparently allowed is authentication of every Rth SRTP packet 
> using HMAC-SHA-1-80.
> 
> For this broadcasting application, I would like to retain the 
> use of authentication as optional, whilst using the method of 
> carrying the ROC defined in this internet draft. It seems 
> that the only way to do this would be to define an additional 
> version of the RCC transform, which I shall call "RCCv3".
> 
> I would envisage that RCCv3 would be similar to RCCv1, in 
> that the authentication tag field would only be present in 
> every Rth RTP packet.
> However, the content of the authentication tag field would 
> consist only of ROC_sender, rather than ROC_sender || MAC.
> 
> Would this be a sensible addition to the current draft, or is 
> there a better solution?
> 
> Regards,
> 
> Nigel
> 
> 
> 
> This email message and any attachments thereto are intended 
> only for use by the addressee(s) named above, and may contain 
> legally privileged and/or confidential information. If the 
> reader of this message is not the intended recipient, or the 
> employee or agent responsible to deliver it to the intended 
> recipient, you are hereby notified that any dissemination, 
> distribution or copying of this communication is strictly 
> prohibited. If you have received this communication in error, 
> please immediately notify the [email-masked] and destroy 
> the original message _______________________________________________
> msec mailing list
> [email-masked]
> http://six.pairlist.net/mailman/listinfo/msec
>

---

From: "Dallard, Nigel" <[email-masked]>
Date: Fri, 28 Apr 2006 16:45:06 +0100

> From: David McGrew [mailto:[email-masked]] 

> I'm curious: are there any higher-level checksums on the application  
> data that would catch the decryption error that would result from
> ROC de-synch?  If not, how would the codec respond to seemingly
> random inputs?

Hi there David,

No, there are not usually any checksums on the application data. MPEG
A/V decoders used in TV broadcasting systems are pretty robust at
recovering from errored bitstreams and concealing lost data from the
viewer (via interpolation, etc). Loss of crypto-sync would just look
like horrendous bit-errors to the decoder.

> I'm not sure that I'd make that tradeoff.  If there are system  
> constraints (e.g. on packet size) that would prevent the use of  
> authentication, that's one thing.  But IIRC you're securing video  
> broadcasts, and video packets are typically fairly large.

Whilst it is true that a complete compressed video frame may be quite
large, typically in broadcast TV systems, the compressed video stream is
split into relatively small packets (payload of 184 bytes if using the
MPEG-2 Transport Stream, for example). Whilst I'm not suggesting that
each SRTP packet be that small, I don't expect a whole video frame to be
transported in a single RTP packet.

> Also, consider that with RCC as currently defined the 32-bit
> rollover counter is being included in every Rth packet - so
> there is already some bandwidth loss that's being incurred
> just for using RCC.

There is indeed, but we need to convey the ROC anyway, and the
alternative is in the Key Stream Message, which in broadcast TV systems
is sent several times a second. All we're doing here is moving the ROC
delivery from out-of-band to in-band. Operators would then select "R"
according to how they wish to trade-off bandwidth vs random-access
time/crypto-sync loss recovery time.

> If you're interested in seeing a standard that supports the option  
> you're describing, I suspect that people in the security area will  
> ask you to provide the sort of analysis that you mention above.

OK, I could look at working on that, but really all I'm asking for is
the OPTION to turn off authentication if *I* decide, for *MY* service,
that I don't need it. SRTP already allows me that option, although it is
clearly marked as not to be used lightly. I'm just asking for that
option to be retained if I use RCC to convey the ROC. Do I really need
to provide a security analysis to retain an option that is already
present in RFC3711?

> Have you considered using the "Encrypted Key Transport for SRTP"  
> method, which provides ROC synchronization as well as some other  
> features that are attractive in multi-participant RTP sessions?  It  
> doesn't increase the bandwidth usage (it eats into RTCP's bandwidth  
> allocation, not RTP's bandwidth allocation - it robs Peter 
> instead of Paul, so to speak :-).

I haven't, but will do so. However, the use of RCC has been/is in the
process of being adopted by various broadcast standards organisations,
and it might be difficult to get them all to change direction at this
stage. A slight modification to RCC would allow these various standards
to both proceed and remain harmonised, whilst retaining the operator's
choice as far as authenticating streams.

Regards,

Nigel