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

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

Amendment:

I think the RFC6764 discovery is applicable both for unauthenticated
and authenticated access.  First the user agent asks for domain and
whether and how the user wants to auhtenticate, then does DNS
SRV/TXT/.well-known work.  If the credentials do not match, when the
user wants to authenticate, the server answers with 401
Unauthenticated.

If RFC 6764 in not suitable for discovering collections for
unauthenticated access, then what shall be the procedure to unveil
them?

On Fri, 2018-10-12 at 10:52 +0000, Дилян Палаузов wrote:
> Hello Michael,
> 
> WebDAV ACL (RFC 3744 5.5.1.  ACE Principal) defines
> <DAV:authenticated/> and <DAV:unauthenticated/> as disjoint sets.
> 
> If for an URL the <DAV:unauthenticated/> principal are granted some
> privileges, what shall be the behaviour of that URL for unauthenticated
> requests?
> 
> Exposing an alias of the URL under a slightly different namespace is an
> option, but for me the behaviour of the original URL is unclear.  The
> clients follow procedures to obtain an URL, possibly also its ACEs, the
> exact namespace of the URLs is meaningless for the clients.  With
> procedures I do not mean copying an address from a web page/newsletter,
> but RFC6764 Locating Services for Calendaring Extensions… -discovery.
> 
> On the other side in RFC 5397 WebDAV Current Principal Extension
> section 3.  DAV:current-user-principal is written:
> Value:  A single DAV:href or DAV:unauthenticated element.
> 
> Description:  The DAV:current-user-principal property contains either
>       a DAV:href or DAV:unauthenticated XML element.  The DAV:href
>       element contains a URL to a principal resource corresponding to
>       the currently authenticated user…  When authentication has not
>       been done or has failed, this property MUST contain the 
>       DAV:unauthenticated pseudo-principal.
> 
> Was it on purpose prohibiting for unauthenticated users to return a
> valid DAV:href, from which home-sets can be extracted?  A better
> wording would be: “… When authentication was required, but was not
> successful, this property MUST contain the DAV:unauthenticeted pseudo-
> principal”.
> 
> Speaking about WebDAV: with username and domain provided, a client
> (CUA) can get the DAV:current-user-principal and from it obtain 
> CARDDAV:addressbook-home-set and CALDAV:calendar-home-set.  Is there
> any standard way to retrieve WebDAV URLs for the principal, that are
> not CalDAV or CardDAV related and where the principal can manage files?
> 
> Greetings
>   Дилян
> 
> On Thu, 2018-10-11 at 23:41 -0400, Michael Douglass wrote:
> > I'm pretty much opposed to the mixing of authenticated and 
> > unauthenticated resources on any given context.
> > 
> > If the context /caldav/<anything> always challenges and the context 
> > /pubcaldav/<anything> never challenges there's not much confusion.
> > 
> > I think that was where I was heading anyway.
> > 
> > It might be worth considering flipping it and advertising a noauth 
> > option which will never require authentication
> > 
> > On 10/10/18 03:30, Дилян Палаузов wrote:
> > > 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
> 
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify