[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Protocol Authentication (was Re: Collection convergence?)


Robert Sayre wrote:

...
John Panzer wrote:

Robert Sayre wrote:


* authentication
  obvious editorial issue. This section is over-specified and already
  being flaunted. Out it goes. Point to CGI auth? Sure. Someone write
  it.


How is it being flaunted? Would be helpful to know.

Blogger supports BASIC over SSL only. Were MSN Spaces to support the protocol (hahaha), they wouldn't be able to either because they use passport.com sign-ons with expiring tickets. Beyond that, you'll start seeing sites using cookies (I'm shocked, just shocked) after the initial exchange, because it's much cheaper on the CPU and DB. There are many DAV implementations that do this now.

Note that the draft spec doesn't prohibit doing any of this. It just says that you also have to support Digest Auth, whatever else you do. I'm not sure whether Blogger intends to support the spec once it's finalized; adding Digest to BASIC auth would be pretty easy. Has anyone asked Jason Shellen? (CCd).

On a side note, I think that endpoints starting with "https://"; are allowed, right? So doesn't the draft spec already allow servers to specify whether they want their PostURIs to be SSL or non-SSL? (And doesn't this already present an issue for MIDP 1.0 phones that don't support SSL?)

Finally: I don't believe the group seriously considered BASIC auth over SSL originally. I haven't been able to figure out why; I haven't been able to see any security problems with it. Perhaps we should adopt Blogger's approach in the spec ('running code' and all that). Then Blogger would be following the draft spec.


I believe we do need a "greatest common denominator" authentication specification for interoperability, but could be convinced otherwise.


I wish we could do that, but we can't, IMHO.

OK, that's your opinion; my opinion is the opposite. You've presented one case (Blogger) that's using something almost compliant with the draft spec, and mentioned a few hypothetical clients that you think won't follow the spec. I'm still not convinced. Maybe I'm an incurable optimist.

The "CGI Authentication" scheme is a way to work around 'features' of Apache which prevent use of HTTP BASIC or Digest Auth on the server side. Seems to me this is exactly why the RFC "SHOULD" was invented. If a server can use a standard HTTP auth scheme, I don't see why it should need to support "CGI Authentication" as well. So I think we actually have different requirements for servers and clients. Here's some proposed wording:

===============
An Atom server SHOULD support HTTP Digest[1] Auth. In situations where this is not feasible, a server SHOULD support "CGI Authentication".[2]
An Atom client MUST support the standard WWW-Authenticate: challenge and authentication protocols for both HTTP Digest[1] and "CGI Authentication".[3]
Note that other authentication schemes are allowed if both client and server support them.[4]
===============

[1] Or, alternatively, HTTP BASIC over SSL using an https:// URI.
[2] Note that if neither is feasible, I agree we should give up on auth compatibility.
[3] This would end up hosing MIDP 1.0 cell phone clients assuming we allow https:// URIs. My opinion: Sorry; use a proxy or upgrade your phone. We don't support gopher client libraries either.
[4] For example, AOL will use Kerberos tickets as well, so a client presenting a valid ticket won't be challenged.

Let me give some examples. A client thinks it's talking to a server that accepts Kerberos tickets, so it passes one in its request via a nonstandard header. However, the server is not actually looking for that header (the client is misconfigured or the server switched its software or whatever). So, the server challenges the client using WWW-Authenticate and one of the two standard profiles. The client sees the challenge and has to ask the user for their username and password or pull it from a local store -- not the best situation, but much, much better than leaving the user staring at a "403 forbidden error" dialog.

On the other hand, a server which houses highly secure content, and a much more stringent need for security (the CIA's blog server, for example) may decide that neither standard auth scheme is sufficient and require a custom scheme. That's fine; they SHOULD support the schemes but they can't due to external constraints. So off the shelf clients won't work with the CIA's blog server, but they can easily customize a client to interface with their brainwave scanner authenticator hardware.

A client which wants to offer alternative authentication (e.g., a fingerprint scanner) can do so, but if it encounters a standard Atom server it's required to let a user enter a username/password combination as a fallback.

And now, for some quick takes:


Every client will have a large switch statement in their auth code.

Urk.

"CGI authentication" is the WSSE-based authentication[0] used in many draft-gregorio-09 implementations. Should the nonce be base64-encoded when appearing in a header? Only you can decide.

It needs a better name for discussion purposes, IMHO (UsernameToken?). Seems to me that the base64-encoding issue has been decided; if they have other issues, perhaps they should be raised on the protocol group.

-John