[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Evaluation: draft-ietf-avt-srtp - The Secure Real-time Transport Protocol to Proposed Standard

Steve:

From section 4.1, I learn that:

* k_e is the session encryption key
* k_s is the session salting key

Thus, I do not think that k_s is ever used as an AES key. Rather, it is only used in the creation of the IV value, and k_e is the AES key. I do not think there is any security issue with the IV being known. The k_s is being added to make it difficult to mount a precomputation attack.

If this is your only concern, then I think you should withdraw your DISCUSS.

Russ


At 10:08 PM 6/11/2003 -0400, Steven M. Bellovin wrote:
In message <200306061403.KAA24117@ietf.org>, IESG Secretary writes:
>
>Last Call to expire on: 2003-5-22
>
>       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)