Re: Please review: http gss authentication mech

I've done an early (not for nits) review of this draft.

Major architectural concern: I am not enough of a GSS expert to know if this mechanism offers enough information in each roundtrip for a server to be able to reconstruct who the request is from and where they are in the authentication process. The spec only mentions passing GSS tokens resulting from various API calls, and not how these tokens can be used to recover state, or what other state the server must store to put all this together, and how long the server must store that. For HTTP server farms and non-persistent connection scenarios, it's important to explain this stuff somewhere.

Major standardization concern: This work is based on an Informational RFC, yet it's marked as intended for Standard Track. I am dubious about a variance for a downref for RFC4559, for various reasons we can discuss if it's not obvious or others disagree.

Other work todo on this spec, besides the todos already mentioned in the spec:

- Add a swimlane diagram showing client requests and server responses and what GSS stuff goes in each.

- Much more discussion and spec text necessary on the "client initiates authentication feature". Although I would like to see this feature become a standard, it's not actually tied to GSS, and I think this feature could not easily go to Proposed Standard unless it met with solid approval from HTTP implementors. There are many details still unspecified (some questions at bottom of this email, not guaranteed to be a complete list of issues).

- I'd personally prefer MUST-language that does not say that the client or server "MUST call gss_foo_bar". Instead, the requirements could be that the client or server MUST use the token that would result from a call to gss_foo_bar. This may be an un-GSS way of doing things :)

- Explain the limits on the number of roundtrips (current spec text says "This process continues until either an error occurs or the GSS-API layer has successfully completed...").

Lisa

Open questions on client initiating HTTP Authentication

- How does the client know it may send an empty Authorization header -- what if it tries this with a server not supporting HTTP-GSS?

- May the server respond with any WWW-Authenticate value whatsoever or only HTTP-GSS?

- Can the server assume from the empty Authorization header that the client supports HTTP-GSS? What about assuming support other mechanisms?

- How would a GUI client (browser or rich client) know whether to present a "Login" button? Imagine a client browsing a publicly-readable archive in HTML or WebDAV -- with anonymous read requests, the may see all kinds of documents. Yet if the client can authenticate and get more permissions, the client might see new stuff (e.g. additional documents, links to edit documents, or with WebDAV see write permission available on ACL queries and know to enable "upload" and "change" UIs in response).

- What method would the empty Authorization header go on? Any? Only GET? MUST the server handle it or can it ignore?

On Nov 9, 2006, at 11:23 AM, Leif Johansson wrote:

At the informal bar-bof yesterday in San Diego it was decided that I should
send my drafts describing a new http gss authentication mechanism to
this list.
Other work todo on this spec, besides the todos already mentioned in the spec:
- Add a swimlane diagram showing client requests and server responses and what GSS stuff goes in each.
- Much more discussion and spec text necessary on the "client initiates authentication feature". Although I would like to see this feature become a standard, it's not actually tied to GSS, and I think this feature could not easily go to Proposed Standard unless it met with solid approval from HTTP implementors. There are many details still unspecified (some questions at bottom of this email, not guaranteed to be a complete list of issues).
- I'd personally prefer MUST-language that does not say that the client or server "MUST call gss_foo_bar". Instead, the requirements could be that the client or server MUST use the token that would result from a call to gss_foo_bar. This may be an un-GSS way of doing things :)
- Explain the limits on the number of roundtrips (current spec text says "This process continues until either an error occurs or the GSS-API layer has successfully completed...").

Lisa

Open questions on client initiating HTTP Authentication
- How does the client know it may send an empty Authorization header -- what if it tries this with a server not supporting HTTP-GSS?
- May the server respond with any WWW-Authenticate value whatsoever or only HTTP-GSS?
- Can the server assume from the empty Authorization header that the client supports HTTP-GSS? What about assuming support other mechanisms?
- How would a GUI client (browser or rich client) know whether to present a "Login" button? Imagine a client browsing a publicly-readable archive in HTML or WebDAV -- with anonymous read requests, the may see all kinds of documents. Yet if the client can authenticate and get more permissions, the client might see new stuff (e.g. additional documents, links to edit documents, or with WebDAV see write permission available on ACL queries and know to enable "upload" and "change" UIs in response).
- What method would the empty Authorization header go on? Any? Only GET? MUST the server handle it or can it ignore?

On Nov 9, 2006, at 11:23 AM, Leif Johansson wrote:

At the informal bar-bof yesterday in San Diego it was decided that I should
send my drafts describing a new http gss authentication mechanism to
this list.

Note that these drafts are not intended for inclusion in the kitten
charter at
this or any future time. They are only presented to this list for review
by gss
experts.

By way of background this draft (and the related draft describing channel
bindings for http+tls) describes a successor (but not update) to the
negotiate
http auth mech which hopes to solve some of the drawbacks of this
mechanism.
The orginal motivation for this work was requirements from the calcify
wg who
expressed the need for a better authentication mechanism (than plain
passwords)
for applications using http as a transport but not using a browser as a
client.

Please note that this is a 00 version and new versions with
modifications based
on discussions from yesterday are forthcoming.

http://www.ietf.org/internet-drafts/draft-johansson-http-gss-00.txt
http://www.ietf.org/internet-drafts/draft-johansson-http-tls-cb-00.txt

Cheers Leif

Re: Please review: http gss authentication mech

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.