Re: Please review: http gss authentication mech

[Leif Johansson <leifj at it.su.se>]

Lisa Dusseault wrote:
> 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. 
Noted.
>
> 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.
>
The intent is only to use RFC4559 as a non-normative reference. The
specification shouldn't contain any
normative references on RFC4559 but I would like to include the
non-normative reference both as help
for implementors and to explain what the historical basis for this
specification is.
> 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.
That will certainly increase readability.
> - 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 have gotten similar feedback from other reviewers too.
>  
> - 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 :)
I was looking for a better way to write this. This sounds like a win and
I don't think it is very un-GSS at all.
> - 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...").
>
That may be more difficult. In practice there are few situations where
more than (say) 5 roundtrips are
ever needed and in many cases 1 or 2 are enough but in general GSS have
few hard limits. The same
question came up during the discussion of GSS-TLS on friday. I don't
have a good answer to this at
this time.
> 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?
If I understand these questions correctly I believe they will be
alleviated by following Cyrus Daboos suggestion to
use the attribute=value-pair ABNF which RFC4559 decided not to use for
some reason. I.e "GSS challenge=<> "
instead of "GSS <>".
> - 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).
How does a client ever know that?
> - What method would the empty Authorization header go on? Any? Only
> GET? MUST the server handle it or can it ignore?

Again I wonder if this problem goes away with better ABNF...

       Cheers Leif

_______________________________________________
Kitten mailing list
Kitten at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten