Subject: RE: [AVT] SRTP Concerns

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 10 Aug 2001 16:05:27 -0700

> >Another concern of mine is that the presence of the SPI tag is not
> >determinable from the packet - it must be signalled out of band.
> 
> Why is this a problem?  You will certainly need to do key management
> and the SPI tag is metadata related to the key.  I don't see 
> the problem.

Indeed however I do not think that it is a good design to require that the
context must be known before you can know what constitutes the context in
the first place. <grin>

When you receive an RTP packet you would like to know whether there is an
SPI present so that you can do the correct lookup the cryptographic context
- which in turn gives you mapping between the media source and the session.
It is the session entity has the information on the negotiated presence and
length of the SRTP fields. I'm not saying you can't heuristically hack
something together but this is not a good design IMO - you added the SPI so
that you didn't have to mess around with other fields in the first place!

[I am aware that cryptographic context has different meaning to different
people but effectively in this respect it is providing a reference to a
session (or rather some session configuration dataset).]

Robert.

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

---

From: "David A. McGrew" <[email-masked]>
Date: Sat, 11 Aug 2001 08:42:48 -0400

Robert,

thanks for your input, more below:

> session (or rather some session configuration dataset).]

it looks like you've found a chicken-and-egg problem with the language in the
current draft.  This can be fixed by defining the SPI so that it only selects
among a set of keys within a given context.  Certainly the following rules for
the receiver's packet processing are logically consistent:

1. Find the context using the SSRC and destination transport address.
2. If the context requires the SPI, check the SPI to find out what key should be
used.
3. Process the packet using that key and the other info in the context.

The SPI was introduced because it allows frequent rekeying without changing the
RTP session and thus the SSRC.  Limiting the SPI to selecting only among keys in
a context, instead of selecting among contexts, retains this functionality.

Your proposal to use a single bit immediately before the auth tag to signal the
presence or absence of a SPI is also interesting.  However, there could be a
problem with this approach if the SPI were allowed to signal more metadata than
just the keys.  For example, the presence/absence and/or length of the
authentication tag would not be known before the context was looked up.  It
could be the case that neither the auth tag nor the SPI were present in a
particular packet.

thanks,

David