Subject: Re: [MSEC] draft-ietf-msec-srtp-tesla-00.txt

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Wed, 05 May 2004 17:50:45 -0400

Hi Mark,

I have a followup comment/question, mainly for my own clarification.

Mark Baugher wrote:

> Hello Lakshminath,
>
> At 10:26 AM 4/23/2004, Dondeti, Lakshminath wrote:
>
>> Hi Mark/Elisabetta,
>>
>> I have a couple of questions on the SRTP-TESLA I-D:
>>
>> 1. In Figure 1, and the associated text:
>>
>> Isn't Id optional?  Also, is it a variable length payload, or do you 
>> plan to suggest a key chain length?
>
>
> I did not think that would be wise since section 6.2 of 
> http://www.ietf.org/internet-drafts/draft-ietf-msec-srtp-tesla-00.txt 
> and the length is fixed according to 6.2.
>
>
>> 2.  Figure 2 indicates that the disclosed TESLA key is in the clear.
>
>
> The only key I see in Figure 2 is "Disclosed Key" - and yes this is 
> disclosed to prove the authenticity of the previous message (see 
> section 6.2).
>
My question is whether the key should be disclosed to the members only 
or to any eavesdropper (in the I-D, the key is not encrypted).  As I 
note below, I am not sure it is necessarily a threat, but my 
recollection is that in IPsec (if my memory serves me well) the 
disclosed key is going to be under the protection of the group key.

regards,
Lakshminath

>
>> Is that intended?  I thought about it a little bit: it might not be 
>> directly useful for an attacker as that key is not going to be used 
>> to authenticate any future/current traffic, but why disclose a key 
>> from the key chain if it can be avoided.  Any thoughts on this.
>
>
> That's how I understand this thing to work, Lakshminath, from
> http://www.ece.cmu.edu/~adrian/projects/tesla-cryptobytes/tesla-cryptobytes.pdf 
> <http://www.ece.cmu.edu/%7Eadrian/projects/tesla-cryptobytes/tesla-cryptobytes.pdf> 
> on page 2:
> "
> The main idea of TESLA is that the sender attaches
> to each packet a MAC computed with a key k known
> only to itself. The receiver buffers the received packet
> without being able to authenticate it. A short while
> later, the sender discloses k and the receiver is able to
> authenticate the packet. Consequently, a single MAC
> per packet suffices to provide broadcast authentication,
> provided that the receiver has synchronized its
> clock with the sender ahead of time.
> [pg. 2]."
>
> That "k" is our K_i. 
>
>
>> Nit:  Please replace MAC with ICV or auth tag or something like that.
>
>
> I don't understand since this field is a message authentication code.
>

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

---

From: Mark Baugher <[email-masked]>
Date: Wed, 05 May 2004 16:13:34 -0700

hi Lakshminath,

At 02:50 PM 5/5/2004, Dondeti, Lakshminath wrote:
<...>

>>disclosed to prove the authenticity of the previous message (see section 6.2).
>My question is whether the key should be disclosed to the members only or 
>to any eavesdropper (in the I-D, the key is not encrypted).  As I note 
>below, I am not sure it is necessarily a threat, but my recollection is 
>that in IPsec (if my memory serves me well) the disclosed key is going to 
>be under the protection of the group key.

The disclosed key is in the clear, disclosed to members and interlopers, to 
prove that the _previous_ message is authentic (or messages are 
authentic).  There is no reason that I can see to encrypt that key.

cheers, Mark

>>>directly useful for an attacker as that key is not going to be used to 
>>>authenticate any future/current traffic, but why disclose a key from the 
>>>key chain if it can be avoided.  Any thoughts on this.
>>
>>

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Wed, 05 May 2004 22:38:27 -0400

Thanks Mark.

Lakshminath

Mark Baugher wrote:

>> My question is whether the key should be disclosed to the members 
>> only or to any eavesdropper (in the I-D, the key is not encrypted).  
>> As I note below, I am not sure it is necessarily a threat, but my 
> The disclosed key is in the clear, disclosed to members and 
> interlopers, to prove that the _previous_ message is authentic (or 
> messages are authentic).  There is no reason that I can see to encrypt 
> that key.
>
> cheers, Mark
>
>
>> regards,
>> Lakshminath
>>
>>>

---

From: George Gross <[email-masked]>
Date: Wed, 5 May 2004 21:52:21 -0400 (EDT)

Hi,
	Although I did not read the above ID, this thread about sending
the TESLA authentication key in the clear did set me to thinking, there
seems to me to be one possible attack:

