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
