Subject: AW: [AVT] More on SRTP and SPI.

From: Euchner Martin <[email-masked]>
Date: Mon, 27 Aug 2001 09:25:50 +0200

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

(I admit none of them is excitingly beautiful but at east something like this should be available for backwards compatibility with RTP Version 1).

BTW, does V = 2 actually mean that encryption and/or authentication are applied to an SRTP packet? Or is there any SRTP with V =2 without any security enabled (which would be identical to RTP V =1) ?

Kind Regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Phone: +49 89 722 55790
| Martin Euchner                 Fax  : +49 89 722 46841
| Siemens AG
| ICN M SR 3                     mailto:[email-masked] <mailto:[email-masked]> 
| Hofmannstr. 51                 Intranet: http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm <http://intranet.icn.siemens.de/marketing/cs27/> 
| D-81359 Muenchen               Internet: http://www.siemens.de <http://www.siemens.de> 
| __________________
| Germany     
-----------------------------------------------------------------------

	-----Ursprüngliche Nachricht-----
	Von:	Fairlie-Cuninghame, Robert [SMTP:[email-masked]]
	Gesendet am:	Sonntag, 26. August 2001 22:02
	An:	[email-masked]'; [email-masked]'
	Cc:	'Mark Baugher'; [email-masked]'
	Betreff:	[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

---

From: Mats Näslund <[email-masked]>
Date: Mon, 27 Aug 2001 12:42:05 +0200

Euchner Martin wrote:

> 
> BTW, does V = 2 actually mean that encryption and/or authentication 
> are applied to an SRTP packet? Or is there any SRTP with V =2 without 
> any security enabled (which would be identical to RTP V =1) ?

Both encryption and authentication of RTP is optional in SRTP,
but RTCP requires at least authentication to be present.

Best,

/Mats

---

From: Colin Perkins <[email-masked]>
Date: Mon, 27 Aug 2001 10:11:28 -0400

--> 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
>
>(I admit none of them is excitingly beautiful but at east something like
>this should be available for backwards compatibility with RTP Version 1).

Why not signal it in the call setup? There's no need to put this
information into the packets.

>BTW, does V = 2 actually mean that encryption and/or authentication are
>applied to an SRTP packet?  Or is there any SRTP with V =2 without any
>security enabled (which would be identical to RTP V =1) ?

RTPv1 was an experiment which is no longer used. Standard RTP is version 2.

Colin