Subject: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long)

From: Bob Briscoe <[email-masked]>
Date: Thu, 19 Aug 2004 08:31:34 +0100

Mark, Elisabetta,

Thanks for the new SRTP-TESLA I-D draft 01.

Below is a thorough review. I'm afraid these comments would have been more 
useful after draft 00. But I've moved on from group security, so I don't 
follow the list closely. My original motivation back in 1999 behind 
thinking up what became known as TESLA (in parallel with the co-authors of 
the TESLA intro) was to authenticate multicast RTP, so I hope you will find 
the suggested improvements below useful.

Essentially, the goal with SRTP is to keep the packet size as low as 
possible.  Although this is a bandwidth concern (as mentioned in your 
section 6), it is more a latency concern for many real-time applications, 
particularly interactive voice (conferencing) and to a lesser extent 
interactive video (conferencing).

I explain below how you can trade-off sender memory/processing for smaller 
packet size. In this way, we can also do stronger immediate authentication 
than you have (against DoS) while keeping equally strong delayed 
authentication, but completely removing the need for 3 of your 4 byte 
headers per pkt. = 12 bytes less overhead out of your 38 bytes. As you say, 
implementations can also choose to do heavier truncation of the MAC etc, to 
get further overhead savings.

I also explain below how we might even achieve interactive-quality latency 
in parallel to delayed authentication, rather than in series. The improved 
immediate authentication makes this feasible.

I can send you a tech report I started in 1999, with RTP uppermost in my 
mind as an application. I'm afraid it's unfinished and therefore 
unpublished. But the body is finished - I just never got round to topping 
and tailing it. It gives the rationale and protocol details behind all the 
points below, plus other stuff like how I would envisage extensions to SDP 
for sending session security parameters for TESLA. Just ask if you want a 
copy (PDF, 19pp including 9 figures).

If you believe some of the points below impact on the TESLA intro rather 
than SRTP-TESLA, say now. However, we have tried to accommodate all these 
possibilities in draft-ietf-msec-tesla-intro-03.txt just published. 
However, until re-reading my own report just now, I had forgotten how I had 
done stronger immediate authentication (point 3/ below)!

1/ Key index field is redundant with SRTP
----------------------------------------
The key index can be derived from the RTP timestamp in each message. This 
saves 4 bytes in each packet.

If the sender buffers packets between adding the RTP timestamp and adding 
TESLA authentication fields, this will add to the TESLA authentication 
delay. But a good RTP implementation shouldn't be doing serious buffering here.

2/ Non-TESLA group authentication to protect against DoS should be optional
---------------------------------------------------------------------------
The immediate authentication provided by your non-TESLA group 
authentication only protects against DoS by non-group members. It should be 
RECOMMENDED not REQUIRED (section 7). Two reasons:
i) Imagine an Internet TV application, with millions of viewers. It would 
be silly to MANDATE the non-TESLA group authentication fields in such a 
scenario. An attacker isn't going to be prevented from mounting a DoS 
attack by being excluded from the group. Such large, publicly accessible 
groups are too easy to join for group authentication to make sense.
ii) If there is no history of DoS attacks on a particular group, it is 
silly to add this overhead to every packet to protect against a threat of 
which there is no risk.

Below, anyway, I show another way to do immediate authentication without 
these group authentication fields, and it's stronger.

3/ Non-TESLA group authentication to protect against DoS is redundant
---------------------------------------------------------------------
If the time interval for switching to a new key is set to be the same as 
that for each RTP packet, the disclosed key allows an immediate rather than 
delayed test that affords good enough protection against DoS on its own 
(irrespective of whether attackers are within or outside the group). TESLA 
delayed authentication is still necessary to protect against attackers with 
some control over the network. But you get immediate 'network-dependent' 
authentication. I use this term to mean authentication dependent on the 
integrity of the network, but still protecting against malicious behaviour 
of end systems.

Each time a packet arrives at a receiver, it will now contain a new 
disclosed key. An immediate check can be made as to whether:
- this key has already been seen (in which case all later packets with 
duplicate keys are considered fake and ignored)
- this new key fits into the key chain.
The tech report gives a more exact definition of the tests.

The only way an attacker can get hold of the next key in the chain is to 
receive the next authentic packet. It then has to extract the key and use 
it to create its own fake packet, then overtake the original packet's 
arrival at some or all the other receivers. This might be done in the 
following ways:
- request better latency service (even then, receiving, processing, 
re-transmitting and overtaking the original packet is very hard)
- use a parallel network (ditto)
- watch for negative acks, and send retransmissions only to those receivers 
affected
- conspire with a network provider, or take over a network node to delay or 
remove the original packets from the remainder of the multicast tree

I believe this 'network-dependent' authentication, where all the above uses 
and abuses of the network are infeasible, is sufficient to protect against 
most DoS attacks. Indeed, it gives better protection against DoS than the 
group authentication MAC you use.

Changing the key each packet requires more memory or processing at the 
sender. But the complexity only rises O(log(r)) where r is the key change 
rate, so this isn't a big hit. See refs [21, 22] in the TESLA intro draft 
for efficient hash traversal algorithms.

BTW, this immediate authentication isn't novel. It is the basic S/KEY 
protocol that has been used for years (IETF RFC1760 based on Lamport).

4/ No need to include the key index, i, in the TESLA authenticated portion
--------------------------------------------------------------------------
[If you accept my argument in 1/ that the key index is unnecessary, my 
point here is irrelevant.]
The key index determines the operation of the verification algorithm - viz. 
which key to use to create a MAC to compare with the TESLA MAC field. There 
is no point in including this key index within the coverage of the TESLA 
MAC (end of section 4.2, section 4.5 & 4.6). If the key index is altered, 
the verification will fail, whether or not the key index is covered by the 
MAC. It doesn't really matter either way. It's just contrary to what the 
TESLA intro specifies, and therefore liable to lead to confused 
standardistion of implementations.

