Subject: [MMUSIC] SDP security/privacy concerns (draft-ietf-mmusic-sdp-new-22.txt)

From: "Anders Klemets" <[email-masked]>
Date: Sat, 4 Dec 2004 11:39:33 -0800

It looks to me like the SDP syntax for "o=" is forcing users to divulge
information that could be considered sensitive, or private.

According to draft-ietf-mmusic-sdp-new-22.txt, the username field on the
"o=" line is supposed to reveal the user's login identity.  Divulging
this information to strangers is not a good security practice.

The SDP spec allows the "username" field to be set to "-", but only if
the originating host does not support the concept of user IDs.  I think
the spec should be changed to allow the "username" field to be set to
"-" even when the host has a concept of user IDs.

Current text:

   <username> is the user's login on the originating host, or it is "-"
      if the originating host does not support the concept of user ids.
      The <username> MUST NOT contain spaces.

Proposed new text:

   <username> is the user's login on the originating host. 
      The <username> may be "-", or a random character string, as long
as
      the tuple of <username>, <sess-id>, <nettype>, <addrtype> and 
      <unicast-address> form a globally unique identifier for the
session.
      The <username> MUST NOT contain spaces.

There is a similar problem "unicast-address" parameter on the "o=" line.
For security reasons, some people may not want to divulge their IP
address or domain name, especially if the host is behind a NAT.  I think
we can fix it in a similar way.

This what the text currently says:

   <unicast-address> is the address of the machine from which the
      session was created.  For an address type of IP4, this is either
      the fully-qualified domain name of the machine, or the
      dotted-decimal representation of the IP version 4 address of the
      machine.  For an address type of IP6, this is either the
      fully-qualified domain name of the machine, or the compressed
      textual representation of the IP version 6 address of the machine.
      For both IP4 and IP6, the fully-qualified domain name is the form
      that SHOULD be given unless this is unavailable, in which case the
      globally unique address MAY be substituted.  A local IP address
      MUST NOT be used in any context where the SDP description might
      leave the scope in which the address is meaningful.

My proposal is to keep that text, but add this extra sentence at the
end:

      A randomly generated character string MAY be used as
<unicast-address>
      as long as the tuple of <username>, <sess-id>, <nettype>,
<addrtype> and 
      <unicast-address> form a globally unique identifier for the
session.

Comments?

Anders

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

---

From: Colin Perkins <[email-masked]>
Date: Sun, 5 Dec 2004 18:46:09 +0000

Anders,

On 4 Dec 2004, at 19:39, Anders Klemets wrote:
> It looks to me like the SDP syntax for “o=” is forcing users to 
> divulge information that could be considered sensitive, or private.
>
> According to draft-ietf-mmusic-sdp-new-22.txt, the username field on 
> the “o=” line is supposed to reveal the user’s login identity.  
> Divulging this information to strangers is not a good security 
> practice.
>
> The SDP spec allows the “username” field to be set to “-“, but only if 
> the originating host does not support the concept of user IDs.  I 
> think the spec should be changed to allow the “username” field to be 
> set to “-“ even when the host has a concept of user IDs.

Seems reasonable to me.

...
> There is a similar problem “unicast-address” parameter on the “o=” 
> line.  For security reasons, some people may not want to divulge their 
> IP address or domain name, especially if the host is behind a NAT.  I 
> think we can fix it in a similar way.
>

The <unicast-address> must  be consistent with the <nettype> and 
<addrtype> fields, so I don't think it can be a randomly generated 
string. I wouldn't object to implementations that use 127.0.0.1 though, 
provided the username was chosen to ensure uniqueness.

Colin