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

[Michael Douglass <[e-mail]>]

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