Hi Adrien,
On Sun, Feb 26, 2012 at 02:54:01PM +1300, Adrien de Croy wrote:
I wonder if it would be helpful for people to outline what they expect
are the issues to be solved by doing more work on an HTTP auth mechanism.
I get the feeling that some think the scope would encompass providing
auth support for web applications, whereas others are mainly concerned
with the transport level auth.
I am personally concerned with the risk that new auth schemes continue
to mix messages and transport. I don't think we need to define these new
schemes, we just need to ensure the new protocol offers provision for
doing the things right. I'd like to ensure we never get a new NTLM-like
design error which forces every implementation to break the HTTP model
to try to be compatible.
Also, (that's not directly related to auth) it would be nice if we could
have a random session ID in messages that browsers would send to help the
whole intermediary chain select the appropriate server. A simple hash on
this session ID would make load balancing much easier and much more reliable
than any other algorithm right now and would definitely help when challenge
based auth schemes are needed.
(...)
If we're just talking about transport auth, then what's wrong with
something like kerberos. As for server logging a client out, the auth
mechanism would need a token that can be revoked by the server, since
one cannot rely on client co-operation in such a matter. A kerberos
ticket seems to fit this bill. then we'd just need a mechanism for a
client to request revokation (logout). It is also AFAIK supported on
all server platforms, unlike any auth mechanism that requires access to
plaintext passwords at the server end - these are not always available.
It is comparable to what is already done with cookies in most applications
(ie I have nothing against this). We just have to keep in mind that auth
methods will change with time. Many applications right now expect two-factor
auth and/or some complex UI adaptations to protect against malware. That's
why I think that our work on supporting auth should mainly ensure we offer
the solid blocks for building new auth schemes and don't necessarily need
to define these schemes ourselves.
Regards,
Willy
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf