Subject: [MMUSIC] Commetns on draft-ietf-mmusic-sdescriptions-02.txt

From: Magnus Westerlund <[email-masked]>
Date: Fri, 12 Dec 2003 13:43:23 +0100

Hi,

I have know read the draft and has thought about most of the open issues 
that the draft presents and the discussion during the IETF meeting. 
There are a couple of points below that, especially 5, that I believe 
requires further discussion and study.

1. As a general thing I think authors should think about how the pages 
get clipped by the pages. For improved readability one should move any 
new sections, etc. that only gets a few line to the next page. One such 
example is to start the table of contents on the first page, instead of 
on the second. Another if the section 4 heading that are sole on the 
last line of a page.

2. The table contents may be a bit to detailed, I would think that it 
would be acceptable to remove all third level items.

3. The introduction contains a normative MUST. I don't think this is 
really appropriate. Please find another place to locate this normative 
text after the introduction.

4. In the last paragraph of section 2, I think this section would 
benefit of being split into two paragraphs.

5. I think that one must look over the multicast cases and divide them 
into different use cases. I think that removing all the multicast is a 
bad choice as there are situation where it seems to work. I would start 
by dividing the usage into scenarios where one can use the a=crypto 
successfully.

- The one to many, using ASM case. This is a advertisement case. Only 
the intended sender declares his SSRC/ROC/SEQ to ensure that all 
receivers does not use the senders SSRC and causes a two time pad with 
it. As all receivers are unsynchronized unless other mechanism is used, 
there might happen SSRC collisions. However if you either don't encrypt 
the RTCP, which is the only thing they will send, it is not a problem. 
Also if RTCP encryption is used, it might be deemed acceptable with the 
low risk of two time pads that exist. However this is clearly a security 
trade off.

- The one to many, using SSM, as the receivers can't send to anybody 
else there is no problem. If one uses unicast RTCP feedback, the same 
security consideration regarding RTCP two time pads apply, however the 
distribution of the offending packets will not be the same as for ASM 
use cases.

- The multicast conference case, with a central session control 
instance. As all participants speak only with the central control entity 
it can ensure that SSRC, collision is avoided if the same key are used. 
However in this case it is probably better to use individual master keys 
for each sender. However there seems to be some need to fix the a=crypto 
syntax to support this case.

- The multicast conference, each sender announces there attributes 
individually to each participant. In this case all should be required to 
use individual master keys. Thus there is no risk for two time pads.

As I see it with a few changes to the a=crypto attribute multicast can 
be fixed. However there is need to flesh out the scenarios and ensure 
that the signalling works for these.

So as a conclusion there is need for more work in the multicast 
environment. Also statement as the second bullet in 4.1.1.2 is not correct.

6. void

7. Section 5.1.1.1 the example line includes a extra "<" at the 
"lifetime" parameter.

8. Section 5.1.1.1: How does one know what type of key that is specified 
in the key field. To my understanding there are a possibility for at 
least three different levels of keys in SRTP. A top level master key, a 
master key for a single SSRC, individual keys for streams. There is 
currently no way of differentiating or requiring a key to be of a 
certain type.

9. In section 5.1.1.1 there is a rule that the key length must be 
correct for the signalled length. However a BASE64 encoded key|salt 
combination may need some padding. So I assume that key lengths changing 
it to up to the next base64 boundary is okay.

10. Section 5.1.1.1: The lifetime parameter "from-to" is not clear about 
how the number of packets are calculated and applies to. Is this the 
total number of packets a master key can be used for, or does it applies 
to any derived key, and when one of the derived keys reach this number 
it needs to rekey? I don't think the text in section 5.3.1 really helps 
either, as it makes it impossible for individual participants to 
actually calculate how many packets that has been used by the master key.

11. Section 5.2, I think this section could gain by an table that 
tabulates the crypto suits and its major parameters for easy access 
instead of the description.

12. Section 5.3.1: The SRC parameter I think need to be better 
clarified.  If one gives a ROC/SEQ is given, it MUST be given in 
relation to the SSRC for which it is valid.

13. When it comes to offer answer for multicast, it must be made clear 
how one uses SRC to ensure that a joining participant selects a SSRC 
that will not collide.

14. Section 5.3.1, what is an invalid SSRC? How do you know.

15. How is the the usage of late binding and shared master key 
indicated, to allow a receiver to determine what is used.

