Subject: [AVT] More on SRTP and SPI.

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Sun, 26 Aug 2001 13:01:56 -0700

Hi,

These are my condensed and considered comments on the SRTP draft:

- I believe that the draft should explicitly say destination transport
address rather than merely transport address to remove any ambiguity with
the source transport address.

- The SPI text description (Section 3.2) should explicitly describe the
minimum set of information required to identify the cryptographic context.

I believe this to be:

If SPI is used, 
	context = SPI + <dest transport address/port/protocol> ;
	(note: no dependence on SSRC which simply complicates matters)
otherwise if SPI is not used, 
	context = SSRC + <dest transport address/port/protocol>

[In Section 3.3 (SRTP Packet Processing) the first step is 
	"1. Determine which cryptographic context to use as described in
Section 3.2." 
Yet I feel that section 3.2 does not give a concrete description of this
process, hence the above additions suggested.]

- The protocol must allow the determination of whether the SPI is present in
a packet. This is not only good design (IMO) [eg, it decouples packet
parsing from context determination and allows packet sanity checking] but is
also required for correct operation in some corner cases.

Eg. When SPI is not being used and a sudden re-keying is administratively
required, then SRTP should be able to accomplish this _without_ requiring
SSRC or <dest transport address/port/protocol> changes in the media flow
[which once again would simply complicates matters and not be good design
separation for a security framework]. 

So now a media stream must be able to transition from not using SPI to using
SPI without changing SSRC or dest transport address/port/protocol>. This
requires that the receiver can determine whether or not the SPI is present
in a packet independently of the preceding information.

[I suggested a method for achieving this (as well as improving the bandwidth
efficiency of SPI) in a previous AVT email.]

- For many reasons, the SRTP protocol should place some recommendations on
the key management protocol. I believe the two following recommendations are
highly desirable (and not at odds with the current key management systems)
but should perhaps be stated explicitly in the SRTP protocol.
	
The key management protocol should allow the receiving application to
determine if SPI is required (ie, the sender or some central conference
bridge cannot force the receiver to _not_ use SPI) and the receiving
application is the entity that generates the SPI values to be used.

For starters this allows the receiver to allocate SPI values in an
implementation specific manner which allows the receiver to employ any
context lookup mechanism it desires - important.

[Currently when discussing the use of SPI (Sec 3.2), the draft says:

"The SPI-approach is the only robust method, and SHOULD be used if frequent
re-keying is desired.

We leave it to the key management to implement such features."

I feel that adding the above recommendation to help describe exactly which
features the key management needs to implement would be beneficial to the
document.]

Regards,

Robert.

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

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 28 Aug 2001 12:43:49 -0700

Hi Colin,

Yes it would be simpler but I believe the ability not to use SPI is purely
and simply to cut down on SRTP bandwidth (which is a "good thing" in my
mind). 

In the unicast case, where the receiver allocates each SRTP stream to a
separate port and the receiver does not expect to rekey the stream then SPI
is not really required.

What I believe _is_ necessary is that an SPI stream can transition from not
used SPI to using SPI (without changing SSRC or transport address). This
provides a robust approach to changing contexts when SPI is not initially
used. This requires that you can determine the 
presence/absence of SPI in a packet.

That's my take on it anyway. :) I'll let the authors defend themselves.

Regards,

Robert.

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Tuesday, August 28, 2001 11:12 AM
> To: Fairlie-Cuninghame, Robert
> Cc: Euchner Martin; [email-masked]'; [email-masked]';
> 'Mark Baugher'; [email-masked]'
> Subject: Re: AW: [AVT] More on SRTP and SPI. 
> 
> 
> Okay, so can we make the SPI mandatory? That might make 
> things easier to
> manage...
> 
> Colin
> 
> 
> 
> --> "Fairlie-Cuninghame, Robert" writes:
> >Hi Colin,
> >
> >> --> Euchner Martin writes:
> >> >Yes, there should be some easy parseable signaling means for the
> >> >recipient(s) to determine whether SPI is present or not. I 
> >> would pretty
> >> >much prefer this some bit in the RTP header, e.g.  M Bit or 
> >> X bit and some
> >> >SPI extension flag or perhaps with V = 3
> >> >
> >> 
> >> Why not signal it in the call setup? There's no need to put this
> >> information into the packets.
> >
> >Well for starters, it makes things significantly more 
> complicated: you must
> >first match the media stream to the session entity, which is 
> not a trivial
> >task (or always possible immediately) before you can decode 
> or authenticate
> >the packet. [not a good design IMO]
> >
> >I complete agree that the length of all the other fields 
> should be obtained
> >from the session information but since the SPI value can be useful
> >identifying that session information I think it should be 
> independently
> >parseable/determinable.
> >
> >Secondly, in the example I gave where a media stream 
> transitions from not
> >using SPI to using SPI (because it needs a new context) then 
> this would not
> >be possible to achieve this robustly & seamlessly [the same 
> media sender can
> >have multiple contexts]. You should not be _forced_ to 
> change the SSRC or
> >media address just because you need a new cryptographic 
> context (IMO).
> >
> >To reproduce my suggestion:
> >
> >We could use first three bits of each optional field 
> determine tag type:
> >
> >So 1 byte SPI could be 001 + 5bit SPI value 
> >So 2 byte SPI could be 010 + 13bit SPI value
> >So 3 byte SPI could be 011 + 21bit SPI value
> >So 4 byte SPI could be 100 + 29bit SPI value
> >Authentication tag starts with 101 + 5 spare signaling bits 
> + remainder of
> >authentication tag
> >
> >This also saves bandwidth when using SPI which is a benefit 
> (and as it says
> >in the draft, SPI is the only robust method). SPI values are 
> not like SSRC
> >values that need a degree of randomness to prevent 
> collision, etc. The
> >smaller SPI values can be _normally_ used.
> >
> >Robert.
>

---

From: Mark Baugher <[email-masked]>
Date: Tue, 28 Aug 2001 16:15:49 -0700

Robert,

>presence/absence of SPI in a packet.

Complicated behavior like this should be avoided in a security protocol.
I don't believe what you describe is needed at all.

Mark

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 28 Aug 2001 16:38:11 -0700

Hi Mark,

> I don't believe what you describe is needed at all.

On the flip side I would say that security protocols need to always be
robust. Providing a way for a security protocol (or any protocol) to be used
in a non-robust way is asking for trouble and in its very self is a
complication of the protocol (even if it allows a simple lazy implementation
to work with some subset of the functionality).

My suggestion (non-SPI to SPI transition) allows the advantages of not using
SPI but allows the protocol to handle context switches to be handled in a
robust manner.

I don't think it is that complicated. You are simply looking for the context
of a received packet and matching it to a negotiated crypto context. The
lack of an SPI can be treated just like receiving an SRTP with a special,
unused SPI value. Simple. Implementation of a key management protocol is
still a requirement and support for the _negotiation of SPI is still
required (regardless of whether it is normally used).

I don't see the severe complication in my suggestions; in fact to me they
seem more elegant as it allows the non-SPI case to become robust. [but of
course everyone always thinks their own solutions are elegant don't they.
<grin> ] I fear this is becoming a philosophical argument so I'll stop now.

Cheers,

Robert.