[Ietf-http-auth] [comments on caldav security and HTTP
RL 'Bob' Morgan
rlmorgan at washington.edu
Thu Sep 29 23:59:47 PDT 2005
A brief writeup introducing the problem, in the caldav context.
- RL "Bob"
---------- Forwarded message ----------
Date: Wed, 14 Sep 2005 13:20:42 -0700 (PDT)
From: RL 'Bob' Morgan <rlmorgan at washington.edu>
To: CalConnect TC-CALDAV <tc-caldav-l at calconnect.org>
Subject: comments on caldav security
Some quick notes on the security-related topics I've been complaining to people
about for a while now. Let me emphasize that my interest here is not in any
way to derail Caldav, rather to point out problems that inhibit affect its
adoption and see whether there are solutions.
One of the things that some of us liked best about the late CAP proposal was
that it was based on BEEP, not because of BEEP per se but because BEEP in turn
incorporated what I (and others) have called the standard IETF
application-protocol security framework. This consists of a STARTTLS command
to negotiate in-band the use of TLS security; and a SASL profile to provide the
ability to use any of the security mechanisms (primarily for authentication but
also for optional datastream protection in some cases) defined for use with
SASL. This includes various challenge-response mechanisms, GSS/Kerberos,
public-key-based GSS mechanisms, and other potential future mechanisms.
Caldav of course relies on webdav which relies on HTTP. HTTP does not make use
of the STARTTLS/SASL framework. HTTP's primitive security has only been
tolerable, given its extremely wide deployment, because an extensive set of
workarounds have been developed, almost all of which depend on classic browser
features and hence are not generally applicable to webdav or webdav-based
HTTP over TLS/SSL is of course widely used. The inability to negotiate the use
of TLS in the protocol is mitigated by the ability of servers to redirect
browsers to rewritten URLs with or without the "s". This of course isn't
really negotiation since the browser isn't an active participant.
For authentication, HTTP includes only Basic and Digest. In practice,
especially in institutional settings, these are rarely used. Instead deployers
most commonly rely on form-based authentication (using username/password) and
cookie-based session maintenance. The authenticated web-based app you used
today almost certainly used this approach.
In more scalable enterprise settings schemes are used that leverage one
form-based authentication service (aka "weblogin") to serve the needs of many
web-based apps, via redirection, cookies, URL parameters, form POSTs, etc;
still ultimately relying on cookie-based session maintenance at the webapp
after authentication (and of course TLS/SSL underneath all connections). This
approach has been standardized in the OASIS Security Assertion Markup Language
(SAML), and its web browser signon profile, which has been widely implemented
in commercial and open-source packages, and is being widely deployed. These
approaches are at the very heart of "enterprise authentication" for many large
Webdav agents (about which I am not an expert) traditionally have had spotty
support at best for many of the http-user-agent features that these signon
systems require: TLS/SSL, redirection, cookies, etc. And of course form-based
authentication probably doesn't make sense at all to a webdav agent (though
this isn't necessarily a showstopper).
So this is a fundamental problem. If Caldav continues to defer to vanilla HTTP
for its security features, and yet is not able to take advantage of the
techniques that make HTTP-based applications compatible with enterprise
security, this will definitely limit its deployment (my institution has held
off on large-scale webdav deployment for these reasons).
The requirements I'm claiming here haven't been written up as use cases to my
knowledge, this should be done. A protocol/UI-level question is the role of
login/logout in Caldav, which might be considered independently of the
mechanisms needed to do it.
An approach that goes back to the start and tries to extend HTTP security to
support modern requirements directly (rather than via what are essentially
tricks) would be the right thing, but would obviously be a very big deal. We
might (assuming these requirements are to be addressed) consider whether
Caldav-level protocol features would be appropriate.
- RL "Bob"
More information about the Ietf-http-auth