Subject: [calsify] Client "Bootstrapping" Procedures for CalDAV/CardDAV for passwordless access

From: Dilyan Palauzov <[email-masked]>
Date: Sat, 18 Aug 2018 23:37:52 +0000

Hello,

RFC6764 "Locating Services for Calendaring Extensions to WebDAV  
(CalDAV) and vCard Extensions to WebDAV (CardDAV)", Section 6.  Client  
"Bootstrapping" Procedures suggests asking the user for minimal amount  
of data - email address or URL and a password, to complete the  
configuration.

RFC 4918 "HTTP Extensions for Web Distributed Authoring and Versioning  
(WebDAV)" - Appendix E.  Guidance for Clients Desiring to Authenticate  
says:

    Thus, the WebDAV client would be able to authenticate
    with its first couple requests to the server, provided it had a way
    to get the authentication challenge from the server with realm name,
    nonce, and other challenge information.  Note that the results of
    some requests might vary according to whether or not the client is
    authenticated -- a PROPFIND might return more visible resources if
    the client is authenticated, yet not fail if the client is anonymous. [...]

My understanding is, that a CalDAV server can offer public and private  
calendars.  When users authenticate, they see the own, internal and  
public calendars, but if they don't authenticate (=anybody on the  
globe) can see the public calendar.  In particular, for the same  
requests the server can return different answers, depending on whether  
the user is authenticated, but never return 401 to force user  
authentication.

How shall the bootstraping work for public calendars?  Entering  
anonomous@domain with any password would work, but this is unnecessary  
complicated and any user using this mechanism would ask herself how  
can be software engineers so stupid to require users to enter useless  
information.

What about closing the gap by writing one more bootstraping scenario:
* for a CalDAV server:
   (modify first bullet, by inserting *possibly*; inject more bullets)
           +  Minimal input from a user would consist of a calendar user
              address and possibly a password.  A calendar user  
address is defined
              by iCalendar [RFC5545] to be a URI [RFC3986].  Provided a
              user identifier and a domain name can be extracted from the
              URI, this simple "bootstrapping" configuration can be done.

        + When no password is provided by the user, the client shall  
assume that the server offers anonymous access and should try the  
bootraping without a password, before forcing the user to enter one on  
401 Unauthenticated response
        + When password is provided by the user, the client must send  
WWW-Authenticate when obtaining the DAV:current-user-principal and all  
subsequent reqeusts, even if the server has not returned 401  
Unauthenticated

The explicit "password" is a little bit funny, as the client can use  
WWW-Authenticate: Negotiate/GSSAPI-SPNEGO/KerberosV without any  
password, but I cannot think on a better wording.

Greetings
   Дилян

---

From: Michael Douglass <[email-masked]>
Date: Sat, 18 Aug 2018 21:55:41 -0400

> can be software engineers so stupid to require users to enter useless 
Bedework offers authenticated and unauthenticated CalDAV. 
Unauthenticated is actually not part of the spec as the spec mandates 
basic auth. Most other forms of auth don't work with CalDAV (as specified).

For basic auth it's quite easy. Put authenticated on one context and 
unauth on another. Then the server can challenge on the first request to 
the authenticated context. Never chanllenge on the unauth.
>              address and possibly a password.  A calendar user address 
> is defined
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Dilyan Palauzov <[email-masked]>
Date: Sun, 19 Aug 2018 03:09:18 +0000

Hello Michael,

where precisely is HTTP Basic Authentication required for  
CalDAV/CardDAV and what is the purpose of this requirement?

https://tools.ietf.org/html/rfc4918#section-20.1  [WebDAV core RFC]  
requires support for Digest authentication, permitting other  
authentications, but appendix E states
    Note that the results of
    some requests might vary according to whether or not the client is
    authenticated -- a PROPFIND might return more visible resources if
    the client is authenticated, yet not fail if the client is anonymous.

so WebDAV does not require authentication.

In RFC4791 CalDAV I cannot find such requirements, too.

What do you mean by putting authenticated and unauthenticated  
resources in different context?  Do you suggest to use different  
domains, which allow the bootstrapping process to find different URLs?  
  This will help with clients which send passwords only after  
receiving 401, but will not help with clients which insist on having a  
password before performing the bootstrapping.

https://tools.ietf.org/html/rfc6352#section-9.3 [CardDAV, Client  
Configuration] adds:
    Given support for SRV records (Section 11) and DAV:current-user-
    principal-URL [RFC5397], users only need enter a user identifier,
    host name, and password to configure their client.  The client would
    take the host name and do an SRV lookup to locate the CardDAV server,
    then execute an authenticated PROPFIND on the root/resource looking
    for the DAV:current-user-principal-URL property.

So clients waiting for 401 before authenticating on performing this  
PROPFIND are indeed formally wrong.

But are CalDAV/CardDAV clients required to authenticate on purpose,  
was this an oversight, not to state clearer that unauthenticated  
accesses is bad idea, and what what speaks against clarifying this now?

Greetings
   Дилян

----- Message from Michael Douglass <[email-masked]> ---------
    Date: Sat, 18 Aug 2018 21:55:41 -0400
    From: Michael Douglass <[email-masked]>
Subject: Re: [calsify] Client "Bootstrapping" Procedures for  
CalDAV/CardDAV for passwordless access
      To: [email-masked]

>> (CalDAV) and vCard Extensions to WebDAV (CardDAV)", Section 6.  
>> Client "Bootstrapping" Procedures suggests asking the user for  
>> minimal amount of data - email address or URL and a password, to  
>> complete the configuration.
>>
>> RFC 4918 "HTTP Extensions for Web Distributed Authoring and  
>> Versioning (WebDAV)" - Appendix E.  Guidance for Clients Desiring  
>> to Authenticate says:
>>
>> My understanding is, that a CalDAV server can offer public and  
>> private calendars.  When users authenticate, they see the own,  
>> internal and public calendars, but if they don't authenticate  
>> (=anybody on the globe) can see the public calendar.  In  
>> particular, for the same requests the server can return different  
>> answers, depending on whether the user is authenticated, but never  
>> return 401 to force user authentication.
>>
>> anonomous@domain with any password would work, but this is  
>> unnecessary complicated and any user using this mechanism would ask  
>> herself how can be software engineers so stupid to require users to  
>> enter useless information.
> Unauthenticated is actually not part of the spec as the spec  
> mandates basic auth. Most other forms of auth don't work with CalDAV  
> (as specified).
>
> unauth on another. Then the server can challenge on the first  
> request to the authenticated context. Never chanllenge on the unauth.
>>
>> bootraping without a password, before forcing the user to enter one  
>> on 401 Unauthenticated response
>>        + When password is provided by the user, the client must  
>> send WWW-Authenticate when obtaining the DAV:current-user-principal  
>> and all subsequent reqeusts, even if the server has not returned  
>> 401 Unauthenticated
>>
>> The explicit "password" is a little bit funny, as the client can  
>> use WWW-Authenticate: Negotiate/GSSAPI-SPNEGO/KerberosV without any  

----- End message from Michael Douglass <[email-masked]> -----