Re: Please review: http gss authentication mech

On Mon, Nov 13, 2006 at 09:24:42PM +0100, Leif Johansson wrote:
> Lisa Dusseault wrote:
> > - 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.

Check out some of the other RFCs and I-Ds that do this (RFC2203,
RFC2222, RFC2228, RFC3645, RFC4462, draft-ietf-sasl-gssapi,
draft-ietf-sasl-gs2).

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

There is always a finite maximum number of round-trips.  There's no API
to inquire what that would be for a given GSS mechanism (or for all
available mechanisms), but a) we could provide such an API, b) such data
could be hardcoded as a last resort.

But, why is this needed?

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

It might know from: context, configuration, and/or, much more likely,
from application-level data sent by the server.

In the NFSv4 case, for example, the negotiation is at the application
layer (i.e., in NFSv4, not in RPC or RPCSEC_GSS), and the server may
want different mechanisms to be used for different subsets of its
filesystems.

WebDAV should probably follow that model.

And HTML too should follow it.  Meaning we need an element by which the
server can tell the client that "if the user clicks on this, then
authenticate using HTTP-GSS + channel binding to TLS."

Specification of all such app-layer bits are well beyond the scope of
Leif's I-Ds, and, in some cases (e.g., HTML), well beyond the scope of
the IETF.

Nico
-- 

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