Subject: [Ietf-calsify] Issue 80: security considerations section -- proposal

From: aki.niemi at nokia.com (Aki Niemi)
Date: Tue Jun 12 00:55:58 2007

Hi all,

A while back, Jay posted an issue about the security considerations of 
rfc2445bis, which is tracked as issue 80.

In one of the recent Jabber chats, I promised to take a stab at new text 
for the section. Here's the proposal:

<section title='Security Considerations'>

   <p>
     Because calendaring and scheduling information is very
     privacy-sensitive, the protocol used for the transmission of
     calendaring and scheduling information MUST have capabilities to
     protect the information from possible threats, such as
     eavesdropping, replay, message insertion, deletion, modification
     and man-in-the-middle attacks.
   </p>

   <p>
     As this document only defines the data format and media type of
     text/calendar that is independent of any calendar service or
     protocol, it is up to the actual protocol specifications such as
     <xref target="I-D.xxx">iTIP</xref>, <xref
     target="I-D.xxx">iMIP</xref> and <xref
     target="RFC4791">CalDAV</xref> to describe the threats that the
     above attacks present, as well as ways in which to mitigate them.
   </p>

In other words, rfc2445bis would now be completely silent about 
authorization issues, and instead move responsibility over to actual 
calendaring protocols and/or services. I'll note that a similar approach 
has been taken in at least in RFC3863, Presence Information Data Format 
(PIDF).

Any opinions?

Cheers,
Aki
(as individual contributor)

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Wed Jun 13 06:40:15 2007

+1

Aki Niemi wrote:
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: lists at block-online.eu (Oliver Block)
Date: Wed Jun 13 13:13:31 2007

Hello Aki,

even though I like your proposal and to know that my calendar data is safe, Is 
the MUST admissible in this context?

<copy src="rfc2119">
1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.
</copy>

Regards,

Oliver

---

From: aki.niemi at nokia.com (Aki Niemi)
Date: Thu Jun 14 00:25:34 2007

Hi Oliver,

This is a point that has been discussed a lot. It is true that RFC2119 
text should only be used when there is an actual implementation choice 
that is observable from the outside. Here, I agree that a "MUST" is just 
hand-waiving, so I'm ok making it a "must" instead.

Cheers,
Aki

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Thu Jun 14 01:02:08 2007

> hand-waiving, so I'm ok making it a "must" instead.

I think it's rather a SHOULD (or a should?). It'a really up to the groupware 
server developers/designers and out of scope for the data format definition. 
If a server team has good reasons against implementing some security measure, 
it's their business, not ours.

Cheers, 
Reinhold

> >>      and man-in-the-middle attacks.

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

---

From: aki.niemi at nokia.com (Aki Niemi)
Date: Thu Jun 14 02:48:51 2007

> it's their business, not ours.

Yes, agree. And this is why it says capabilities. It's always in the 
admin's or user's discretion whether to turn them on.

Cheers,
Aki