Subject: [AVT] IESG review of draft-ietf-avt-srtp.08 - first comments

From: Allison Mankin <[email-masked]>
Date: Wed, 11 Jun 2003 20:42:09 -0700

Mark and other SRTP authors,

The IESG is considering SRTP at the telechat tomorrow.  The review will
continue over till the Jun 26th meeting, so some comments will not come in
yet, but here is a Discuss comment from Steve Bellovin that it would be good
to respond to (don't revise the draft yet, though).

Allison

------- Forwarded Message

>
>	Please return the full line with your position.
>
>                    Yes    No-Objection  Discuss *  Abstain  
>
>
>Steve Bellovin      [   ]     [   ]       [ x ]      [   ] 

SSRC should be expanded in the text the first time it's used.

The IV definition in 4.1.1 has me a bit nervous.  Right now, it's
(k_s << 16) ^ (ssrc << 64) ^ (i << 16), where k_s is the session key, 
ssrc is the 32-bit synchronization source, and i is the 48-bit packet 
index.  The low-order 16 bits are for the block number within the 
packet, which is fine.

The problem I have is that given the mandated 0-padding, the high-order 
32 bits of the IV are from k_s, unmodified by anything else.  Furthermore
ssrc and i are known to the attacker, and the block count is obvious.  
This means that the IV is a trivial function of most of the session key.
I don't *think* that that's a problem, but any extra use of keys makes me 
nervous.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)

------- End of Forwarded Message

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Mats Näslund <[email-masked]>
Date: Fri, 13 Jun 2003 14:18:41 +0200

Dear all,

Since I haven't seen any other reply, I will give a quick
response to Steve's concern (forwarded by Allison below).
See inline.

 > SSRC should be expanded in the text the first time it's used.

OK.

 > (k_s << 16) ^ (ssrc << 64) ^ (i << 16), where k_s is the session key,

Note: k_s is the "session salt", not the "session key".
I am not sure if this is a typo or a missinterpretation of the spec.
In the latter case (you've misstaken the salt for the key), I can
certainly see your concerns...

Let me clarify why it is (we are convinced) not only OK, but rather
REQUIRED to use the *salt*, k_s, in this way.

 > 32 bits of the IV are from k_s, unmodified by anything else.

Here, I think you have "reversed" the security issue that
motivates the presence of k_s in the IV: without the
k_s salt, the high order bits of the IV would be 00....0. Hence,
the k_s is there for the sole purpose of randomizng these zeros,
there is no need for the k_s to be randomized by something else
(more below).

 > ssrc and i are known to the attacker, and the block count is obvious.

Absolutely! *Without* the k_s salt, the IV would be highly predictable,
opening up for pre-computation attacks etc. By XORing k_s onto the
IV, we randomize the IV and fight off such attacks.

 > I don't *think* that that's a problem, but any extra use of keys 
makes me

Recall how keys and salts are generated in SRTP (Sect 4.3 of the ID):

Starting from a master key and a master salt, we derive (among other
things):

* the session key, k_e (which is the AES counter mode key)
* the session salt, k_s (as above)

k_e and k_s are derived by applying a pseudo random function to
said master key and master salt. Hence, k_s and k_e are
"cryptographically isolated" (sorry for imprecise language,
but I think you understand what I mean), both from each other,
and from the master key. The session key, k_e, is kept secret
and is not part of any IV (but k_s is part of it as you noted).

Note: neither the master salt, nor the session salt (k_s) needs to be
secret, though as typically implemented, k_s will be secret. The
only property needed from the "salts" is that they are unpredictable.

Hope this sorts out things.

Best,

/mats