Subject: [calsify] UID value

From: Cyrus Daboo <[email-masked]>
Date: Tue, 05 Jul 2016 10:45:20 -0400

Hi folks,
Following the IESG review of draft-ietf-calext-extensions-04, we decided 
that there was a need to tighten up the recommendations on the UID value 
that were originally defined in RFC5545 and which are now a potential 
security and/or privacy threat.

To that end, I propose making the following three changes, and I would 
appreciate feedback on these.

---
Added to the end of section "5.3.  UID Property":

   The description of the "UID" property in [RFC5545] contains some
   recommendations on how the value can be constructed.  In particular,
   it suggests use of host names, IP addresses, and domain names to
   construct the value.  However, this is no longer considered good
   practice, particularly from a security and privacy standpoint, since
   use of such values can leak key information about a calendar user, or
   their client and network environment.  This specification updates
   [RFC5545] by stating that "UID" values MUST NOT include any data that
   might identify a user, host, domain, or any other security or privacy
   sensitive information.  It is RECOMMENDED that calendar user agents
   now generate "UID" values that are hex-encoded UUID [RFC4122] values.

   The following is an example of such a property value:

   UID:5FC53010-1267-4F8E-BC28-1D7AE55A7C99

   Additionally, if calendar user agents choose to use other forms of
   opaque identifiers for the "UID" value, they MUST have a length less
   than 255 octets, and MUST conform to the "iana-token" ABNF syntax
   defined in Section 3.1 of [RFC5545].
---
Added to the end of "7.  Security Considerations":

   This specification changes the recommendations on how "UID" property
   values are constructed to minimize leaking any information that might
   be security sensitive.
---
Added to the end of "8.  Privacy Considerations":

   This specification changes the recommendations on how "UID" property
   values are constructed to minimize leaking any information that might
   be privacy sensitive.
---

-- 
Cyrus Daboo

---

From: Ken Murchison <[email-masked]>
Date: Tue, 5 Jul 2016 11:21:53 -0400

Hi Cyrus,

I'm not a security expert but this looks good to me, especially if the saag folks sign off on it. 

--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
> On Jul 5, 2016, at 10:45 AM, Cyrus Daboo <[email-masked]> wrote:
> 
> Hi folks,
> Following the IESG review of draft-ietf-calext-extensions-04, we decided that there was a need to tighten up the recommendations on the UID value that were originally defined in RFC5545 and which are now a potential security and/or privacy threat.
> 
> To that end, I propose making the following three changes, and I would appreciate feedback on these.
> 
> ---
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Michael Douglass <[email-masked]>
Date: Tue, 5 Jul 2016 11:29:54 -0400

This may not be sufficient.

To make a UUID globally unique doesn't it use some information about the 
host?

https://www.ietf.org/rfc/rfc4122.txt section 4.1.6

4.1.6.  Node

    For UUID version 1, the node field consists of an IEEE 802 MAC
    address, usually the host address.  For systems with multiple IEEE
    802 addresses, any available one can be used.  The lowest addressed
    octet (octet number 10) contains the global/local bit and the
    unicast/multicast bit, and is the first octet of the address
    transmitted on an 802.3 LAN.

    For systems with no IEEE address, a randomly or pseudo-randomly
    generated value may be used; see Section 4.5.  The multicast bit must
    be set in such addresses, in order that they will never conflict with
    addresses obtained from network cards.

    For UUID version 3 or 5, the node field is a 48-bit value constructed
    from a name as described in Section 4.3.

    For UUID version 4, the node field is a randomly or pseudo-randomly
    generated 48-bit value as described in Section 4.4.

---

From: Michael Douglass <[email-masked]>
Date: Tue, 5 Jul 2016 11:50:38 -0400

Echoing Ken:
I'm no security expert but...

Thinking further - the requirement for a globally unique value seems to 
require that it contain information about WHO generated it.

That's a problem if the WHO is YOU.

On the other hand couldn't we define a UID service which produced UUIDs 
which are only identified as coming from that service.

There's probably still some possibility of problems but this seems more 
secure

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 05 Jul 2016 11:52:47 -0400

Hi Michael,

> https://www.ietf.org/rfc/rfc4122.txt section 4.1.6

How about:

   It is RECOMMENDED that calendar user agents
   now generate "UID" values that are hex-encoded random UUID values as
   defined in Section 4.4 of [RFC4122].

That specifically targets the "random" variant of UUID generation in 4122.

-- 
Cyrus Daboo

---

From: Philipp Kewisch <[email-masked]>
Date: Tue, 5 Jul 2016 19:07:20 +0200

On 7/5/16 4:45 PM, Cyrus Daboo wrote:
> Hi folks,
> Following the IESG review of draft-ietf-calext-extensions-04, we
> decided that there was a need to tighten up the recommendations on the
> UID value that were originally defined in RFC5545 and which are now a
> potential security and/or privacy threat.
>
Hi Cyrus,

I mostly agree, aside from the "domain names" part, which I think is not
quite clear. If this means the domain name of the calendar user then I
agree that shouldn't show up. On the other hand, I've seen a few
calendaring systems, mostly those providing an ics frontend to an
existing system, that use the UID as a way to reconstruct the item they
are querying from the database. This way they do not have to keep a
separate mapping between for example a uuid and their database items.
These systems sometimes include a domain name in their generated UID,
but it is the domain name of the calendaring system generating the data.
I think this kind of domain name should be allowed, and using MUST NOT
would block that.

Maybe you could make the following change, or something to that effect:

OLD
  This specification updates
  [RFC5545] by stating that "UID" values MUST NOT include any data that
  might identify a user, host, domain, or any other security or privacy
  sensitive information.

NEW
  This specification updates
  [RFC5545] by stating that "UID" values MUST NOT include any data that
  might identify a user, for example the user's host name or domain, or
  any other security or privacy sensitive information.

END

What do you think?
Philipp