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

From: Bob Briscoe <[email-masked]>
Date: Thu, 02 Sep 2004 07:23:27 +0100

Atul,

At 19:39 30/08/2004, [email-masked] wrote:

>Just trying to understand from confusing inlining....

I tried to be careful with inlining - what's the problem?

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

Just to be clear, group authentication just says each streamed packet came 
from /someone/ who knew the group key. TESLA is for scenarios where you 
need source authentication to say precisely who they came from, which 
should mean you don't need group authentication. But TESLA source 
authentication is delayed a hundred msec or so. So, if there's a threat of 
DoS, you need something (cheap) in the mean time.

Options for these ~100msec:
- a group MAC as well (as in current SRTP draft) = bigger packets
- the S/KEY-like scheme in 3/ below = more sender memory/processing

There are applicability issues with both these options. The TESLA-intro 
authors have decided to write up these issues in a further TESLA-intro 
draft. I'd be interested in opinions in the mean time, but you might want 
to wait until the issues are laid out clearly.

>and the related question:
>
>         The base TESLA intro draft does not mandate it, how come
>         SRTP-TESLA draft is mandating it?

Again, to be clear, the TESLA-intro draft will be INFORMATIONAL, so isn't 
in a position to mandate anything. It should give advice for those writing 
the specific instantiations, of which SRTP-TESLA is one. A specific 
instantiation needs to say, MUST/SHOULD/MAY etc.

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

Pending Elisabetta checking why it said 10.

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

Yes, interoperability isn't the issue. Implementation and usage complexity 
of having options /is/ a concern. Chances of security holes increase, both 
due to complexity bugs and due to inappropriate choice of options for a 
particular scenario.

Another possibility is to define completely separate transforms instead of 
options within a transform, but I don't fully understand the complexity 
implications of each way forward. Can anyone help here?

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

See above, for process clarification.

Bob

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

____________________________________________________________________________
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: "Elisabetta Carrara (KI/EAB)" <[email-masked]>
Date: Thu, 2 Sep 2004 09:18:05 +0200

> Pending Elisabetta checking why it said 10.

The group MAC is default 4 bytes in the SRTP-TESLA draft. 
Please point me out if any text in the draft says differently.

/E

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 02 Sep 2004 16:02:21 +0100

Elisabetta,

>Please point me out if any text in the draft says differently.

You're right. I looked in the table of default values in section 6.1 and 
not finding it, I went to the SRTP RFC where it says 80 bits. I missed the 
sentence in section 6 saying truncate it to 32 bits.

Bob

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.   +44 1473 645196

---

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

Ran,

At 05:14 31/08/2004, canetti wrote:
>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.

1/ It's really not delicate or hard...

Just like when on reception, the earliest slot the sender can be in is 
computed based on packet arrival time, t_j (in TESLA-intro section 3.5):
         floor[(t_j - T_0)/T_int = K_i]

The slot K_s that the sender appears to have been in when it sent the 
packet can be computed based on RTP timestamp, t_s:
         floor[(t_s - T_0)/T_int = K_s]

If there's significant delay in the sender stack after the RTP timestamp is 
applied, that doesn't change the security; it can just all be put down as 
extra network delay (but avoidable by more careful implementation).

2/ Just to emphasise a point that Adrian Perrig reminded me of when we met 
(offline) recently....

This use of the RTP timestamp (just like use of the key index) must not be 
assumed to say anything authentic about the time the packet was sent until 
after the packet is authenticated. It is merely a hint as to which key to 
try in order to see whether the packet is authentic. Then, only if the key 
the timestamps hints at does indeed create a matching MAC to that in the 
packet, can one say that the timestamp (or key index) was indeed authentic. 
This is implicit authentication - because correct authentication depended 
on it.

So, we must still have the timeslot plan for the whole key chain signed in 
advance under an asymmetric key. The timestamps or key indices in the 
packets are NOT authentic until proven so by implicit authentication.

Bob

---

From: "Elisabetta Carrara (KI/EAB)" <[email-masked]>
Date: Tue, 14 Sep 2004 18:44:03 +0200

