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

From: Bob Briscoe <[email-masked]>
Date: Thu, 02 Sep 2004 09:03:28 +0100

Mark,

At 18:49 30/08/2004, Mark Baugher wrote:
>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?

Yup, for the DoS prevention, Ran Canetti has proposed we need to add a more 
formal DoS mitigation section to TESLA-intro.

This mail thread just goes to show how getting specific about a protocol 
(SRTP) feeds back to the generic description. It was only when we got to 
the specifics that the issues became clear. I'll stop pestering you for a 
while on point 3/ (DoS prevention).

On use/non-use of group MAC, TESLA-intro won't MANDATE anything. It's 
informational.

More inline.

>   More below...
>On Aug 30, 2004, at 5:51 AM, Bob Briscoe wrote:
>...
>>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.

I started out the diag making clear the trust context, but yes, it got 
munged into unspecified trust in the explanatory para after. SOrry. I think 
it best if I write all the applicability stuff into a new DoS sectino in 
the TESLA-intro, then we can have this debate with some clarity.

I hope to do this while the issue is fresh - next few days, but...

>>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.

The S/KEY-like scheme in point 3/ is an alternative, but it's now different 
to what I described following Adrian Perrig knocking it down,... me fixing 
it,... then Adrian agreeing it's now OK. It's now a good option for fixed 
or nearly-fixed packet rate (eg audio), but needs applicability carefully 
explaining for highly variable packet rate (eg video).

I've agreed to document three DoS mitigation possibilities in a next 
TESLA-intro draft:
* check that the disclosed key fits the chain (simple but weak - always 
worth doing)
* group MAC
* disclose & use new key each packet

I think it's best to wait for that before the debate on what 
defaults/options/transforms there should be in SRTP-TESLA.

I've split the remaining reply into separate threads for each numbered 
issue I raised at least those still up for debate, as requested. THey are 
all orthogonal.

>>>>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?

Yup. Done.

Cheers

Bob

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      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: Mark Baugher <[email-masked]>
Date: Sun, 12 Sep 2004 15:49:19 -0700

hi Bob
   Just to recap this thread:  We agreed to make the group MAC a  
RECOMMENDED feature rather than required.  We'll use you editorial  
comments as a guide when we make the next update to the specification.   
And we'll look forward to reviewing DoS points in a subsequent revision  
of the base TESLA I-D.

thanks, Mark
On Sep 2, 2004, at 1:03 AM, Bob Briscoe wrote:

> Yup, for the DoS prevention, Ran Canetti has proposed we need to add a  
> more formal DoS mitigation section to TESLA-intro.
>
> This mail thread just goes to show how getting specific about a  
> protocol (SRTP) feeds back to the generic description. It was only  
> when we got to the specifics that the issues became clear. I'll stop  
> pestering you for a while on point 3/ (DoS prevention).
>
> munged into unspecified trust in the explanatory para after. SOrry. I  
> think it best if I write all the applicability stuff into a new DoS  
> sectino in the TESLA-intro, then we can have this debate with some  
> clarity.
>
> The S/KEY-like scheme in point 3/ is an alternative, but it's now  
> different to what I described following Adrian Perrig knocking it  
> down,... me fixing it,... then Adrian agreeing it's now OK. It's now a  
> good option for fixed or nearly-fixed packet rate (eg audio), but  
> needs applicability carefully explaining for highly variable packet  
> rate (eg video).
>
> * check that the disclosed key fits the chain (simple but weak -  
> always worth doing)
> * group MAC
> issue I raised at least those still up for debate, as requested. THey  
> are all orthogonal.
>
>
>
>>>>> ------------------------------------------------------------------- 
>>>>> -- -- ----

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 14 Sep 2004 17:58:19 +0100

Mark,

>And we'll look forward to reviewing DoS points in a subsequent revision

Yup.

I've quoted my five original points below with the resolutions so far, as 
far as I understand them.

>1/ Key index field is redundant with SRTP
= Debate current on list (Replies to that thread not this, pls)

>2/ Non-TESLA group authentication to protect against DoS should be
= Agreed should be RECOMMENDED

>3/ Non-TESLA group authentication to protect against DoS is redundant
= Related to point 2/ and depends on write-up of alternative DoS protection 
in a new TESLA-intro (I sent a new draft to my co-authors last Fri for 
sanity checking - should be on the msec list soon).

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

>5/ Discard if a packet cannot be authenticated should be optional
= Agreed

>Nits
= To be considered in next draft.

Cheers

Bob

>>_______________________________________________________________________ _____

---

From: Mark Baugher <[email-masked]>
Date: Tue, 14 Sep 2004 11:55:22 -0700

hi Bob

On Sep 14, 2004, at 9:58 AM, Bob Briscoe wrote:
...
>> 5/ Discard if a packet cannot be authenticated should be optional

I did not sign up for this one - or at least I did not mean to.  I'd  
like to discuss this some more.  Personally, I want to limit options  
wherever possible and this is the second option (including making the  
group optional) that you have proposed.  I don't think we necessarily  
want to add this particular option and would like to hear what others  
have to say on the matter.

thanks, Mark
>>>>> sufficiently that group authentication might detect some DoS  
>>>>> attacks
>>>>> -
>>>>>>> ----------------------------------------------------------------- 
>>>>>>> -- -- -- ----

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Tue, 14 Sep 2004 15:07:34 -0400

Hi Bob,

I am not sure there was consensus on issue #5 below.  I don't think it 
is a good idea to allow a packet to be considered authenticated, when a 
receiver is not sure about it.  Historically speaking, there were a lot 
of doubts on TESLA with the time synchronization issues: but it looks 
like many of us are ready to make that leap in pursuit of efficiency, 
but this guideline would make the protocol insecure!

In fact, I recall Hugh raising this issue at a meeting once, and was 
convinced only after hearing the assertion that unverifiable packets 
would be dropped!

On your wording: when you say optional, do you mean "MAY"?  I would 
stick to the current specification: receivers MUST drop packets if they 
cannot verify them.

regards,
Lakshminath

= Agreed

---

From: Mark Baugher <[email-masked]>
Date: Tue, 14 Sep 2004 12:24:40 -0700

On Sep 14, 2004, at 11:55 AM, Mark Baugher wrote:

> group optional)

sorry, I meant "group MAC optional"

Mark
> that you have proposed.  I don't think we necessarily want to add this  
> particular option and would like to hear what others have to say on  
> the matter.
>
> thanks, Mark
>>
>>> Nits
>>>>> and not an SRTP-TESLA issue.  I think this is also true for  
>>>>> guidance
>>>>> on
>>>>>>>> ---------------------------------------------------------------- 
>>>>>>>> --- -- -- ----
>>>>> do it.  If it's over a VPN, then the attack seems very unlikely -  
>>>>> as
>>>>> is
>>>>>>> packets are buffered awaiting authentication.  In this case,  
>>>>>>> there
>>>>>>> is
>>>>>> - As each key is later disclosed, TESLA can do delayed  
>>>>>> verification
>>>>>> of
>>>>>> these stored packets.
>>>>>> protection idea hasn't had the same peer-review as TESLA, except  
>>>>>> it
>>>>>> is
>>>>> the need for group MACs in TESLA, then it can be zero bytes and  
>>>>> I'll
>>>>> be
>>>>> perfectly happy.
>>>>>>
>>>> B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.   +44  
>>>> 1473
>>>> 645196
>>>>