Subject: [AVT] RE: I-D ACTION:draft-ietf-avt-srtp-03.txt - More Feedback

From: Euchner Martin ICN M SR 3 <[email-masked]>
Date: Mon, 6 May 2002 12:35:18 +0200

Hi SRTP folks,

I have some more comments and questions on SRTPv3:

1.)	Figure 3 shows in the middle part "Encrypted Portion of RTP packet".
I guess, this should be the unencrypted portion of the RTP packet?

2.)	Optional master salt: Section 3.1.1 says that " In addition, for
each master key, SRTP MAY choose to specify the following associated
values:" However, the key derivation procedures in section 4.3.1 make the
master salt integral part of the PRF procedures. Thus, I would say that the
four lines on the master salt in 3.1.1 should be moved upwards and become
mandatory.

3.)	Section 3.3: The sentence " * If the MKI indicator in the
cryptographic context is zero, the master keys is determined by the current
SRTP index, even though SRTCP has its own index." seems to have some
language problems. Is it referring to just one master key or are there
actually several (2?) master keys involved? (which one then: the SRTP master
key or the SRTCP master key)?

4.)	Section 4.3.1: " and a default PRF transform is defined in Section
4.3.2." This reference should in fact point to section 4.3.3.

5.)	Sections 12.1.1 and 12.1.2: This a question on clarification and
understanding how the situation would be in case of

a)	Unidirectional RTP stream: I guess this involves 6 distinct session
keys (encryption and authentication session key for the RTP payload,
encryption and authentication session key for the RTCP sender to receiver
direction, and another session key pair for the reverse RTCP direction). But
I am not quite certain whether there are actually 2 separate unidirectional
RTCP contexts or there might be a bi-directional RTCP context, thereby
reducing the number of session keys?
b)	Bi-directional RTP stream: Since there is some redundancy on the
RTCP forward and reverse channels, there are in total four session key pairs
(encryption + authentication).

		This my view correct?

With kind regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 47713
| ICN M SR 3                     mailto:[email-masked]
|                                mailto:[email-masked]
| Hofmannstr. 51                 Intranet:
http://intranet.icn.siemens.de/marketing/cs27/topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------

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

---

From: Mark Baugher <[email-masked]>
Date: Mon, 06 May 2002 09:23:44 -0700

Hi Martin,
   We are just finishing the next version of SRTP for posting,
so your comments are timely.

>I guess, this should be the unencrypted portion of the RTP packet?

It's the portion to be encrypted.  Perhaps we should refer to Figure 1
here.

>four lines on the master salt in 3.1.1 should be moved upwards and become

Yes, I think there is an inconsistency here that we need to clarify.

>key or the SRTCP master key)?

We need to clarify the fact that the master key need not
be shared between SRTP and SRTCP.

>4.3.2." This reference should in fact point to section 4.3.3.

We fixed this in the current draft.

>reducing the number of session keys?

My reading is that "two-party unicast" implies that both sides
are sending.  In 12.1.1, they share a single master key and
there are a total of four keys, which are enumerated in 12.1.1.

>(encryption + authentication).

The issue addressed in section 12.1 is whether the two hosts
share master keys or not.  If they share master keys then
there are authentication and encryption keys for RTP and
RTCP, for a total of four keys.  If they do not share master
keys, then each host has four unique keys for a total of eight.

We will clarify key sharing in the draft that we post this week.

thanks, Mark

---

From: Mark Baugher <[email-masked]>
Date: Mon, 06 May 2002 12:20:32 -0700

Martin,
   Elisabetta and Mats pointed out to me that there is a
"NULL salt" defined in 3.1.1.  So,...

At 12:35 PM 5/6/2002 +0200, Euchner Martin  ICN M SR 3 wrote:
>hi srtp folks,
>
>i have some more comments and questions on srtpv3:
>
>1.)     figure 3 shows in the middle part "encrypted portion of rtp packet".
>i guess, this should be the unencrypted portion of the rtp packet?
>
>2.)     optional master salt: section 3.1.1 says that " in addition, for
>each master key, srtp may choose to specify the following associated
>values:" however, the key derivation procedures in section 4.3.1 make the
>master salt integral part of the prf procedures. thus, i would say that the

I think we can leave this as it is.  Do you agree?

Mark

>3.)     section 3.3: the sentence " * if the mki indicator in the
>srtp index, even though srtcp has its own index." seems to have some
>language problems. is it referring to just one master key or are there
>actually several (2?) master keys involved? (which one then: the srtp master
>key or the srtcp master key)?
>
>4.)     section 4.3.1: " and a default prf transform is defined in section
>4.3.2." this reference should in fact point to section 4.3.3.
>
>5.)     sections 12.1.1 and 12.1.2: this a question on clarification and
>a)      unidirectional rtp stream: i guess this involves 6 distinct session
>keys (encryption and authentication session key for the rtp payload,
>encryption and authentication session key for the rtcp sender to receiver
>direction, and another session key pair for the reverse rtcp direction). but
>i am not quite certain whether there are actually 2 separate unidirectional
>rtcp contexts or there might be a bi-directional rtcp context, thereby
>b)      bi-directional rtp stream: since there is some redundancy on the
>rtcp forward and reverse channels, there are in total four session key pairs
>                 this my view correct?
>with kind regards
>martin euchner.
>| dipl.-inf.                     rapporteur q.g/sg16
>| martin euchner                 phone: +49 89 722 55790
>| siemens ag.....................fax  : +49 89 722 47713
>| icn m sr 3                     mailto:[email-masked]
>| hofmannstr. 51                 intranet:
>| d-81359 muenchen               internet: http://www.siemens.de/
>| __________________
>| germany
>audio/video transport working group
>[email-masked]