Re: security requirements (was: Updating RFC 2617 (HTTP Digest) to use UTF-8)

   If I may add a data point, the recently approved CalDAV states  
that a server MUST NOT implement Basic Auth or similar without SSL or  
similar.

   Personally, I think that sort of MUST NOT requirement is bogus,  
and fully intend to ignore it.  More specifically, I do no intend to  
disallow a server admin from configuring the server to allow Basic.   
My server's written in Python, and bypassing any such constraints  
would be trivial in any case.

   There will be zero CalDAV-compliant clients which will fail to  
interoperate with my server as a result of this, so as a practical  
matter, I have no incentive to comply with this requirement.

   It certainly won't be enabled by default, nor would I encourage  
such a config in a production environment, and I wouldn't put it in  
an admin UI.  But if a server admin decides that making Basic work is  
useful, then I'm not getting in the way.  I, for example, use it for  
testing, since SSL is a bit of a bother when using tcpflow.

   For what it's worth, as a client author I'd have a somewhat  
different viewpoint here.  But as a server author, SHOULD NOT makes  
plenty of sense, and MUST NOT strikes me as hard to justify.

	-wsv



On Oct 18, 2006, at 3:19 AM, Henrik Nordstrom wrote:

> ons 2006-10-18 klockan 09:24 +0000 skrev Ingo Struck:
>
>
>> A formulation within an updated http/1.1 document could be
>> that a conforming server implementation MUST NOT use the
>> Basic auth scheme (or equally weak schemes), while clients
>> MAY support it, but if they do they MUST warn the user
>> decidedly -- if this seems to be too restrictive a SHOULD NOT
>> could still suffice.
>
> I would add "without adequate transport level security" to the above.
>
> Exchanges of plain-text passwords is often required for  
> interoperability
> reasons far beyond the HTTP protocol as such. In very many  
> applications
> the server simply MUST know the plain-text password of the user.
>
> The main reason why Digest auth hasn't been widely deployed and most
> still using Basic is because of these reasons. There is not very  
> much as
> such wrong with Digest auth even if there is areas which can be  
> improved
> (and many broken implementations), but in practice it's often  
> completely
> useless as the backend systems doesn't support Digest auth, only other
> proprietary authentication protocols or plain text.
>
> Quite recently there was a standardisation effort which have brought
> Digest auth a bit closer to something deployable by extending RADIUS
> with Digest auth support. Hopefully this will make Digest a more
> available alternative.
>
>
> Regards
> Henrik

Received on Thursday, 19 October 2006 00:09:54 UTC