Re: PaceAuthentication (was Re: CGI Authentication)

[John Panzer]

I'm basically +1 on PaceBasicAuthentication too.  The only reason that PaceAuthentication proposed removing CGI auth is to try to force things to a conclusion -- CGI Auth has been in there forever, isn't in a usable state, and needs to be fixed or removed to an extension.  James M Snell wrote: Hey John, Overall I'm +1 on what PaceAuthentication is looking to do, but I think the PaceBasicAuthentication I just submitted today is a bit of a cleaner approach... mainly given that it's only a minimal change to the existing text. What I really want to see at this point, is a discussion of cgi auth. it's something that could be of significant benefit but really needs to be nailed down before we decide to strip it out the way PaceAuthentication does. - James John Panzer wrote: James M Snell wrote on 2/22/2006, 5:12 PM: > > With Bob [1] in mind, are we ever going to finish filling out the > details of the mysterious enigma that is CGI Authentication? > > [1] http://www.xml.com/pub/a/2003/12/17/dive.html A great question. If people are interested, perhaps we could debate PaceAuthentication? (The section numbers might have changed, if people are ready to talk about this I'd be happy to update them, but the issues in draft-08 are the same as in draft-04. Let me know.) Text: == Abstract == Modifies section 9 in draft-04 of the Atom Protocol to say "use HTTP Auth" in an interoperable way. == Status == Open == Rationale == Lack of agreement on authentication and security could easily cause interoperability problems between Atom clients and servers. Choosing a "minimal acceptable" approach allows for interop while not constraining clients and servers from using other approaches as well. There are problems with the existing section 3.7. Blogger has implemented HTTP Basic over TLS for their Atom server implementation, which technically violates the existing spec. Others have apparently voiced opposition to the section's requirements. Robert Sayre has proposed removing all authentication requirements completely from the protocol as a solution. This Pace proposes to reform the section instead in order to ensure at least minimal interoperability between clients and servers. It also brings Blogger into compliance with the draft specification by changing the specification. == Proposal == * Change section 9, Securing the Atom Protocol, to the following: {{{ 3.7 Securing the Atom Protocol Atom servers determine the appropriate level of security needed for protocol operations. Atom relies on standard HTTP authentication mechanisms for interoperability. Custom authentication and security mechanisms are also allowed, but are outside the scope of this document. Servers SHOULD support the HTTP Basic auth-scheme [RFC2617] for operations requiring authentication. Servers SHOULD use SSL/TLS [RFC2246] for such operations. Servers MAY support other auth-schemes, and MAY support schemes entirely outside the challenge-response framework of [RFC2617]. Clients SHOULD support the HTTP Basic auth-scheme for all operations. Clients MAY support other auth-schemes or schemes entirely outside the challenge-response framework of [RFC2617]. Clients SHOULD support SSL/TLS for operations whose endpoints specify it. There are cases where an authentication mechanism may not be required, such as a publicly editable Wiki, or when using the PostURI to post comments to a site that does not require authentication to create comments. }}} * Remove section 9.1, [@@TBD@@ CGI Authentication]. * Change section 10, Security Considerations: {{{ Because Atom is a publishing protocol, it is important that servers be able to ensure that only authorized users can create and edit entries. The default security for Atom is based on HTTP Basic Authentication over SSL/TLS. Any weaknesses in this combination will obviously affect the security of the Atom Publishing Protocol. HTTP Basic Authentication over non-SSL/TLS connections is highly insecure and is not recommended for general use with the Atom Publishing Protocol. @@TBD@@ Talk here about denial of service attacks using large XML files, or the billion laughs DTD attack. }}} == Impacts == Brings Blogger into compliance with specification. May prevent MIDP 1.0-based Atom clients from following the recommended authentication protocol (they do not support TLS). Note that MIDP 2.0 based clients are OK, and MIDP 1.0 based clients can use a proxy. Prevents "CGI" hosted servers such as Movable Type and Blosxom from following the recommendations, since they cannot implement either HTTP Basic or SSL/TLS. (An alternative is to keep this in the spec but reference an external RFC -- but there is no such RFC to reference right now.) == Notes == This makes security recommendations SHOULD rather than MUST to provide for edge cases. (An Atom client designed only to post unauthenticated comments would be an example.) This removes the option to use "CGI Authentication" because no one has provided a referenceable spec for that yet. Should this be provided, CGI Authentication could become another option for servers (servers SHOULD support either Basic Auth or CGI Auth), and clients SHOULD support both. I'd love to see such a proposal. Note that if this doesn't happen, the affected parties could still add it in as an extension. The new wording is close to the conclusion reached by the WebDAV WG: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0171.html == Author == JohnPanzer ---- CategoryProposals CategoryInterop CategoryApi