Subject: [AVT] SRTP and SPI model - rethink requested

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

Hi again,

After a long and protracted email discussion with Mark Baugher (it took him
a while to get through to me), Mark showed me that the changes I proposed
don't work for multicast transport.

When multicast cast transport is used, it is the sender that must generate
the SPI value (and the value will obviously will be the same for all
receivers). Therefore the SPI for multicast can never be assigned a unique
value w.r.t a single receiver and thus you do in fact want to use as many
bits as possible. For multicast, the SPI is effectively forming a 64-bit
SSRC except that it allows the cryptographic context to be changed
independently of the SSRC (but you are still effectively just forming a
64bit unique sender identification number).

This fact suddenly made me wake up and realize that the multicast and
unicast RTP models _ARE_ entirely different and should be treated as such! 

- For multicast, it is the _sender_ that must determine what is to be sent
and where it is to be sent and how it is to be identified (eg SPI). All
receivers must use that same information - a receiver has no say in the
matter.
- For unicast (in the SDP model), it is the _receiver_ that specifies what
is to be sent, where it is to be sent (ie, how it so to be identified). 
- This difference is _entirely_ independent of the conference model - it is
merely a function of the transport protocol. Additionally, it is entirely
determinable by the transport address used (multicast verse unicast).

SIP & SDP recognize this fact :
   "For a multicast session, the callee SHOULD only return a session
   description if it is unable to receive the media indicated in the
   caller's description or wants to receive data via unicast."

   Also, the interpretation of send-only and receive-only for multicast
media
   sessions is effectively reversed to that of unicast.

I believe that the SRTP key management protocol should also make a simple
distinction!

In unicast the advantages for the receiver allocating the SPI value are
_immense_:
	- the receiver can allocate SPI values such that the SPI values can
be used to associate media flows with their session and cryptographic
contexts.
	- the receiver is free to implement whatever media context lookup
scheme it likes
	- the SPI value can be allocated such that senders in different
sessions independent of source or destination transport addresses and SSRC
collision. This effectively solves port sharing problem.
	- the receiver can allocate very small values of SPI (much less
bandwidth)
	- It's simple.
	- No changes to STRP.

All that we are required to do is make recommendations to the key management
protocol that in the multicast case the sender decides the SPI (because it
has to) but otherwise the receiver decides on the SPI to use. This works for
all conference models, multicast, multi-unicast or simple unicast. 

Cheers,

Robert.

> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> Sent: Sunday, August 26, 2001 1:02 PM
> To: [email-masked]'; [email-masked]'
> Cc: 'Mark Baugher'; [email-masked]'
> Subject: [AVT] More on SRTP and SPI.
> 
> 
> 
> 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
> 

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