BTW, it should be pointed out that the verification algo should check the 
key index is within an expected range before using it (e.g. only a small 
increment above the last highest verified key index seen). Otherwise, an 
attacker can tamper with this field to lead all receivers to run millions 
of hash operations unnecessarily. I prefer to call it a key-index *hint*, 
to remind me not to rely on it being correct.

5/ Discard if a packet cannot be authenticated should be optional
-----------------------------------------------------------------
It is wrong to say a packet MUST be discarded if a safe condition does not 
hold (section 4.4 & 4.4.2). We have changed the lastest TESLA intro I-D to 
clarify this point. It is one thing for verification to fail. It is another 
for the verification test to not be possible (e.g. due to excessive delay). 
In the latter case, it should be application-dependent whether the packet 
is discarded.

Instead, we have introduced the term "considered unauthenticated" for such 
packets. There might be an internal API between the verifier and the 
application to flag when packets are considered unauthenticated, rather 
than dropping them (a fairly dumb implicit API). An explicit API is likely 
to be preferred, to distinguish network loss from potential attacks.

For instance, if there has been no history of verification failure, and the 
odd packet arrives too late to be verified safely, an application should be 
within its rights to assume the *probability* of such packets being 
authentic is high.

Also, part of the application might involve analysing the cause of attacks. 
It would be wrong to mandate discard, thus removing the evidence such 
applications need.

6/ Play-out may be in parallel to buffering awaiting authentication
-------------------------------------------------------------------
In the note at the end of section 4.4.2, you say decryption can be done 
optimistically before TESLA verification. I would ask you to add that some 
delay sensitive applications might even play-out the packets optimistically 
before TESLA verification (still buffering the packets in parallel). If 
TESLA verification subsequently fails, then roll-back would have to be 
achieved at the user interface level. We have given an example in the new 
TESLA intro.

7/ TESLA tail piece section required
------------------------------------
Perhaps after the TESLA bootstrapping section, a new section is required to 
explain the implications on SRTP of disclosing the remaining keys after all 
RTP data has finished.

Nits
====
A general point of style: I found the spec had too much 'knitting together 
by reference' from other specs. As Ran said in an earlier posting, it needs 
at least some sketching of what is referred to. Otherwise it is unlikely to 
lead to safe standardisation of implementations. Particularly given that 
the references themselves are evolving, it becomes unsafe to expect people 
to find discrepancies when reviewing this draft by re-reading the latest 
drafts of the other specs each time. Sections 4.4. & 4.4.1 were particular 
culprits. However, I also have some sympathy with the view that duplication 
of parts of specs in other specs can lead to inconsistency.

Throughout: To be consistent with the TESLA intro, the time-slot index, I, 
should be i (lower case).
Sec 2. "...may often used..." --> "...may often be used..."
Sec 3. "This specification assumes that the reader is familiar with TESLA" 
repeats the same sentence in Sec 1.1.
Sec 3. TESLA synch protocol & initial bootstrapping outside scope, but 
presumably you will include a ref once one is available.
Sec 4. "...and the delayed-authentication TESLA elements of procedure 
[TESLA]." Garbled sentence?
Sec 4.1 "showed" --> "shown"
Sec 4.3 bullet 10 "...based up the..." --> "...based upon the..."
Sec 4.4 "If the safe condition does not hold,..." add "...and the event 
SHOULD be logged."
Sec 5. TESLA doesn't assume local clocks don't drift too much. Rather it 
requires a bound on clock drift to be known.
Sec 7. "...an in the TESLA specification..." --> "...and in the TESLA 
specification..."
Sec 7. "...noted that the all TESLA security..." sentence garbled.

Bob

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.   +44 1473 645196  

_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Thu, 19 Aug 2004 11:27:49 -0400

I think some of the new "enhancements" you propose would make TESLA 
ineffective for the most part (should have read the new tesla-intro I-D; 
will do now).  I also found it interesting that the "adversary" can 
become a member of a secure group easily (as in the IP Television 
example below, to make the case that we don't need to differentiate 
between members and non-members ), but which cannot take over someone's 
network connectivity. 

Some specific points:

1. I think the argument for immediate authentication is weak:  for 
instance, in many networks, ARP spoofing might allow a user to act as a  
WiTM and successfully subvert TESLA authentication.

Furthermore, an adversary can send a bogus packet and hope to succeed.  
If the adversary is nearer to the sender than at least another receiver, 
then receiving, processing, re-transmitting is not as hard to assume 
that we don't need to consider the possibility.  Besides, if the goal is 
to try and confuse a receiver, the attack will work most of the time.

