[Ietf-http-auth] [comments on caldav security and HTTP authentication]

[RL 'Bob' Morgan]

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 
systems.

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 
organizations.

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"