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

From: <[email-masked]>
Date: Mon, 30 Aug 2004 14:39:10 -0400

Just trying to understand from confusing inlining....

One of the high order bits of the discussion is the question:

	Should Group-MAC, to provide group authentication and prevent
	DoS attacks from outside the group, be MANDATED or NOT?

and the related question:

	The base TESLA intro draft does not mandate it, how come
	SRTP-TESLA draft is mandating it?

Thinking out loud, mandating Group-MAC has the advantage of less interoperability
woes. On the flip side making it optional has the advantage of saving byte-overhead
per packet and a bit of computation time, when Group-MAC is not used. Mark, points
out extra space needed should actually be 4 bytes as opposed to 10 bytes mentioned
in the SRTP-TESLA draft.

Since presence of Group-MAC can be a group policy, which in the case of Multicast
security is enforced rather than negotiated, I would guess interoperability issues
should not crop up. So making it optional may not actually lead to interoperability
woes.

What do other members on MSEC mailing list think? Mandate or not Mandate Group-MAC
in the base TESLA protocol? IMHO, Once we decide that, we can talk about what to do
in SRTP-TESLA, if at all any different.

Best,
Atul

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Mark Baugher
> Sent: Monday, August 30, 2004 1:50 PM
> To: Bob Briscoe
> Cc: [email-masked]; [email-masked]
> Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long)
> 
> 
> 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:
> >
> ...
> > 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.
> 
> 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:
> >
> >     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.
> 
> 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:
> > - remove I from the default TESLA-SRTP packet format
> > - explain how to derive I from the RTP timestamp
> 
> 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.
> 
> > - 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)
> 
> 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
> >
> >
> >>> 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.
> >>
> >> 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.
> >
> > 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.
> 
> >
> >> If the functions are really identical, then they are 
> redundant.  I  
> >> tend
> >> to doubt that.
> >
> > 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.
> 
> This new option will double the signaling, implementation, 
> testing, and  
> operational complexity of the protocol.
> >
> >
> >>> 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).
> >>
> >> 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.
> >
> > 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.
> >
> ...
> >
> >> 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?
> >
> > 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.
> 
> >
> > 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).
> 
> 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.
> >
> >
> 
> ...
> >> 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?
> >
> > 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.
> 
> And this sizable email exchange would be in vain :?)
> >
> >
> 
> ...
> >>> 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.
> >>
> >> This sounds like an argument for keeping the MAC.
> >
> > 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.
> >
> >
> ...
> >>
> >> We'll refer to your editorial comments at the next revision.
> >
> > 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
> >
> >> thanks, Mark
> >
> > And many thanks to you too, for doing all the hard work on these  
> > drafts.
> >
> > more comments follow...
> >
> >
> >>> 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.
> >
> > 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.
> >
> >
> >>> Throughout: To be consistent with the TESLA intro, the time-slot
> >>> index, I, should be i (lower case).
> >
> > I now realise that lower case i would conflict with the SRTP spec.
> >
> >>> 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.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
> >>> event SHOULD be logged."
> >
> > 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 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.
> >
> >
> > Cheers
> >
> >
> >
> > 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
> >
> 
> _______________________________________________
> msec mailing list
> [email-masked]
> http://six.pairlist.net/mailman/listinfo/msec
> 
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: Mark Baugher <[email-masked]>
Date: Mon, 30 Aug 2004 12:59:59 -0700

Thanks for the summary.  There is also the point about re-using the RTP 
timestamp in place of the TESLA key identifier.  And Bob has proposed a 
way to obviate the need for a group MAC with a TESLA innovation that 
his co-authors are considering.

Even if Bob's idea is accepted, the discussion on whether or not to 
mandate group authentication in a TESLA protocol is probably time well 
spent.

Mark

---

From: canetti <[email-masked]>
Date: Tue, 31 Aug 2004 00:14:25 -0400 (EDT)

Jumping into a very long discussion, wanted to say few short things:

1. I think that the TESLA intro draft should contain a better
comparative discussion of anti-DOS methods, including weaknesses and
strengths, and recommendations for use in different scenarios.
however I DONT think that the intro draft should (or can) mandate any one
method. Remember, this is an informational draft, not a dtandard.

In contrast, tesla-srtp, and also the comingrealsoonnow tesla-esp are
standards, and therefore they should each choose one DOS protection method,
that is suitable to their respective scenarios.

I am ok with tesla-srtp using the current external MAC method, especially
since SRTP already has an external MAC mechanism in place. But I dont feel
strongly here at all, mainly since none of the suggested methods is
completely superior to other methods. all have their own strengths and
weaknesses. I'd thus opt for doing the simplest thing... whatever that
might be.

That said, I think it is reasonable to reduce the extenal MAC in tesla-srtp to
RECOMMENDED. Indeed, as Bob points out, in some scenarios it might be
totally unneeded and only be a babdwidth deadweitght. (still, the security
considerations section ahould make it crystal clear what are the tradeoffs
here.

2. I think that Bob's idea of having the receiver infer the interval
number from the RTP timestamp may work in some/many cases. But it might
make the programming more delicate and harder to get right. One potential
solution is just to opt for a more robust design at the price of extra 4
bytes p.p. altenratively, we can make  the interval number optional and
leave it up to the implementation whether it wants to save the extra 4
bytes or not.

Ran