2.  "Immediate authentication"  combined with your suggestion of 
accepting unverifiable packets (#5 below) as legitimate, would be a 
disaster.  I also think reliance on "history" is a bad idea: after a 
stock broker, say, has been tricked into trading based on what he thinks 
is legitimate information, realizing later that the information is bogus 
would be useless.

I agree that unverifiable packets might be kept around for future 
analysis, however.

I would agree that some enhancements are necessary for real-time and 
interactive applications, but they should not come at this cost!

regards,
Lakshminath

PS:  I was wondering if disclosing soon as in case of immediate 
authentication would mean tighter time synchronization requirement.

Bob Briscoe wrote:

> Below is a thorough review. I'm afraid these comments would have been 
> more useful after draft 00. But I've moved on from group security, so 
> I don't follow the list closely. My original motivation back in 1999 
> behind thinking up what became known as TESLA (in parallel with the 
> co-authors of the TESLA intro) was to authenticate multicast RTP, so I 
> hope you will find the suggested improvements below useful.
>
> section 6), it is more a latency concern for many real-time 
> applications, particularly interactive voice (conferencing) and to a 
> lesser extent interactive video (conferencing).
>
> I explain below how you can trade-off sender memory/processing for 
> smaller packet size. In this way, we can also do stronger immediate 
> authentication than you have (against DoS) while keeping equally 
> strong delayed authentication, but completely removing the need for 3 
> of your 4 byte headers per pkt. = 12 bytes less overhead out of your 
> 38 bytes. As you say, implementations can also choose to do heavier 
> truncation of the MAC etc, to get further overhead savings.
>
> I also explain below how we might even achieve interactive-quality 
> latency in parallel to delayed authentication, rather than in series. 
> The improved immediate authentication makes this feasible.
>
> I can send you a tech report I started in 1999, with RTP uppermost in 
> my mind as an application. I'm afraid it's unfinished and therefore 
> unpublished. But the body is finished - I just never got round to 
> topping and tailing it. It gives the rationale and protocol details 
> behind all the points below, plus other stuff like how I would 
> envisage extensions to SDP for sending session security parameters for 
> TESLA. Just ask if you want a copy (PDF, 19pp including 9 figures).
>
> If you believe some of the points below impact on the TESLA intro 
> rather than SRTP-TESLA, say now. However, we have tried to accommodate 
> all these possibilities in draft-ietf-msec-tesla-intro-03.txt just 
> published. However, until re-reading my own report just now, I had 
> forgotten how I had done stronger immediate authentication (point 3/ 
> below)!
>
> The key index can be derived from the RTP timestamp in each message. 
> This saves 4 bytes in each packet.
>
> If the sender buffers packets between adding the RTP timestamp and 
> adding TESLA authentication fields, this will add to the TESLA 
> authentication delay. But a good RTP implementation shouldn't be doing 
> serious buffering here.
>
> authentication only protects against DoS by non-group members. It 
> should be RECOMMENDED not REQUIRED (section 7). Two reasons:
> i) Imagine an Internet TV application, with millions of viewers. It 
> would be silly to MANDATE the non-TESLA group authentication fields in 
> such a scenario. An attacker isn't going to be prevented from mounting 
> a DoS attack by being excluded from the group. Such large, publicly 
> accessible groups are too easy to join for group authentication to 
> make sense.
> silly to add this overhead to every packet to protect against a threat 
> of which there is no risk.
>
> Below, anyway, I show another way to do immediate authentication 
> without these group authentication fields, and it's stronger.
>
> If the time interval for switching to a new key is set to be the same 
> as that for each RTP packet, the disclosed key allows an immediate 
> rather than delayed test that affords good enough protection against 
> DoS on its own (irrespective of whether attackers are within or 
> outside the group). TESLA delayed authentication is still necessary to 
> protect against attackers with some control over the network. But you 
> get immediate 'network-dependent' authentication. I use this term to 
> mean authentication dependent on the integrity of the network, but 
> still protecting against malicious behaviour of end systems.
>
> The only way an attacker can get hold of the next key in the chain is 
> to receive the next authentic packet. It then has to extract the key 
> and use it to create its own fake packet, then overtake the original 
> packet's arrival at some or all the other receivers. This might be 
> done in the following ways:
> - watch for negative acks, and send retransmissions only to those 
> receivers affected
> - conspire with a network provider, or take over a network node to 
> delay or remove the original packets from the remainder of the 
> multicast tree
>
> I believe this 'network-dependent' authentication, where all the above 
> uses and abuses of the network are infeasible, is sufficient to 
> protect against most DoS attacks. Indeed, it gives better protection 
> against DoS than the group authentication MAC you use.
>
> sender. But the complexity only rises O(log(r)) where r is the key 
> change rate, so this isn't a big hit. See refs [21, 22] in the TESLA 
> intro draft for efficient hash traversal algorithms.
>
> The key index determines the operation of the verification algorithm - 
> viz. which key to use to create a MAC to compare with the TESLA MAC 
> field. There is no point in including this key index within the 
> coverage of the TESLA MAC (end of section 4.2, section 4.5 & 4.6). If 
> the key index is altered, the verification will fail, whether or not 
> the key index is covered by the MAC. It doesn't really matter either 
> way. It's just contrary to what the TESLA intro specifies, and 
> therefore liable to lead to confused standardistion of implementations.
>
> BTW, it should be pointed out that the verification algo should check 
> the key index is within an expected range before using it (e.g. only a 
> small increment above the last highest verified key index seen). 
> Otherwise, an attacker can tamper with this field to lead all 
> receivers to run millions of hash operations unnecessarily. I prefer 
> to call it a key-index *hint*, to remind me not to rely on it being 
> correct.
>
> It is wrong to say a packet MUST be discarded if a safe condition does 
> not hold (section 4.4 & 4.4.2). We have changed the lastest TESLA 
> intro I-D to clarify this point. It is one thing for verification to 
> fail. It is another for the verification test to not be possible (e.g. 
> due to excessive delay). In the latter case, it should be 
> application-dependent whether the packet is discarded.
>
> Instead, we have introduced the term "considered unauthenticated" for 
> such packets. There might be an internal API between the verifier and 
> the application to flag when packets are considered unauthenticated, 
> rather than dropping them (a fairly dumb implicit API). An explicit 
> API is likely to be preferred, to distinguish network loss from 
> potential attacks.
>
> For instance, if there has been no history of verification failure, 
> and the odd packet arrives too late to be verified safely, an 
> application should be within its rights to assume the *probability* of 
> such packets being authentic is high.
>
> Also, part of the application might involve analysing the cause of 
> attacks. It would be wrong to mandate discard, thus removing the 
> evidence such applications need.
>
> In the note at the end of section 4.4.2, you say decryption can be 
> done optimistically before TESLA verification. I would ask you to add 
> that some delay sensitive applications might even play-out the packets 
> optimistically before TESLA verification (still buffering the packets 
> in parallel). If TESLA verification subsequently fails, then roll-back 
> would have to be achieved at the user interface level. We have given 
> an example in the new TESLA intro.
>
> Perhaps after the TESLA bootstrapping section, a new section is 
> required to explain the implications on SRTP of disclosing the 
> remaining keys after all RTP data has finished.
>
> Nits
> ====
> A general point of style: I found the spec had too much 'knitting 
> together by reference' from other specs. As Ran said in an earlier 
> posting, it needs at least some sketching of what is referred to. 
> Otherwise it is unlikely to lead to safe standardisation of 
> implementations. Particularly given that the references themselves are 
> evolving, it becomes unsafe to expect people to find discrepancies 
> when reviewing this draft by re-reading the latest drafts of the other 
> specs each time. Sections 4.4. & 4.4.1 were particular culprits. 
> However, I also have some sympathy with the view that duplication of 
> parts of specs in other specs can lead to inconsistency.
>
> Throughout: To be consistent with the TESLA intro, the time-slot 
> index, I, should be i (lower case).
> Sec 3. "This specification assumes that the reader is familiar with 
> TESLA" repeats the same sentence in Sec 1.1.
> Sec 4.4 "If the safe condition does not hold,..." add "...and the 
> event SHOULD be logged."
> Sec 5. TESLA doesn't assume local clocks don't drift too much. Rather 
> it requires a bound on clock drift to be known.
> Notice: This contribution is the personal view of the author and does 
> not necessarily reflect the technical nor commercial direction of BT plc.

---

From: Mark Baugher <[email-masked]>
Date: Mon, 23 Aug 2004 15:48:07 -0700

Bob
   Thanks for you comments.  More below...

On Aug 19, 2004, at 12:31 AM, Bob Briscoe wrote:
<....
> lesser extent interactive video (conferencing).

I'd say that this is definitely an SRTP requirement for voice on  
low-bandwidth links.  As we know, there is a security tradeoff to  
keeping the packet size as low as possible.  When we drop the  
authentication tag and don't perform the integrity check, we're at risk  
for many types of attacks; it's arguably okay for voice packets in some  
environments but not in general, e.g. not for keying in a credit card  
using dial tones - it is a brittle solution that fails whenever one  
can't limit the channel to voice.  I personally don't like this option  
in SRTP.

In IP multicast environments, moreover, re-use of the RTP sequence  
number, rollover-counter and SSRC for AES counter mode also has its  
pitfalls:  There's exposure during SSRC collisions of known plaintext  
fields in RTP packets, late-joiners need to get the ROC as part of  
initialization, but the ROC probably should not appear in application  
signaling any more than the SSRC belongs there.  I personally don't  
like the current encryption transform in SRTP for multicast  
applications but did not grasp the problems until we took the  
specification out to the product development community.

Given all of these considerations, I think we should be prudent  
regarding bandwidth optimizations in RFC 3711 for IP multicast.  We  
sure don't want to multicast SRTP without some message authentication.   
We may want to consider changes to the encryption transform for  
multicast, but this is another story.

> TESLA. Just ask if you want a copy (PDF, 19pp including 9 figures).

Please send it to me - unicast.
> 1/ Key index field is redundant with SRTP
I would not say that two fields are redundant if they perform different  
functions, which I think is the case here.  We would need to do a  
complete analysis of how the timestamp is used today in RTP  
applications before we can evaluate how safe this would be for all  
applications.  I'd prefer to not overload an existing field in this way  
if we can avoid it.
> authentication delay. But a good RTP implementation shouldn't be doing  

What about high-bandwidth, server/playback media such as movies?  In  
fact, let me try this:  What about an MPEG packetizer that does a lot  
of pre-processing of the MPEG AUs prior to assigning them to packets.   
This might happen because the AUs were encrypted and required a lot of  
pre-processing.  Maybe there would be a two-step process applied to one  
or more AUs in which timetamps are assigned during some processing and  
then everything gets sent.
Maybe such a problem can be avoided in packetizers.  There are a lot of  
considerations when we take an existing field such as the RTP timestamp  
and add new functions to it.

If the functions are really identical, then they are redundant.  I tend  
to doubt that.

> should be RECOMMENDED not REQUIRED (section 7).

I think that this point should be resolved in the base TESLA  
specification, i.e. I don't think there is anything that is  
SRTP-specific to this point.  But we did not treat it that way in  
SRTP-TESLA, and that's probably my fault.  Nonetheless, I think it  
should be REQUIRED in base TESLA.

> Two reasons:

I see your point.  Maybe it should just be RECOMMENDED, but I still  
think that we will have a more robust solution at very little cost if  
the check were just done.  There are >200 TV channels in US digital  
cable and satellite offerings today and this will grow to include more  
narrowcasting.  We don't want a special interest channel to be  
vulnerable to the particular opponents of that special interest.  Sure,  
the channel could be so large as to include opponents, but rogue  
members can be removed and the keys changed.

I don't know why we would not err on the side of more cautious than  
less.

> of which there is no risk.

Phishing attacks were pretty much unknown before the mid-90s and worms  
prior to the late 80s.  I'd say the existence of the vulnerability is  
what we should focus on, first and foremost, and not the history of  
exploits against the vulnerability.
> 3/ Non-TESLA group authentication to protect against DoS is redundant

I think I get your point and I think it's largely independent of the  
previous two points or at least, this stands by itself.  The dos by a  
non-group member relies upon the fact that memory gets tied up while  
packets are buffered awaiting authentication.  In this case, there is  
no buffering of multiple packets, just one packet during the disclosure  
interval.  Do I understand you correctly?
> protocol that has been used for years (IETF RFC1760 based on Lamport).

Your proposal is a configuration option.  This option requires that ALL  
SRTP-TESLA applications change the key on each packet, in order to  
forgo the MAC.  But if this is true for SRTP, it's likely true for most  
TESLA applications.  Are the TESLA authors quite sure that all or most  
TESLA applications can tolerate a key change per packet?  If so, why  
not put this in the core TESLA specification.  I'd say that if it  
belongs in SRTP-TESLA, then it belongs in the core specification.  No?

> 4/ No need to include the key index, i, in the TESLA authenticated  

I agree.
> to call it a key-index *hint*, to remind me not to rely on it being  

This sounds like an argument for keeping the MAC.
> 5/ Discard if a packet cannot be authenticated should be optional

This sounds reasonable to me.
> 6/ Play-out may be in parallel to buffering awaiting authentication

I intended to say that all processing might proceed optimistically for  
applications where roll-back or notification of authentication-failure  
is possible.
> 7/ TESLA tail piece section required

Yes, David McGrew pointed this out to us previously.

We'll refer to your editorial comments at the next revision.

thanks, Mark

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 30 Aug 2004 13:51:16 +0100

Mark,

>can't limit the channel to voice.  I personally don't like this option

I'm not sure whether you're misunderstanding me, or just agreeing, but 
sounding as if you disagree. In no way am I proposing anything that doesn't 
do strong integrity checking. TESLA can strongly verify packets from tone 
dialling as much as from any other application, whether voice or not. The 
ONLY point at issue with TESLA is that it doesn't protect against a 
flooding attack during the key disclosure delay.

>specification out to the product development community.

Relevant to the discussion of key indexes - see later.

>sure don't want t multicast SRTP without some message authentication.

To be crystal clear, nowhere have I proposed anything that removes message 
authentication. TESLA authentication/integrity/replay checking is as good 
without the group authentication tag as with it, albeit delayed. The 
discussion is purely about how to protect against flooding attacks 
immediately on arrival of a packet, to prevent having to buffer attacker's 
packets until TESLA delayed authentication can be used once the TESLA key 
is disclosed.

Having thought about it, I will be stronger than the last mail and say a 
group MAC will provide barely any additional protection in most 
circumstances so should not be the default. The logic of using a group MAC 
with TESLA looks like this:

     Sender's level of trust in group members not to spoof packets
                 |         using a group key?           |
                Low                                   High
                 |                                      |
  Use source authentication (ie TESLA).         Use group authentication.
                 |
  TESLA is vulnerable to DoS filling buffer
      until delayed auth
                 |
  Use group authentication alongside TESLA
    (as in current SRTP draft)

I hope this diagram helps highlight the broken logic. Group authentication 
is being MANDATED in the SRTP draft in a scenario which only ever arises 
where the group isn't trusted. Adding group authentication to TESLA only 
provides any additional value for the narrow range of scenarios where group 
members aren't trusted enough to use group authentication alone, but they 
are trusted sufficiently that group authentication might detect some DoS 
attacks - pretty slim odds. Worth allowing as an option, but surely not 
MANDATING.

>Please send it to me - unicast.

Sent.

>applications.  I'd prefer to not overload an existing field in this way

I had thought about the ramifications fairly carefully before saying this. 
I suggest that the way to deal with the TESLA time interval identifier, I, 
is to:
- remove I from the default TESLA-SRTP packet format
- explain how to derive I from the RTP timestamp
- MANDATE that a sender authentication module should use a TESLA key 
interval derived from the RTP timestamp, not the clock
- warn implementors that any delay in the sender stack will add to the 
TESLA authentication delay (but not weaken it)
- (if we can think of any other problems ) warn implementors what to watch 
out for when overloading the RTP timestamp function (I'm fairly sure there 
aren't any - and I've thought long and hard)
- make I optional in the TESLA-SRTP packet format for implementors to use 
if they are in one of these obscure scenarios

>and add new functions to it.

As long as we mandate that the TESLA sender uses the key appropriate to the 
time interval derived from the RTP timestamp (not from the clock), the 
protocol is safe. The TESLA safety test is still accurate.

Any delay after RTP has determined its timestamp then folds into the delay 
between sender and receiver that TESLA is designed to handle safely. Of 
course, this makes the delay longer, which /delays/ authentication. But it 
doesn't /weaken/ authentication. See section 4 of the TESLA intro for 
discussion of similar scenarios (eg TCP buffering).

If authentication delay is a problem for a particular scenario, and it's 
some odd scenario like you suggest where a large part of the delay is 
within the sender stack between RTP and TESLA, then the implementor can 
choose to use an explicit I in the packet.

>If the functions are really identical, then they are redundant.  I tend

I'd rather say that the functions of the two fields are invariably 
equivalent, but may not be in some scenarios, when it's up to the 
implementor to use the option of an explicit I.

>>----------------------------------------------------------------------- ----

Currently section 5 (security considerations) of the TESLA-intro mentions 
group authentication as one possible way of preventing flooding attacks 
during the key disclosure delay. But it doesn't MANDATE it. I'm simply 
taking issue with group authentication being MANDATED in SRTP-TESLA, as I 
don't think it's effective in many (most?) scenarios, making it unnecessary 
overhead.

I have no problem with making a group MAC optional for scenarios where it 
does improve matters.

>the check were just done.

IMHO, a default of 10 octets per RTP packet is a high additional cost to 
MANDATE, which means interoperable implementations must carry it even when 
it serves no purpose. Whether or not you agree with me about the prevalence 
of scenarios that don't need it, you do agree that the TV one doesn't (and 
I give another example below). So why MANDATE something that isn't always 
needed?

>There are >200 TV channels in US digital

Even if there were no alternative to protect against flooding (tho I 
believe 3/ below is an alternative), it would be wrong to MANDATE a field 
that sometimes serves no purpose.

>exploits against the vulnerability.

Sorry, history was a distracting word. I meant likelihood. Imagine a video 
conf between senior execs of competing companies, or between 
representatives of mutually distrusting governments. They don't trust each 
other not to spoof what the other parties are saying, but they have no 
likelihood of one launching a flooding attack on the other (e.g. the whole 
thing is over a joint VPN). They need group authentication like a phish 
needs a bicycle. So why MANDATE it?

>previous two points or at least, this stands by itself.

Orthogonal-ish... if there is an alternative to a group MAC for detecting 
flooding, it makes a group MAC even less necessary to MANDATE (not wishing 
to labour the point ;)

>The dos by a
>non-group member

or a group member

>relies upon the fact that memory gets tied up while

No. The disclosure *interval* (delay) still spans multiple packets. The new 
feature depends on each key now only ever being *disclosed* once, rather 
than the same key being disclosed repeatedly as it was when there were 
multiple packets in the same TESLA time interval.

As soon as a packet arrives, the disclosed key in it now has two purposes:
- it's original TESLA purpose: to verify a packet received some time previously
- to immediately show the receiver that the sender of this packet knew the 
next key back along the hash chain which is now only ever *disclosed* once

So if more packets are received that *disclose* the same key, the receiver 
can assume (at least until the delayed TESLA verification) that only the 
first packet to disclose each key was genuine.

If a network element is compromised, an attacker can discover the next 
disclosed key and overtake or replace a genuine packet with many others. 
But the receiver can still immediately discard all but the first to arrive, 
protecting itself from memory overflow.

So the scheme has the following properties:
- The receiver will never buffer more than one packet per packet sent by 
the genuine sender (so the receiver's buffer fill rate is still clocked by 
the party that reveals each new key backwards in the chain).
- As each key is later disclosed, TESLA can do delayed verification of 
these stored packets.
   - if they pass delayed verfication, the messages must be genuine
   - if they fail delayed verfication, the messages must not have been genuine
- The true message will have been lost in the latter case. But, then if an 
attacker can compromise a network element, it can discard the true messages 
anyway (a group MAC can't prevent this either ;)

I need to fully document this. There are some corner cases not covered by 
the above. I've given an outline later. Obviously, this DoS protection idea 
hasn't had the same peer-review as TESLA, except it is essentially just 
S/KEY, which has had ample peer review (but perhaps not in a group setting).

>>The tech report gives a more exact definition of the tests.

For completeness, I'll give a more precise description of the change I'm 
proposing here. Note when I use the term key index, it might be derived 
from other info in the RTP header, rather than explicitly declared in each 
packet:

The sender:
The sender uses a new key back along the hash chain for each packet. It 
guarantees not to disclose any key for the disclosure delay. It must 
therefore delay disclosure for a number of packets (not a time), but 
calculated from the fastest sustained overall packet rate that it 
guarantees not to exceed for any future window of time with a duration of 
the disclosure delay.

The receiver:
1/ Immediately on reception, the receiver does these tests:
    o) Session DoS mitigation tests: check arriving packets have valid IP 
addresses and port numbers for the session
    i) CPU DOS mitigation test: checks the key index of the arriving packet 
is within a reasonable distance (say 64) of the previous highest index received
    ii) S/KEY DoS mitigation test: checks that the TESLA key disclosed in 
the packet fits into the hash chain where its index says it should
    iii) flooding DoS mitigation test: discards second and subsequent 
disclosures of the same key (this test is complicated by packet misordering 
- I have held back 5 paras on that - this mail is already too long)
    iv) the regular TESLA delay safety test to determine whether the key 
used is guaranteed not to have been disclosed yet
2/ it then buffers the packet to await regular TESLA delayed verification 
if all tests pass
3/ Later, when the key for this packet is disclosed, the receiver does 
TESLA regular verification.

>TESLA applications can tolerate a key change per packet?

As an option, it would only be used where the app could tolerate this. The 
key change per packet isn't a problem per se (just two more hashes for sndr 
& rcvr). It's the storage of the longer key chain for the sndr (O log(n)), 
or the alternative of only storing regular keys along it and re-running the 
calculations for those between.

>If so, why

You are absolutely correct.

We (the co-authors of the TESLA base spec) are discussing this off-line 
right now. It's my fault we didn't reach closure on it before TESLA got 
this far. I was originally pushing this as an option, but I think I never 
quite got myself understood. Somewhere in the mists of time I gave up. I've 
been taking a back seat on the TESLA work until just recently, so my brain 
obviously wasn't in gear when reviewing drafts. I forgot I'd got this 
option to attack the DoS problem. It was only through reveiwing the SRTP 
draft that the technique came back to me. Now, the more I argue about it, 
the better I think it is.

However, it's not out of the woods yet. My co-authors are trying to break 
it. I believe I've defended it in the case of variable packet rate and 
packet misordering. But I'm expecting more attempts to break it (and, of 
course, anyone on this list is welcome to try as well).

If it comes out intact, you should see text on it shortly. Otherwise, I 
guess the TESLA base spec will stay as it is.

>>----------------------------------------------------------------------- ---
>
>I agree.