suppose that the adversary controlled a router along the path that the
authentication key is known to traverse, and this router is at a choke
point, which if controlled by the adversary effectively partitions the
group into two sub-groups. If the adversary intercepted and delayed the
authentication key packet, he/she would be able to briefly forge bogus yet
pseudo-authentic messages. After a short period, the adversary releases
the captured authentication key packet. the receiver endpoints accept the
bogus messages as authentic.

is this attack pausible?

 BTW, to me this attack seems very feasible in MANETS ;o)

	George

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Thu, 06 May 2004 01:03:24 -0400

Plausible yes, effective: I would have to say no, in that TESLA would 
drop the bogus packets.  That said, I was thinking along those lines in 
bringing up this topic.

The attack would be ineffective because there is group authentication 
using a 4B ICV that offers (some) protection.  Furthermore, assuming 
TESLA is implemented properly (with secure time synchronization etc.), 
the timing checks should fail i.e., a receiver drops any packets for 
which it estimates that the sender has already revealed the 
authentication key.  Now if the adversary succeeds in dropping time 
synchronization messages and if there is sufficient clock skew, we would 
have a different story.  Apologies if that is somewhat off; it has been 
a while since I looked at TESLA.

What would make an attack successful?  If the time synchronization is 
suspect (improper implementation/deployment), and if the adversary can 
break the 4B ICV, the adversary can trick some receivers into accepting 
bogus packets as valid.  I am not entirely sure whether encrypting the 
key helps, but thought it is worth thinking about.  Would it be bad in 
anyway to encrypt the key (any big performance hit?)?

I guess in the end, it depends on the threat model.  If TESLA is being 
employed, the assumption is that group members are trusted to not launch 
DoS attacks on each other, but might cheat in all other ways, including 
forgery.

Finally, thanks for your message.  Glad to know that I am not the only 
one being paranoid about this :-).

regards,
Lakshminath

---

From: Mark Baugher <[email-masked]>
Date: Thu, 06 May 2004 09:26:36 -0700

hi George
   I think you are discovering problems that are handled by the TESLA 
protocol.  You need to take a look at the original spec by Adrian and Ran 
before going further in this thread.

thanks, Mark

---

From: canetti <[email-masked]>
Date: Sat, 8 May 2004 17:44:37 -0400 (EDT)

Mark, Elizabetta,

Finally got around to reviewing the srtp-tesla draft. Overall it reads very
good. A couple remarks though:

(a) one issue that I think needs better treatment is the
way a receiver determines whether a packet is "safe", or alternatively
arrived "too late" and should thus be dropped. Currently this point is not
specified clearly enough.

I see two ways to go about this. Let me propose both; I'm interested to
hear your opinions (as well as everyone else's). The decision will also
affect the other TESLA drafts that are still underway.

In both ways, the receiver should have in its "cryptographic context" table
for  the session a "corrected session start time", denoted t_0.
t_0 is computed as session initialization time (within the receiver), and is
given to the SRTP session as an external parameter.

/* t_0 should be computed by the session setup protocol as t_0=T_0+D, where
T_0 is the session initiation real time at the *sender*, and D is a lower
bound on the clock skew that was computed by NTP or other means.
Intuitively, t_0 is a lower bound on the local clock-read at the receiver,
at the time where the sender initiates the session. */

Also, in both ways, it should be stressed that the receiver's decision
whether the packet should be dropped is done as the first step in the
processing. In both ways, the first thing to do is to record the local time
when the packet is received. Call this time t_r.

Also, in both ways the next step of the receiver is to compute the "deadline
time", t_d, ie a lower bound on the time at which the sender discloses the
key for verification of the MAC in the packet. If the packet arrived after
the
deadline (ie, if t_r > t_d) then the packet should be dropped.
Otherwise, the processing of the packet should proceed as described.

The difference between the two ways is in how the receiver determines t_d:

method I: Here the packet should contain d, the interval number in the
session (ie, d is interpreted as saying "this packet is sent in the d-th
interval since the beginning of the session".)
In addition, the receiver's cryptographic context should contain the
following parameters:
*Tint, the duration of each interval
*Ndel, the number of intervals after which the keys are released. (That is,
the keys used to authenticate the packets at interval d are beingreleased at
interval d+Ndel.)
Now, the receiver computes t_d = t_0 + Tint * (d + Ndel).

method II: Here the packet should contain a time t_p, which is interpreted
as the local time at the sender, since the start of the session,
when the sender is planning to release the key for this packet. (For
instance, if the key is to be released at interval d', and the duration of an
interval is Tint, then the packet should contain the time t_p = d' * Tint.)
The receiver now computes t_d=t_0+t_p.
(Note that the time t_p does not necessarily say anything on when the packet
was sent, only on when its key is being released.)

Method II has several advantages over method I: first, it moves some of the
processing from the receiver to the sender, which is nice since it is done
only once, and also senders are usually higher end machines. more
importantly, it allows the sender to change the duration of
intervals and the delay in release of keys in a dynamic way throuhout the
session based on the bandwidth consumed and the network behavior. Also,
the receivers need not store Tint and Ndel at all.
The down side of method II is that t_p would probably take more bytes to
represent than the interval number d. This overhead could
be controlled by playing with the units in which t_p is represented
(milliseconds? deciseconds?); but it may still be an issue for some
applications.

(b) Another point: in the receiver processing, the receiver should
also check that the key it receives for verifying a packet fits in
the key-chain: at all times the receiver should keep the "latest
key in the key-chain" that it has ever received. Call this value K_i*.
Then when receiving a key K_i, the receiver should verify that
F^{i-i*}(K_i)=K_i*. Then, the receiver should derive from K_i the MAC key
K'_i and verify the MAC.

Ran

---

From: Mark Baugher <[email-masked]>
Date: Mon, 17 May 2004 16:02:47 -0700

hi Ran
   Pardon my delay in answering this note.  More below.

>specified clearly enough.

This is the issue that Lakshminath and George were raising.  We don't
mention this in SRTP-TESLS because it would be redundant to what's
described in the TESLA specification.  That is, this issue is independent
of whether TESLA is used in SRTP, IPsec or other protocol and needs to
be addressed once.  I expect that the TESLA specification is the one
place where this should be addressed rather in the specs that define
instances of TESLA in specific protocols.

That being said, we do define a set of TESLA parameters and variables
for the cryptographic context.  And I understand your point that we
need to make sure that we include this function as well.

>affect the other TESLA drafts that are still underway.

I went looking for the TESLA specification to align what's presented there
with what we have in SRTP-TESLA but the TESLA spec seems to have expired.
I'm using
http://vesuvio.ipv6.cselt.it/internet-drafts/draft-ietf-msec-tesla-spec-00.txt

>at the time where the sender initiates the session. */

Why not use the same variable names as in the TESLA spec?  I'm referring to
the I-D listed above.

>session (ie, d is interpreted as saying "this packet is sent in the d-th

I believe that this is the "id" header field in
http://www.ietf.org/internet-drafts/draft-ietf-msec-srtp-tesla-00.txt
- figure 2.  But it is not clear.

>*Tint, the duration of each interval

T_int is on page 6 of

>the keys used to authenticate the packets at interval d are beingreleased at

I'm confused now.  We have a crypto context parameter "d" which I think
is what you are calling "Ndel."

>was sent, only on when its key is being released.)

I believe this is what we assume in SRTP-TESLA and we have the variables
to perform this computation.  What we don't give is the algorithm for
doing it, preferring to leave this to the main TESLA spec.

>(milliseconds? deciseconds?); but it may still be an issue for some

I need to consult with my co-author on this topic and would appreciate
hearing from the folks who have read both specifications.  My current
understanding is that we have the variables defined in the crypto
context to do method II, but I'm not absolutely certain since our
definitions in
http://www.ietf.org/internet-drafts/draft-ietf-msec-srtp-tesla-00.txt
are too abbreviated.

>F^{i-i*}(K_i)=K_i*. Then, the receiver should derive from K_i the MAC key

Ok.

Mark

---

From: canetti <[email-masked]>
Date: Thu, 27 May 2004 17:39:31 -0400 (EDT)

Mark,

Sorry for the delay.

See remarks inline. Note also that there is a ne tesla-intro draft at the
depository, which explains better the handling of the timing constraints.
It's at

http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-intro-02.txt

Ran

> need to make sure that we include this function as well.

it's indeed a good idea to leave the precise description to the the tesla
draft. But there should be a clear pointer to the tesla draft. (in fact,
it may not be a bad ideal to include a self-contained sketch; after all
it's a pretty simple operation.)

> http://vesuvio.ipv6.cselt.it/internet-drafts/draft-ietf-msec-tesla-spec-00.txt

the updated version of the tesla-into draft should be enough for this.

> Why not use the same variable names as in the TESLA spec?  I'm referring to

the tesla spec is being rewritten and will comply with the notation of
the tesla-intro.

> - figure 2.  But it is not clear.

yes.

> http://www.ietf.org/internet-drafts/draft-ietf-msec-srtp-tesla-00.txt

yes.

> is what you are calling "Ndel."

yes.
> http://www.ietf.org/internet-drafts/draft-ietf-msec-srtp-tesla-00.txt

method II needs a subset of the information required for method I. so
thisshould not be a problem. The issue is just the convention - what the
receiver expects to see in the variable id in the packet.

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