16. Section 5.3.2, It says that 2^0 is 1, as this being a frequency, key 
derivation should be performed every packet. I would recommend to remove 
this wrong motivation, and simply state it as being an exception.

17. In 6.1.1.2 you have a restriction that from-to must only be used in 
"recvonly", doesn't this depend on the scoping of these attributes. As 
pointed out in point 10, the from to context is not clear.

18. In 6.1.2.1, isn't the accepting of a crypto line, one and only one?

19. In 6.1.2.1 Shouldn't there be a rule requiring the use of SRC with 
SSRC when common master key is used.

20. In 6.1.2.1, Before the open issue, there is a statement that the is 
no need for optional parameters. I think this is not, true or what is 
meant with optional parameters must be clarified, there are certain use 
case that definitely will require use of certain parameters.

21. In 6.1.3.2 , there is text saying that session parameters shall be 
ignored, I don't agree with that.

22. In 6.1.3, In the paragraph after the bullets, one may get the 
impression that multiple sources only are needed in multicast. That is 
not true. Also in unicast a single end-point may need to use multiple 
SSRCs, for example for retransmission.

23. In 7.3, I think the RECOMMEND to use a key management protocol if 
not carried in authenticated and encrypted transport format, should be a 
SHOULD.

24, Section 7.3, Question, How does one know that the signalling over 
network (b) even is encrypted.

25. Section 8: "key-params" does not need to be recursively defined, the 
second "key-params", needs only to be a "key-param"

26. Section 8.1: key-method-ext, isn't this a "token"? I think 
restricting the usage of other special characters then "_" is possibly 
to restricted.

27. Section 8.2, is really decimal form for SSRC the best form. I would 
recommend a format in hex instead, e.g. 8*HEX, as an SSRC really is a 32 
bit binary identifier, not a number in its normal sense.

28. Section 10.2.1, I think that you should review the standard IANA 
registration levels in RFC 2434, I think that for the key method, it is 
probably, "standards action" that is the right one.

29. Section 10.2.2: I don't think that SRTP crypto suit registrations 
needs only to take "inline" into consideration. I think it should say 
that it should be defined in relation to applicable key-methods. I also 
think that the IANA section should be a bit more explicit what really is 
required.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Mark Baugher <[email-masked]>
Date: Sat, 13 Dec 2003 17:57:10 -0800

Magnus,
   My co-authors and I will address your issues prior to the next version 
of the I-D, which we should submit within the next several weeks.

   I have one comment, however, and that concerns your comments on 
multicast.  We proposed to the last Wg meeting to drop multicast from the 
draft altogether and focus just on the unicast - as a divide and conquer 
strategy.  I expect multicast functionality to be added in a subsequent 
draft when people are actively designing systems to support it.

   This proposal was posted in the WG minutes to this list and I have heard 
no dissent from anyone.

