Hi Russ,
Thank you for an impressively elaborate reply.
On 2012-09-04 19:09, Russ Allbery wrote:
Peter Mogensen <[email protected]> writes:
Correct. Note that the mod_webauth implementation will never do this,
however; mod_webauth implements an authentication scheme wherein all
authentication credential lifetimes are bounded by the lifetime of the
original TGT, and nothing will outlive the original TGT lifetime. (This
is intentional; I consider it an important feature.)
But still... if you issue service tickets with a shorter life time than
the TGT and store them in the app-token, they might need to be renewed,
which require the webkdc-proxy-token. By either a redirect to the WebKDC
or a mehanism similar to the proxy-token (just not issuing delegated
credentials, but renewing the service-ticket).
Right, because in the Kerberos authentication model that ticket belongs to
the user, not to the server.
Well.. strictly speaking it belongs to the Weblogin service, since each
time it receives it, it can act as the user.
If the server could arbitrarily extend its
lifetime without requiring the user to be present, then Kerberos ticket
lifetimes would be meaningless for S4U2proxy, which would be a significant
security flaw. You would lose central control of those tickets; any
server to which a user has ever authenticated would be able to use
S4U2proxy for that user forever.
Sure... using S4U2proxy one should avoid giving the server control over
when the service ticket to itself is valid.
Sure, but that's true of all Kerberos authentications. If the user goes
idle, then the session is going to expire. I consider this a feature, not
a bug; idle sessions are possibly stolen sessions, particularly in the web
world.
Yes, ... but having no externally issued auth data in its session cookie
a web-application can normally relative costless renew a session cookie
on any activity and ensure expiry only after a certain amount of idle
time. What I'm looking for is a way to do that, which (I realize) might
be impossible.
If the session contains something important over which expiry the
application has no control (like a Kerberos service ticket) without
constantly involving the WebKDC in a costly renewal process this can't
be done.
But I guess that's a trade-off one have to make.
Honestly, my gut reaction here is "your application design is flawed" if
you expect to be able to do constrained delegation for users, without
requiring the user reauthenticate, when the user has been idle past the
boundary of a TGT expiration.
Sure... but it might be impossible to the user to predict the length of
tolerated idle time if even short idle time starting just before the TGT
expiry can result in session termination.
I know it's wishful thinking on my part, but I guess most users would
think of it as a better user experience, if timeouts were only dependent
on how long time you were idle and not when you were idle.
All that said, there is a feature on the WebAuth roadmap that I think may
address this problem sufficiently that it would minimize the problem
you're worried about:
* WEBAUTH-49: Provide a way to force reauthentication of a user who has
valid credentials but ones that are about to expire, and apply it only
to GET requests and not POST requests. This would be useful for wikis,
for example, where expired credentials will usually destroy whatever
work the user is trying to save.
Partly.
I think it's a good idea, but wouldn't that only work if you are GET'ing
a HTML doc? ... it wouldn't work for AJAX applications only making
request for data.
...and the redirect would make you loose any javascript state, so you
would have to think about when to do it and serialize everything
important into the applications state.
Also, considering the WebAUTH protocol support for credential delegation
by using proxy tokens I was wondering if that could be replaced by
S4U2proxy support on the Kerberos level - thus making it the same
mechanism used to delegate throughout the Kerberos infrastructure.
Yes. S4U2proxy is very new, much newer than the WebAuth protocol itself,
so WebAuth was not designed with it in mind. But you could indeed replace
the whole proxy/cred token system with S4U2proxy, provided that your KDC
had good enough ACLs on that capability.
You would lose a UI feature that WebAuth currently has, where the WebLogin
server warns the user what credentials the WAS will be able to obtain on
their behalf, but you could re-add that by adding some sort of API for the
WebLogin server to query the KDC-side ACL.
Loosing that feature might be OK in a lot of scenarios where the user
don't even know that there's a speciel backend server involved.
... which it seems is exactly what MS describes in MS-SFU as a feature
of S4U.
One thing I don't understand about S4U is that S4U2self has no option
for the service to actually prove that it is in session with an
authenticated user.
The fact that S4U2self with PA-FOR-USER allows a service just to demand
a ticket makes it unsafe to combine with S4U2proxy. That would allow any
service with access to both these protocols to get credentials to others
services at any time.
I could imagine a useful PA-DATA for S4U2self, which required a service
to prove that it actually had a session with someone knowing the
password. For example:
1) The user requests a resource unauthenticated.
2) Before returning 401, the webserver requests a nonce from the KDC
3) The KDC returns a nonce together with a timestamped and signed hash
of the nonce (to verify that it actually issued that nonce)
4) The webserver returns 401 with WWW-Authenticate: Digest using the
nonce a challenge.
5) The browser performs the Digest and re-issues the request, providing
the webserver with a proof that it currently has session with some one
knowing the password.
6) The webserver issues a S4U2self request with pa-data containing the
nonce, the signed version, and the digest proof.
Wouldn't that make S4U2proxy safe together with S4U2self ?
/Peter
