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 > > >