cheers, Mark
At 04:43 AM 12/12/2003, Magnus Westerlund wrote:
>that the draft presents and the discussion during the IETF meeting. There 
>are a couple of points below that, especially 5, that I believe requires 
>further discussion and study.
>
>
>1. As a general thing I think authors should think about how the pages get 
>clipped by the pages. For improved readability one should move any new 
>sections, etc. that only gets a few line to the next page. One such 
>example is to start the table of contents on the first page, instead of on 
>the second. Another if the section 4 heading that are sole on the last 
>line of a page.
>
>4. In the last paragraph of section 2, I think this section would benefit 
>of being split into two paragraphs.
>
>into different use cases. I think that removing all the multicast is a bad 
>choice as there are situation where it seems to work. I would start by 
>dividing the usage into scenarios where one can use the a=crypto successfully.
>
>- The one to many, using ASM case. This is a advertisement case. Only the 
>intended sender declares his SSRC/ROC/SEQ to ensure that all receivers 
>does not use the senders SSRC and causes a two time pad with it. As all 
>receivers are unsynchronized unless other mechanism is used, there might 
>happen SSRC collisions. However if you either don't encrypt the RTCP, 
>which is the only thing they will send, it is not a problem. Also if RTCP 
>encryption is used, it might be deemed acceptable with the low risk of two 
>time pads that exist. However this is clearly a security trade off.
>
>- The one to many, using SSM, as the receivers can't send to anybody else 
>there is no problem. If one uses unicast RTCP feedback, the same security 
>consideration regarding RTCP two time pads apply, however the distribution 
>of the offending packets will not be the same as for ASM use cases.
>
>- The multicast conference case, with a central session control instance. 
>As all participants speak only with the central control entity it can 
>ensure that SSRC, collision is avoided if the same key are used. However 
>in this case it is probably better to use individual master keys for each 
>sender. However there seems to be some need to fix the a=crypto syntax to 
>support this case.
>
>As I see it with a few changes to the a=crypto attribute multicast can be 
>fixed. However there is need to flesh out the scenarios and ensure that 
>the signalling works for these.
>
>7. Section 5.1.1.1 the example line includes a extra "<" at the "lifetime" 
>parameter.
>
>in the key field. To my understanding there are a possibility for at least 
>three different levels of keys in SRTP. A top level master key, a master 
>key for a single SSRC, individual keys for streams. There is currently no 
>way of differentiating or requiring a key to be of a certain type.
>
>9. In section 5.1.1.1 there is a rule that the key length must be correct 
>for the signalled length. However a BASE64 encoded key|salt combination 
>may need some padding. So I assume that key lengths changing it to up to 
>the next base64 boundary is okay.
>
>how the number of packets are calculated and applies to. Is this the total 
>number of packets a master key can be used for, or does it applies to any 
>derived key, and when one of the derived keys reach this number it needs 
>to rekey? I don't think the text in section 5.3.1 really helps either, as 
>it makes it impossible for individual participants to actually calculate 
>how many packets that has been used by the master key.
>
>clarified.  If one gives a ROC/SEQ is given, it MUST be given in relation 
>to the SSRC for which it is valid.
>
>13. When it comes to offer answer for multicast, it must be made clear how 
>one uses SRC to ensure that a joining participant selects a SSRC that will 
>not collide.
>
>15. How is the the usage of late binding and shared master key indicated, 
>to allow a receiver to determine what is used.
>
>20. In 6.1.2.1, Before the open issue, there is a statement that the is no 
>need for optional parameters. I think this is not, true or what is meant 
>with optional parameters must be clarified, there are certain use case 
>that definitely will require use of certain parameters.
>
>impression that multiple sources only are needed in multicast. That is not 
>true. Also in unicast a single end-point may need to use multiple SSRCs, 
>for example for retransmission.
>
>23. In 7.3, I think the RECOMMEND to use a key management protocol if not 
>carried in authenticated and encrypted transport format, should be a SHOULD.
>
>26. Section 8.1: key-method-ext, isn't this a "token"? I think restricting 
>the usage of other special characters then "_" is possibly to restricted.
>
>needs only to take "inline" into consideration. I think it should say that 
>it should be defined in relation to applicable key-methods. I also think 
>that the IANA section should be a bit more explicit what really is required.
>
>
>Cheers
>
>Magnus Westerlund
>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 16 Dec 2003 16:25:51 -0500

Hi Magnus

Thank you very much for your detailed review - please see below for answers. To
make it a easier to track any further discussion that might be needed on any of
these points, I'd suggest that they be broken out in separate threads

> on the second. Another if the section 4 heading that are sole on the

OK

> would be acceptable to remove all third level items.

I prefer keeping third level items.

> text after the introduction.

We'll make it a lower-case must (corresponding MUSTs found in Section 10)

> benefit of being split into two paragraphs.

OK (I assume split it right before "In Section 3, we...")

> environment. Also statement as the second bullet in 4.1.1.2 is not correct.

I agree that if we were to address multicast in this document, then we would
need to identify the different multicast cases and address them one by one. The
author team started doing that before publishing this version, but did not find
the task to be as simple as you suggest. We saw several problems and
complications related to multicast (e.g. the "use" parameter,
hierarchical/layered encoding schemes, SSRC "collissions" in the SDP). We felt
(and feel) fairly confident that inclusion of multicast support in this
document will result in a significant delay in progressing this work, and since
there is a real-life need to move this along, we proposed to leave multicast
for further study. There was consensus in the meeting for that, and until now,
there hasn't been any objections on the mailing list either. I still favor
leaving multicast support for further study.

> 7. Section 5.1.1.1 the example line includes a extra "<" at the

Got it.

> currently no way of differentiating or requiring a key to be of a

I'm not sure what the two different master keys you are referring to are -
AFAIK all keys for SRTP are derived from one random number, the SRTP master
key. Section 5.1.1.1 does explicitly talk about "master keys" (not session
keys), but if there are specific places where you think it is unclear and/or
you have some suggested text, please let me know.

> it to up to the next base64 boundary is okay.

Yes - good point.

> actually calculate how many packets that has been used by the master key.

It is simply intended to be the <"From", "To"> parameter as described in
srtp-09:

"* <"From", "To"> values, specifying the lifetime for a master key,
     expressed in terms of the two 48-bit index values inside whose
     range (including the range end-points) the master key is valid.
     For the use of <From, To>, see Section 8.1.1.  <"From", "To"> is an
     alternative to the MKI and assumes that a master key is in one-to-
     one correspondence with the SRTP session key on which the <"From",
     "To"> range is defined."

Perhaps we need to make that clearer or is there more to it than that ?

> instead of the description.

I like the descriptive text we have in there but see your point as well. How
about adding the table as an easy reference/overview ?

> relation to the SSRC for which it is valid.

OK

> how one uses SRC to ensure that a joining participant selects a SSRC

That is one of the problems we faced with multicast which is why we want to
leave multicast support for further study.

> 14. Section 5.3.1, what is an invalid SSRC? How do you know.

We'll clarify.

> indicated, to allow a receiver to determine what is used.

Not sure I understand the question. When late binding is used, you are just not
being informed about the SSRC for the crypto context in the SDP but rather you
determine based on the packet received. What is unique about shared master keys
in this context as opposed to the non-late-binding case ?

> this wrong motivation, and simply state it as being an exception.

OK

> pointed out in point 10, the from to context is not clear.

6.1.1.2 is about multicast which we want to leave for further study.

> 18. In 6.1.2.1, isn't the accepting of a crypto line, one and only one?

I don't follow - can you point me to the specific text ?

> SSRC when common master key is used.

Not necessarily - if you have centralized SSRC allocation you wouldn't need
this. However, I agree that a warning would be appropriate here.

> case that definitely will require use of certain parameters.

(Section 6.1.2.2 I presume). This is a multicast section which should be left
for further study.

> ignored, I don't agree with that.

This is a multicast section which should be left for further study.

> SSRCs, for example for retransmission.

Right. We'll start a separate thread on this issue.

> not carried in authenticated and encrypted transport format, should be a

SHOULD and RECOMMENDED are synonymous per RFC 2119.

> network (b) even is encrypted.

That depends on the signaling protocol. I guess you can never really know for
sure, but at least if you are using SIP, then use of SIPS-URIs will "ensure"
this.

> second "key-params", needs only to be a "key-param"

Fixed.

> restricting the usage of other special characters then "_" is possibly

A name is a name. We can change it to token if you want, but I don't see how
this is too restrictive (however I now found an error in the key-info
production, so thanks :-).

> bit binary identifier, not a number in its normal sense.

A matter of style I guess. This is probably a silly argument, but I'm a bit
worried about using decimal every else and then all of a sudden hex. If we do
it, then what do you think about prefixing it with an "x" ?

> probably, "standards action" that is the right one.

Ok - is that the consensus of everybody (fine with me) ?

> think that the IANA section should be a bit more explicit what really is

OK

Again, thanks for the comments.

-- Flemming

---

From: Colin Perkins <[email-masked]>
Date: Tue, 16 Dec 2003 23:31:22 +0000

Hi,

[cc list trimmed, I assume everyone's on the mailing list...]

--> Flemming Andreasen <[email-masked]> writes:
...
> > low risk of two time pads that exist. However this is clearly a
> > security trade off.
> >
> > instance. As all participants speak only with the central control
> > entity it can ensure that SSRC, collision is avoided if the same key
> > are used. However in this case it is probably better to use individual
> > master keys for each sender. However there seems to be some need to fix
> > the a=crypto syntax to support this case.
> >
> > individually to each participant. In this case all should be required
> > to use individual master keys. Thus there is no risk for two time pads.
> >
> I agree that if we were to address multicast in this document, then we
> would need to identify the different multicast cases and address them one
> by one. The author team started doing that before publishing this
> version, but did not find the task to be as simple as you suggest. We saw
> several problems and complications related to multicast (e.g. the "use"
> parameter, hierarchical/layered encoding schemes, SSRC "collissions" in
> the SDP). We felt(and feel) fairly confident that inclusion of multicast
> support in this document will result in a significant delay in
> progressing this work, and since there is a real-life need to move this
> along, we proposed to leave multicast for further study. There was
> consensus in the meeting for that, and until now, there hasn't been any
> objections on the mailing list either. I still favor leaving multicast
> support for further study.

I strongly agree with Flemming here: let's get the initial version of this
draft published, then worry about multicast support. 

-- 
Colin Perkins
http://csperkins.org/