Hi Bob!
AFAIK, that is the way RTP works, unfortunately 
(I'd be the first happy to save bytes ;o))

Cheers
/E  

> [mailto:[email-masked]]On Behalf Of Bob Briscoe
> Sent: den 14 september 2004 18:37
> To: Elisabetta Carrara (KI/EAB)
> Cc: canetti; Mark Baugher; [email-masked]
> Subject: Fwd: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt
> (long)
> 
> 
> Elisabetta,
> 
> Just made the mistake of sending before reading (I just read 
> your 31 Aug 04 
> posting on msec)...
> 
> You make it clear that the RTP timestamp isn't as reliable as 
> I thought. Is 
> this possible by design, or just due to some crap implementations?
> 
> So, I guess the advice should be to add a key index field unless the 
> implementor is sure of the reliability of the RTP timestamp. If this 
> assurance is going to be rare, it's a good argument for not 
> allowing any 
> option, and always mandating the addition of a key index field...
> 
> ...However, I'm wary of forcing 32 redundant bits per packet 
> just because 
> another code module is often flakey. THat's more an argument 
> for fixing the 
> flakey code, not adding bloat to allow for flakiness 
> elsewhere. It's not 
> unreasonable to expect that adding time-dependent security to an RTP 
> implementation will require tightening up pre-existing 
> timestamping code.
> 
> Of course, there might be a problem if you don't have access 
> to someone 
> else's RTP source that you depend on. But is this really a 
> likely scenario?
> 
> 
> Bob
> 
> 
> >Date: Tue, 14 Sep 2004 17:12:47 +0100
> >To: canetti <[email-masked]>
> >From: Bob Briscoe <[email-masked]>
> >Cc: Mark Baugher <[email-masked]>, [email-masked]
> >Bcc: f\Charging\Security\IN msec
> >
> >Ran,
> >
> >If there's significant delay in the sender stack after the 
> RTP timestamp 
> >is applied, that doesn't change the security; it can just 
> all be put down 
> >as extra network delay (but avoidable by more careful 
> implementation).
> >
> >packet, can one say that the timestamp (or key index) was indeed 
> >authentic. This is implicit authentication - because correct 
> >authentication depended on it.
> >
> +44 1473 645196
> ______________
> +44 1473 645196

---

From: "Elisabetta Carrara (KI/EAB)" <[email-masked]>
Date: Wed, 15 Sep 2004 09:56:30 +0200

Hi
I share Lakshminath's view.

Cheers
/E

> From: Dondeti, Lakshminath [mailto:[email-masked]]
> Sent: den 14 september 2004 21:08
> To: Bob Briscoe
> Cc: Mark Baugher; Elisabetta Carrara (KI/EAB); 
> [email-masked]
> 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
> 
>  >5/ Discard if a packet cannot be authenticated should be optional
> = Agreed
> 
> 
> 
> Bob Briscoe wrote:
> 
> > Mark,
> >
> > At 23:49 12/09/2004, Mark Baugher wrote:
> > >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.
> >
> > 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)
> >
> > = 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
> >
> > >thanks, Mark
> > >On Sep 2, 2004, at 1:03 AM, Bob Briscoe wrote:
> > >
> > >>Mark,
> > >>
> > >>At 18:49 30/08/2004, Mark Baugher wrote:
> > >>>Bob,
> something I'd 
> > like
> > >>>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.
> > >>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...
> > >>>>Having thought about it, I will be stronger than the 
> last mail and
> > >>>>say
> > >>>>circumstances so should not be the default. The logic of using a
> > >>>>group
> > >>>>Group authentication is being MANDATED in the SRTP draft in a
> > >>>>scenario
> > >>>"trusted not to launch a denial of service attack 
> against the group."
> > >>>disclose a group key" - and so on.  Treating something 
> as complicated
> > >>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
> > >>>>sufficiently that group authentication might detect 
> some DoS attacks
> > >>>>-
> > >>>against anyone running a kiddie script who decides to 
> send a burst of
> > >>>packets and overflow members' buffers.  Let's gather 
> some more opinion
> > >>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.
> > >>
> > >>
> > >>
> >>>>>>--------------------------------------------------------
> -----------
> > >>>>>>-- -- ----
> > >>>>I have no problem with making a group MAC optional for scenarios
> > >>>>where
> > >>>>it does improve matters.
> > >>>
> > >>>seemed fairly obvious to me obviously seems wasteful to 
> you.  I'd like
> > >>>>Sorry, history was a distracting word. I meant 
> likelihood. Imagine a
> > >>>>representatives of mutually distrusting governments. 
> They don't trust
> > >>>>each other not to spoof what the other parties are 
> saying, but they
> unlikely - as
> > >>>is
> case, there
> > >>>>>is
> > >>>>No. The disclosure *interval* (delay) still spans 
> multiple packets.
> > >>>>once, rather than the same key being disclosed 
> repeatedly as it was
> > >>>specification and that you have raised the issue with 
> your co-authors?
> > >>>>- 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
> discover the
> > >>>>next
> > >>>>- The receiver will never buffer more than one packet 
> per packet sent
> verification
> > >>>>   - 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
> > >>>>I need to fully document this. There are some corner cases not
> > >>>>covered
> > >>>>protection idea hasn't had the same peer-review as 
> TESLA, except it
> > >>>>is
> > >>>have not read the one you sent me yet.  And I would like 
> to hear what
> specification.
> > >>>>>No?
> > >>>>off-line right now. It's my fault we didn't reach closure on it
> > >>>>before
> > >>>>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
> problem. It
> > >>>>was
> > >>>>only through reveiwing the SRTP draft that the 
> technique came back to
> > >>>>However, it's not out of the woods yet. My co-authors 
> are trying to
> > >>>>If it comes out intact, you should see text on it 
> shortly. Otherwise,
> > >>>>>>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
> > >>>>>>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.
> > >>>>>
> > >>>>packets are extremely re-ordered (e.g. it must be no 
> more than, say,
> > >>>>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
> > >>>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.
> > >>>>
> > >>Yup. Done.
> >>____________________________________________________________
> ___________ 
> > _____
> > >>Bob Briscoe, <[email-masked]>      Networks Research 
> Centre, BT
> > >>Research
> > >>B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 
> 3RE,UK.   +44 1473
> > >>645196
> > >>
> > >Bob Briscoe, <[email-masked]>      Networks Research 
> Centre, BT 
> > Research

---

From: <[email-masked]>
Date: Wed, 15 Sep 2004 09:41:01 -0400

I think in TESLA we are very conservative in terms of whether the packet
is authentic. The packet is not authentic anymore if the sender could
have already revealed the key, as opposed to the packet is not authentic
anymore because the key is revealed and someone could have had time to
forge a packet.

Given the conservative nature of source authentication of TESLA, there
may be some preference in some domains to just have group authentication
and no source authentication, to avoid false negatives. 

In my opinion, we could make group authentication and source authentication
optional, but existence of at least one of them mandatory.

I do not know if that is what Bob was refering to. If yes, I would not mind
supporting the option.

Atul

> Sent: Tuesday, September 14, 2004 2:55 PM
> To: Bob Briscoe
> On Sep 14, 2004, at 9:58 AM, Bob Briscoe wrote:
> >
> ...
> >
> >
> 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
> >
> >> Nits
> need to add  
> but yes, it  
> >>> got
> >>>>> for the narrow range of scenarios where group members aren't  
> >>>>> trusted
> >>>>> sufficiently that group authentication might detect some DoS  
> >>>>> attacks
> >>>>> -
> send a burst  
> >>>> packets and overflow members' buffers.  Let's gather some more  
> >>>> opinion
> OK. It's now  
> >>> I've split the remaining reply into separate threads for each  
> >>> numbered
> >>>>>>> 2/ Non-TESLA group authentication to protect against 
> DoS should  
> >>>>>>> be
> >>>>>>> optional
> >>>>>>> 
> ----------------------------------------------------------------- 
> >>>>>>> -- -- -- ----
> you.  I'd  
> likelihood. Imagine  
> They don't  
> >>>>> trust
> interloper  
> >>>> would
> discussing this  
> received some  
> >>>>> time
> per packet  
> >>>>> sent
> >>>>>   - if they fail delayed verfication, the messages must 
> not have  
> >>>>> been
> >>>>> genuine
> case. But,  
> >>>>> then
> >>>>> essentially just S/KEY, which has had ample peer review (but  
> >>>>> perhaps
> >>>>> not in a group setting).
> >>>>
> document -  
> >>>> I
> to hear  
> >>>> what
> option,  
> >>>>> but I
> the mists  
> >>>>> time I gave up. I've been taking a back seat on the TESLA work  
> >>>>> until
> technique came back  
> >>>>> to
> attempts to  
> >>>>> break
> rely on it  
> >>>>>>> being
> more than,  
> >>>>> say,
> an initial  
> >>>>> test
> do a test  
> >>>>> that
> >>>>> uses none? And this would only work if you trusted the group  
> >>>>> members
> why it needs  
> >>>> to
> proposed  
> >>>> use
> _____________________________________________________________________ 
> >>> __ _____
> ________ 
> >> ______