No. It is an argument for watching that it doesn't appear to imply packets 
are extremely re-ordered (e.g. it must be no more than, say, 64 different 
from the previous highest index, cf the SRTP replay protection window). You 
/could/ use a group MAC to do an initial test of its integrity, but why 
waste 10 octets when you can do a test that uses none? And this would only 
work if you trusted the group members (recall, we are using TESLA because 
we don't trust them).

The key index is implicitly authenticated (similar to the implicit header 
authentication in section 9.5.2 of the SRTP RFC) because the TESLA MAC 
depends on it. If the key index is tampered with, the authentication test 
will fail as it should.

>We'll refer to your editorial comments at the next revision.

I've added a couple more below...

>thanks, Mark

And many thanks to you too, for doing all the hard work on these drafts.

more comments follow...

>>parts of specs in other specs can lead to inconsistency.

The particular point was that the TESLA delay safety test is missing from 
4.4.2, but strictly you have said it must be done earlier (in 4.4) by 
referring to the TESLA-intro. I think it should be in the list of things 
the receiver should do.

>>index, I, should be i (lower case).

I now realise that lower case i would conflict with the SRTP spec.

>>Sec 4.3 bullet 10 "...based up the..." --> "...based upon the..."

Sec 4.3 bullet 10, uses same n_c notation as bullet 2 (but for something else)

>>Sec 4.4 "If the safe condition does not hold,..." add "...and the

Sec 4.4.2: "...perform verification of the SRTP integrity protection 
tag..." this terminology hasn't been used in this draft (it was in SRTP). 
Here it is just labelled the SRTP MAC.
Sec 4.4.2: "...using the rollover counter from the current packet,..." -> 
"...using the rollover counter from the current context,..."
Sec 4.5: It might be worth starting this section by discussing the 
applicability of authenticating RTCP receiver reports in large-scale 
multicast settings. Possibly referring to section 11.2 and other parts of 
the SRTP spec on the applicability and scalability of RTCP authentication 
in multicast.

>>Sec 7. "...noted that the all TESLA security..." sentence garbled.

Cheers

Bob

---

From: Mark Baugher <[email-masked]>
Date: Mon, 30 Aug 2004 10:49:52 -0700

Bob,
   I reply to many of your points below, but here is something I'd like  
for you and your co-authors to consider:  Apart from reusing the RTP  
timestamp field the issue you raise in point 3 is a general TESLA issue  
and not an SRTP-TESLA issue.  I think this is also true for guidance on  
the use or non-use of a group MAC, which is related to your point 3.   
I'd like to see these points treated in a general way so why not  
critique the base TESLA spec on this point and not SRTP-TESLA?

   More below...
On Aug 30, 2004, at 5:51 AM, Bob Briscoe wrote:
...
> sounding as if you disagree. In no way am I proposing anything that  
> doesn't do strong integrity checking.

I understand that.

...
> Having thought about it, I will be stronger than the last mail and say  
> a group MAC will provide barely any additional protection in most  
> circumstances so should not be the default. The logic of using a group  
> MAC with TESLA looks like this:
>
> I hope this diagram helps highlight the broken logic.
> Group authentication is being MANDATED in the SRTP draft in a scenario  
> which only ever arises where the group isn't trusted.

Trusted to do or not do what?  I think in this case, "trusted" means  
"trusted not to launch a denial of service attack against the group."   
There is also "trusted not to capture a disclosed key to successfully  
impersonate a group sender."  Further, there is "trusted not to  
disclose a group key" - and so on.  Treating something as complicated  
as this as "high" or "low" is not persuading me, personally.

> dding group authentication to TESLA only provides any additional value  
> for the narrow range of scenarios where group members aren't trusted  
> enough to use group authentication alone, but they are trusted  
> sufficiently that group authentication might detect some DoS attacks -  
> pretty slim odds. Worth allowing as an option, but surely not  
> MANDATING.

You see a waste of time and bandwidth for protection that is  
superfluous.  I see a relatively cheap way to keep a group protected  
against anyone running a kiddie script who decides to send a burst of  
packets and overflow members' buffers.  Let's gather some more opinion  
from msec on this point IF IT IS NOT MADE MOOT BY YOUR POINT 3, BELOW.
...
>
> I had thought about the ramifications fairly carefully before saying  
> this. I suggest that the way to deal with the TESLA time interval  
> identifier, I, is to:

I may have confused you in my last note in trying to explain all the  
ways that I think overloading protocol fields for security purposes is  
generally not a good idea.  Let me try to state this clearly: The RTP  
timestamp is used for specific purposes for RTP payload types that are  
unrelated to sender authentication, and it is quite possible that we  
will either interfere with these uses by placing TESLA-induced  
constraints on that field or weaken TESLA security when we find  
surprising uses are made of that field by certain applications.

Re-use of the RTP Timestamp in TESLA can be easily avoided by adding a  
TESLA timetamp field in the packet.  I think the points you are raising  
are important and helpful to SRTP-TESLA.  But it would helpful if you  
separated them I think.  Re-use of the RTP timestamp, the non-mandatory  
group MAC, and your proposal under point 3 can stand by themselves.  I  
think we have 3 threads here and not one.

> - (if we can think of any other problems ) warn implementors what to  
> watch out for when overloading the RTP timestamp function (I'm fairly  
> sure there aren't any - and I've thought long and hard)

I'd prefer to use a separate field.  At minimum, I would take this to  
AVT for further discussion.  I don't think the gain from overloading is  
worth any unexpected pitfalls, particularly security pitfalls.  RTP is  
a special beast because it is used in so many types of applications,  
from telephony to client/server multimedia, from unicast-pairwise to  
unicast-group, small multicast conferences to large-scale broadcast,  
etc.

> - make I optional in the TESLA-SRTP packet format for implementors to  
> use if they are in one of these obscure scenarios
>
>
> As long as we mandate that the TESLA sender uses the key appropriate  
> to the time interval derived from the RTP timestamp (not from the  
> clock), the protocol is safe. The TESLA safety test is still accurate.
>
> Any delay after RTP has determined its timestamp then folds into the  
> delay between sender and receiver that TESLA is designed to handle  
> safely. Of course, this makes the delay longer, which /delays/  
> authentication. But it doesn't /weaken/ authentication. See section 4  
> of the TESLA intro for discussion of similar scenarios (eg TCP  
> buffering).
>
> If authentication delay is a problem for a particular scenario, and  
> it's some odd scenario like you suggest where a large part of the  
> delay is within the sender stack between RTP and TESLA, then the  
> implementor can choose to use an explicit I in the packet.

TESLA is complex enough without adding protocol dependencies like this  
in my view.

> implementor to use the option of an explicit I.

This new option will double the signaling, implementation, testing, and  
operational complexity of the protocol.
>>> -- ----
> Currently section 5 (security considerations) of the TESLA-intro  
> mentions group authentication as one possible way of preventing  
> flooding attacks during the key disclosure delay. But it doesn't  
> MANDATE it. I'm simply taking issue with group authentication being  
> MANDATED in SRTP-TESLA, as I don't think it's effective in many  
> (most?) scenarios, making it unnecessary overhead.
>
> I have no problem with making a group MAC optional for scenarios where  
> it does improve matters.

I don't have a lot of religious fervor on the topic either though I  
like to avoid options in security protocols whenever possible.  What  
seemed fairly obvious to me obviously seems wasteful to you.  I'd like  
to discuss this further in a separate thread.  We are really discussing  
a security requirement for protecting groups.
...

>
> Sorry, history was a distracting word. I meant likelihood. Imagine a  
> video conf between senior execs of competing companies, or between  
> representatives of mutually distrusting governments. They don't trust  
> each other not to spoof what the other parties are saying, but they  
> have no likelihood of one launching a flooding attack on the other  
> (e.g. the whole thing is over a joint VPN). They need group  
> authentication like a phish needs a bicycle. So why MANDATE it?

We are beating this to death and confusing one another.  The  
participants would not launch the flooding attack; an interloper would  
do it.  If it's over a VPN, then the attack seems very unlikely - as is  
source spoofing in a small teleconference, for that matter.
...
> No. The disclosure *interval* (delay) still spans multiple packets.  
> The new feature depends on each key now only ever being *disclosed*  
> once, rather than the same key being disclosed repeatedly as it was  
> when there were multiple packets in the same TESLA time interval.

Before we go any further into this, I'd like to understand why this  
disclosure scheme needs to be considered only for SRTP.  You mention  
below that you also think that it belongs in the base TESLA  
specification and that you have raised the issue with your co-authors?   
I think the TESLA co-authors might want to consider discussing this on  
the list.  That sounds better than treating SRTP-TESLA as the poster  
child for something that was maybe overlooked in the base TESLA  
document.

I just got back from some personal time off and am working through  
several hundred messages - I prioritized yours.  It would be a more  
efficient discussion to discuss this with the TESLA authors - on the  
msec list if possible.

> - to immediately show the receiver that the sender of this packet knew  
> the next key back along the hash chain which is now only ever  
> *disclosed* once
>
> So if more packets are received that *disclose* the same key, the  
> receiver can assume (at least until the delayed TESLA verification)  
> that only the first packet to disclose each key was genuine.
>
> disclosed key and overtake or replace a genuine packet with many  
> others. But the receiver can still immediately discard all but the  
> first to arrive, protecting itself from memory overflow.
>
> - The receiver will never buffer more than one packet per packet sent  
> by the genuine sender (so the receiver's buffer fill rate is still  
> clocked by the party that reveals each new key backwards in the  
> chain).
> - The true message will have been lost in the latter case. But, then  
> if an attacker can compromise a network element, it can discard the  
> true messages anyway (a group MAC can't prevent this either ;)
>
> I need to fully document this. There are some corner cases not covered  
> by the above. I've given an outline later. Obviously, this DoS  
> protection idea hasn't had the same peer-review as TESLA, except it is  
> essentially just S/KEY, which has had ample peer review (but perhaps  
> not in a group setting).

This sounds promising to me, but I would like to see the document - I  
have not read the one you sent me yet.  And I would like to hear what  
the other TESLA authors have to say about it.

...
> We (the co-authors of the TESLA base spec) are discussing this  
> off-line right now. It's my fault we didn't reach closure on it before  
> TESLA got this far. I was originally pushing this as an option, but I  
> think I never quite got myself understood. Somewhere in the mists of  
> time I gave up. I've been taking a back seat on the TESLA work until  
> just recently, so my brain obviously wasn't in gear when reviewing  
> drafts. I forgot I'd got this option to attack the DoS problem. It was  
> only through reveiwing the SRTP draft that the technique came back to  
> me. Now, the more I argue about it, the better I think it is.
>
> However, it's not out of the woods yet. My co-authors are trying to  
> break it. I believe I've defended it in the case of variable packet  
> rate and packet misordering. But I'm expecting more attempts to break  
> it (and, of course, anyone on this list is welcome to try as well).
>
> If it comes out intact, you should see text on it shortly. Otherwise,  
> I guess the TESLA base spec will stay as it is.

And this sizable email exchange would be in vain :?)

...
> No. It is an argument for watching that it doesn't appear to imply  
> packets are extremely re-ordered (e.g. it must be no more than, say,  
> 64 different from the previous highest index, cf the SRTP replay  
> protection window). You /could/ use a group MAC to do an initial test  
> of its integrity, but why waste 10 octets when you can do a test that  
> uses none? And this would only work if you trusted the group members  
> (recall, we are using TESLA because we don't trust them).

The group MAC was originally 4 bytes and I need to check with  
Elisabetta to find out why it is now 10.  I don't see why it needs to  
be larger than 4 bytes for group MAC purposes.  If we manage to obviate  
the need for group MACs in TESLA, then it can be zero bytes and I'll be  
perfectly happy.
>
> The key index is implicitly authenticated (similar to the implicit  
> header authentication in section 9.5.2 of the SRTP RFC) because the  
> TESLA MAC depends on it. If the key index is tampered with, the  
> authentication test will fail as it should.

Ok.
...
> I've added a couple more below...

Good.  How do you feel about my proposal to consider the proposed use  
of the RTP timestamp field separately from the group MAC.  And treat  
the group MAC as a related question to your point 3 scheme?

thanks, Mark
> The particular point was that the TESLA delay safety test is missing  
> from 4.4.2, but strictly you have said it must be done earlier (in  
> 4.4) by referring to the TESLA-intro. I think it should be in the list  
> of things the receiver should do.
>
>
> tag..." this terminology hasn't been used in this draft (it was in  
> SRTP). Here it is just labelled the SRTP MAC.
> Sec 4.4.2: "...using the rollover counter from the current packet,..."  
> -> "...using the rollover counter from the current context,..."
> multicast settings. Possibly referring to section 11.2 and other parts  
> of the SRTP spec on the applicability and scalability of RTCP  
> authentication in multicast.
>