Subject: [AVT] SRTP Concerns

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

Hi,

I have a concern with draft-ietf-avt-srtp-01.txt with regards to the use of
source SRTP/SRTCP transport address in establishing cryptographic context. 

This draft itself says that SRTP is to maintain the transport independent
nature of RTP. Surely this is a violation of that principle? Source address
in RTP is not enforceable/determinable and would differ when traversing a
NAT. At any rate there is no text addressing these issues or discussing the
interaction with the way that SDP & NAT's function.

Is this a wise thing to do in the first place?

Robert.

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

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 10 Aug 2001 12:02:04 -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. 

For instance, if an SPI is (or is not) expected then there is no way to tell
whether it is present in the packet [without know the cryptographic context
to start with]. I think a simple (bandwidth) method can be easily be devised
since the length of the SPI field is known to be 32bits. 

For instance, one method could be to add a single byte to the start of the
authentication tag (if present) which begins with a known bit pattern, eg
1111. Now simply mandate that the SPI may not begin with this bit pattern
(which doesn't have any impact on the level of security provided by SRTP as
far as I can tell). If less than 8 bits are used the authentication tag
could even make use of these bit to signal something useful.

Another option is to make the SPI a required field - this means that people
won't get lazy and try to use the SSRC and transport addresses to determine
the cryptographic context when they shouldn't. There are other reasons why
this might be a good idea to not rely on the SSRC even in a two part
conference that I will enumerate in a subsequent email.

Robert.

> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> Sent: Friday, August 10, 2001 6:24 PM
> To: [email-masked]'
> Cc: [email-masked]'; [email-masked]'
> Subject: [AVT] SRTP Concerns
> 
> 
> Hi,
>

---

From: Mark Baugher <[email-masked]>
Date: Fri, 10 Aug 2001 12:12:44 -0700

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

cheers, Mark

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Sat, 11 Aug 2001 08:39:31 -0700

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

I propose the following two amendments are made :

A) 

First three bits are used to determine tag type for SRTP (yes no metadata or
lengths proposed for general tags).

So 1 byte SPI tag could be 001 + 5bit SPI value
So 2 byte SPI tag could be 010 + 13bit SPI value
So 3 byte SPI tag could be 011 + 21bit SPI value
So 4 byte SPI tag could be 100 + 29bit SPI value
[Note: SPI values would all be treated as 32 bit number on reception.]

Authentication tag starts with 101 + remainder of authentication tag

We could save a lot of bandwidth this way when SPI is used with little added
complexity. [Larger SPI values should only be rarely needed, randomness is
not a requirement for SPI.]

B)

SPI can only be _not_ present if both sender and receiver indicate their
willingness for this to occur in the signalling plane. That is, one side
cannot force the other side NOT to use SPI. The other side might require the
SPI for identification due to NATs or port-sharing or whatever. I don't
think this is a difficult or infeasible requirement. SRTP must IMO retain
its transport independent nature unless both sides agree otherwise (and this
would calm some of my concerns).

Cheers,

Robert.

---

From: Mark Baugher <[email-masked]>
Date: Sat, 11 Aug 2001 10:47:39 -0700

Robert,
   What security problem are we trying to solve?

Mark