[calsify] draft-douglass-subscription-upgrade / Re: Client "Bootstrapping" Procedures for CalDAV/CardDAV for passwordless access

[Дилян Палаузов <[e-mail]>]

Hello,

the passwordless CalDAV access can be reflected also in 
https://tools.ietf.org/html/draft-douglass-subscription-upgrade-03 :

One CalDAV collection can be accessed in two ways: anonymously (without
login) and with login.  In the former case the client cannot make
modifications, in the latter the client probably can.

The use case is that any user can edit the ACLs of its own calendar and
can say that anybody can read it.

Should OPTIONS following draft-douglass-subscription-upgrade publish
Link: subscribe-caldav or Link: subscribe-caldav-auth for that
resource?

The current problem with the CalDAV clients is, that some of them
insist on having a username before making a request and others only
send the username, if they get 401.  For a calendar that can be
accessed in two modes, the server does not return 401 and the clients
are stuck.  The only thing a server can do is to send 401 when no user
name is provided and accept for a user “anonymous@domain” any password.

draft-douglass-subscription-upgrade doesn’t say that for Link:
subscribe-caldav when the server returns 401 the client shall retry
with user anonymous@domain and it shouldn’t.

My proposal is to remove subscribe-caldav-auth from the draft and ask
the user, whether she wants to authenticate for the CalDAV collection.

Greetings
  Дилян

On Sun, 2018-08-19 at 03:09 +0000, Dilyan Palauzov wrote:
> 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 <[e-mail]> ---------
>     Date: Sat, 18 Aug 2018 21:55:41 -0400
>     From: Michael Douglass <[e-mail]>
> Subject: Re: [calsify] Client "Bootstrapping" Procedures for  
> CalDAV/CardDAV for passwordless access
>       To: [e-mail]
> 
> 
> > On 8/18/18 19:37, Dilyan Palauzov wrote:
> > > 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.
> > 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.
> > > 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
> > >   Дилян
> > > 
> > > _______________________________________________
> > > calsify mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/calsify
> > 
> > _______________________________________________
> > calsify mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/calsify
> 
> ----- End message from Michael Douglass <[e-mail]> -----
> 
> 
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify