Subject: [MMUSIC] IESG comments on SDPnew

From: Colin Perkins <[email-masked]>
Date: Wed, 16 Jul 2003 15:57:45 +0200

The IESG recently review the SDPnew draft, and sent the following comments.
I'll be talking about these in MMUSIC tomorrow.

Colin

>Ned Freed:
>This document should explicitly say it obsoletes RFC 2327.
>
>This document apparently defines the application/sdp media type, replacing
>the definition in RFC 2327, but contains no media type registration form
>nor any IANA action associated with the registration. (This was also true
>of RFC 2327.)
>
>A 44 page document REALLY needs a table of contents. (I realize the RFC
>Editor is supposed to deal with this, but RFC 2327 is 42 pages and didn't
>have a TOC either.)
>
>That's it!
>
>Steve:
>k= strikes me as almost useless. It doesn't have enough information
>(such as algorithm) to really be usable. I see no protection against
>replay prevention, nor any mention of that as a requirement for secure
>transport of SDP announcements. In fact, nothing is said about channel
>requirements in this context other than "secure and trusted". Is k=
>really used? Should it be deleted in favor of a pointer to
>draft-ietf-mmusic-sdescriptions?
>
>The Security Consideration section says that automatic mechanisms
>SHOULD NOT be used to start up interactive applications without user
>knowledge. I'd prefer MUST NOT, and I'd ask for consent, not simplhy
>knowledge. See the /dev/audio part of
>http://www.cert.org/advisories/CA-1993-15.html for why this is a
>problem...
>
>Russ:
>      Section 4.3 talks about private sessions. It says:
>
>            "The details of how encryption is performed are dependent on
>            the mechanism used to convey SDP - e.g. mechanisms are defined
>            for SDP transported using SAP [RFC2974] and SIP [RFC3261]."
>
>      Why aren't S/MIME for email and TLS for WWW included here?
>
>      In section 5, the discussion of encryption keys says:
>
>            "k=clear:<encryption key>
>
>              The encryption key is included untransformed in this key
>              field. This method MUST NOT be used unless it can be
>              guaranteed that the SDP is conveyed over a secure channel.
>
>              k=base64:<encoded encryption key>
>
>              The encryption key is included in this key field but has
>              been base64 encoded because it includes characters that are
>              prohibited in SDP. This method MUST NOT be used unless it
>              can be guaranteed that the SDP is conveyed over a secure
>              channel."
>
>      These restrictions are necessary but not sufficient. You must also
>ensure that the secure channel is with the party that is authorized to
>join the session, not an intermediary. If a caching server is used, there
>ought to be a way to keep the server from accessing the key.
>
>      Also, it is generally a good idea to indicate the algorithm that a
>cryptographic key is intended to support. I suggest that the encryption
>key type be revised to specify the key as well as the algorithm that the
>key will be used with.
>
>      Finally, many security protocols require two keys, one for
>confidentiality and another for integrity. This specification does not
>support the transfer of two keys.
>
>      In section 6, the document says:
>
>            "Use of the "k=" field poses a significant security risk,
>            since it conveys session encryption keys in the clear. SDP
>            MUST NOT be used to convey key material, unless it can be
>            guaranteed that the channel over which the SDP is delivered is
>            both private and authenticated."
>
>      I agree. It would therefore be desirable for the "k=" field to
>      support
>two other alternatives. First, it would be nice to name the key without
>actually including the key. In PEM (see RFC 1040), the Recipient-ID was
>used to name key-encryption keys, and a similar scheme could be employed
>here. Second, it would be nice to encrypt the session key in a key that is
>not included in SDP. PEM also includes a mechanism for wrapped symmetric
>keys.
>
>Ted:
>In Section 5, for the description of u=<URI>
>
>          I'd suggest eliminating "as used by WWW clients." and adding a
>          citation to draft-fielding-uri-rfc2396bis (or at least rfc2396).
>          Note that this definition seems to presume that all URIs used
>          will be dereferencable, which is not true for all URIs. If this
>          is a limitation, then it should be stated.
>
>          The k=<uri> also seems to presume that the URI is
>          dereferencable. If this is a limitation of the URI, it should be
>          made explicit
>which schemes
>          are appropriate here. Frankly, it seems to mean http:; if that
>          is the case, specifying it seems like a good idea. Even for
>          dereferencable URI schemes, not all will use MIME to mark the
>          reply (think of an ftp: URI, for example). When they do, the
>          mime content-encoding specifies the encoding of the _message_,
>          so reusing the word"encoding" here seems problematic. How would
>          "For those URI schemes which use MIME, the content-encoding and
>          content-type headers of the reply may provide guidance on the
>          format of the key." work?
>
>          On that same hobby horse, the ABNF in the appendix has:
>            ; sub-rules of 'u='
>              uri = URI-reference; see RFC1630 and RFC2732
>
>          I think this should be a pointer to 2396 or the 2396bis draft.
>
>          For the a= inactive designation, we've discussed what addresses
>          to use for sessions which are being set up but for which
>          addresses are not
>	  yet known.  It was suggested apps use something like "sdp.inactive" so
>	  that the .inactive TLD could reinforce the a=inactive flag. In that
>	  instance, would the presence of that TLD be a condition under which
>	  the RTCP SHOULD is appropriately not done, and no RTCP sent? If so, is
>	  mentioning that case appropriate here?
>
>          In the IANA considerations, it looks the draft should specify
>          that the
>	  IANA must update the MIME media type registration to point to this doc
>	  instead of RFC 2327.
>
>Notes:
>
>Having Section 5 contain so much without sub-headers made it hard to
>give pointers to sections in the comments; that may be true for others
>using the spec as well.
>
>In section 5, in the section describing the first subfield of c=
>          Just as a query, has anyone considered using a specific marker
>          of private address realms for SDP? That is, using a network type
>          other than IN to indicate that the domain name or address given
>          are not globally unique/globally reachable?
>
>In the Security considerations, "Many different protocols may be used
>to distribute session description," looks like session description should
>be plural.
>
>Bill:
>In the ABNF, the definition of "m1" ends with an extra ).
>
>
>The text says that type characters are case-sensitive.
>Unfortunately, this means that ASCII values have to be
>used in the ABNF instead of strings, since ABNF strings
>are case-insensitive. e.g.
>
>            proto-version = "v=" 1*DIGIT CRLF
>
>really has to be something like
>
>            proto-version = %x76 "=" 1*DIGIT CRLF
>or
>            proto-version = %x76.3d 1*DIGIT CRLF
>
>since both "v=0" and "V=0" match the one with "v=".
>
>I realize that this latter error is copied from RFC 2327. If this is
>the only objection I'm not going to stand on it too strongly.
>
>    Bill
>
>COMMENTS:
>========
>Erik Nordmark:
>Intro/abstract doesn't say the document obsoletes RFC 2137, which
>I think is the intent.
>
>The text on internationalization says UTF-8 only applies to informational
>fields. Does this mean it isn't required to perform any normalization
>whatsoever on the UTF-8?
>Would it make sense to explicitly state that normalization isn't needed.
>
>Typo:
>                removed. It is assumed that transports of SDP specify will
>                specify this.
>s/specify//
>

-- 
Colin Perkins
[email-masked]

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

---

From: Mark Baugher <[email-masked]>
Date: Wed, 16 Jul 2003 07:30:37 -0700

Colin,
   I'd like to comment on Russ's comment.  See below.

> >not included in SDP. PEM also includes a mechanism for wrapped symmetric

I think it would be wrong to place security mechanisms inside SDP since SDP 
is used with an encapsulating protocol.  SDP needs to use the mechanisms of 
the encapsulating protocol for protecting its keys, cryptographic 
parameters, session security parameters, and other descriptions that are of 
security interest.

That being said, I agree with Russ and Steve that k= is 
under-specified.   That's what I found a year ago when I needed to use it 
for SRTP.

Mark

---

From: Hanne Moa <[email-masked]>
Date: Wed, 16 Jul 2003 16:58:30 +0200

* On 2003-07-16 15:57:45 +0200 Colin Perkins wrote:
> >really used?

I've been monitoring SAP-packets for over a year now and never seen it.
Ditto for z= (time zone adjustments).

Furthermore, more than 90% of sdp over sap is unspecified for time,
that is: t=0 0. It is used for just about anything: on-demand, 24/7
webcams, conferences... It is so vague as to be useless.

Here's one from today:

v=0
o=- 12157 2 IN IP4 128.223.83.33
s=IETF 57 Channel-1 MPEG-4
i=IETF57 - Channel-1 MPEG-4
e=[email-masked]               <--- wow, one of the 5% valid ones!
b=AS:500
t=0 0                                       <--- a-hum
a=tool:IP/TV Content Manager 3.4.14
a=type:broadcast
a=live:capture:1
m=video 49470 RTP/AVP 31 32 96 97
c=IN IP4 224.2.195.59/127
a=x-iptv-videoheight:240
a=x-iptv-videowidth:320
a=x-iptv-svr:video 81.160.32.4 live
a=quality:8
a=framerate:30
a=fmtp:96 profile-level-id=1;config=000001B001000001B50EE04040AF0000010000000120
00845D4C285020F0A31F
a=rtpmap:96 MP4V-ES/90000
a=rtpmap:97 WBIH/90000
m=audio 19154 RTP/AVP 0 3 5 10 11 14 96 97 98 99 100 101 102 103 104 105 106
c=IN IP4 224.2.166.105/127
a=x-iptv-svr:audio 81.160.32.4 live
a=fmtp:14 layer=3; samplerate=11025; mode=stereo;
a=rtpmap:96 X-WAVE/8000
a=rtpmap:97 L8/8000/2
a=rtpmap:98 L8/8000
a=rtpmap:99 L8/22050/2
a=rtpmap:100 L8/22050
a=rtpmap:101 L8/11025/2
a=rtpmap:102 L8/11025
a=rtpmap:103 L16/22050/2
a=rtpmap:104 L16/22050
a=rtpmap:105 L16/11025/2
a=rtpmap:106 L16/11025

If t= *is* used, there's very rarely an r= (repetitions) in the same
sdp, and often an almost, but not quite identical message (+n seconds
in the second field of t= will be sent, with a slightly modified
identifier (o=) every n seconds, overlapping with another similarly
almost-clone message every n+m seconds. In these situations t=0 0
actually would have made sense!)

Oh, and e= (email-address) and p= (phone number) are used for the
strangest things. I should have saved the haiku...

HM.

---

From: Stephen Casner <[email-masked]>
Date: Wed, 16 Jul 2003 10:55:32 -0700 (PDT)

> webcams, conferences... It is so vague as to be useless.

The IP/TV product, initially from Precept Software then later and still
from Cisco, uses both t= and z= but (to my recollection) not k=.

                                                        -- Steve

---

From: Ross Finlayson <[email-masked]>
Date: Wed, 16 Jul 2003 13:17:22 -0700

Because of the known limitations/problems with "k=", plus the fact that we 
now have a better way of describing keying information (i.e., 
"ietf-mmusic-sdescriptions"), I think that the "SDPnew" document should 
just get rid of "k=" (or, at the very least, note that it's deprecated).

         Ross.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 17 Jul 2003 08:18:59 +0200

--> Ross Finlayson <[email-masked]> writes:
> Because of the known limitations/problems with "k=", plus the fact that
> we now have a better way of describing keying information (i.e., 

Certainly we should note that it's deprecated. But, we need to determine if
there are any implementations before deciding if we can remove "k="...

-- 
Colin Perkins
[email-masked]