[Ietf-caldav] References in draft-dusseault-caldav-12
lisa at osafoundation.org
Fri Jun 23 11:07:08 PDT 2006
I answered too fast and forgot one important point: a single,
mandatory-to-implement secure transport is necessary to have both
interoperability and to meet the "no plain-text passwords in the
clear" requirement. If a server supported only IPSec and a client
supported only TLS, that would not be interoperable. I find TLS to
be the preferable mandatory-to-implement solution.
It looks like our text could still do with some improvement however;
something along the lines of "Servers MUST NOT offer BASIC over an
unprotected channel. Clients MUST support TLS in order to provide
one channel-encryption mechanism that servers can rely on if they
decide to offer BASIC."
On Jun 23, 2006, at 11:03 AM, Lisa Dusseault wrote:
> On Jun 23, 2006, at 10:57 AM, Kervin L. Pierre wrote:
>> I think it can be argued that since 4.1.1 states
>> that either TLS or IPSEC is valid to remedy the
>> situation, that the authors were suggesting that
>> the protocol's _use_ be protected and not that the
>> protocol itself has to supply protection. Ie.
>> plain-text CalDAV over an IPSEC VPN would satisfy
>> 4.1.1 in that case.
>> In other words the CalDAV spec does not have to
>> mandate TLS but rather mandate that either TLS or
>> IPSEC be used when using the protocol.
> This is a very good point, thanks.
>> PS. + $0.02 :) The Etag issue, this, and a recent
>> iCalendar issue seem to stem from CalDAV not
>> 'looking the other way' on deficiencies in
>> HTTP and iCalendar.
>> This is commendable, but by doing this it forces
>> developers to investigate and modify components
>> that they otherwise would have been able to
>> utilize as 'black box' components.
>> For example, clients who would simply call a HTTP
>> stack with a url, username and password will now
>> have to check the type of authorization is being
>> used and fail that connection if auth is basic.
>> Not to mention relay that to the user in a way
>> that is useful to them. This is compounded by the
>> fact that the authorization layer may not be in
>> the developers control. Eg. The client application
>> already supports WebDAV or some other HTTP protocol
>> and the CalDAV component or layer simply calls that
>> function with a simplified API interface.
>> My point is maybe we should avoid conflicting with
>> lower level protocols if at all possible, for the
>> sake of adoption?
> A pragmatic approach, yes. Philosophically I tend to agree with
> you (there are too many cases to list, where we simply went with
> what the underlying protocols provided, as that was our first
> choice usually), but there are always a couple exceptions. The
> ETag ambiguity simply interfered too much with interoperability and
> reliable synching. And the secured transport (when using plain-
> text passwords) is not only a good idea, it's important to get
> CalDAV approved.
More information about the Ietf-caldav