On 20/3/09 08:32, Anders Rundgren wrote:
This is a stupid discussion.
Authentication schemes in general begin with authenticating the user.
How long the authentication should be considered as valid is
not something the client-end has anything to do with unless it
has gotten some kind of expiration data from the server.
An awful lot depends on what we mean by "authentication" ...
I'm not sure how one would come up with an expiry on authentication that
will please everyone. It seems that at the low end, we are talking a
few minutes, which seems to be a connection-oriented number.
At the high end, in the (new policy list), it is often mentioned that
the expiry on a cert should be limited to 2 years, and some certs are
issued for much longer.
Is there any difference between these "authentication" expiries?
It seems pretty clear that the real culprit is the TLS protocol itself.
:) and all the rest. After MITB surfaced (and scared the European
bankers into action) people in finance circles started to realise that
session authentication was a mistake from the beginning (and that SSL
was the vector for that mistake). Now they are heading towards
transaction authorisation, which by was what the customer wanted in the
first place. The favourite is to do something like a transaction-level
authentication over the mobile phone. If it goes its full path, we'll
eventually see authorisation of the transaction rather than
authentication of the individual, and then things will be safer.
TLS plays no part in that, or, you are right that the part it plays is
that of the culprit; distracting attention from the real security needs
by imposing its security model.
Fortunately a lot of people are working hard to establish schemes
that use the good part of TLS (server-auth) and leave the unwieldy
part to a community that won't be able fix it.
Getting back to the "cheap" end of the market, right, some of us are
still trying to extract value by getting TLS to the always-on and
dual-authentication status. Only then can it deliver real value up to
the application, rather than open up weaknesses in other areas. For
this, client certs seem to be useful, because the code is already
written in the server side.
But it looks like the real issue here is going to be filled out by
Johnathan's ideas for some more GUI control and the existing restart
being constrained by user-driven policy.
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
