Subject: [http-auth] TLS-OBC: client software choosing session lifetime?

From: "Manger, James H" <[email-masked]>
Date: Fri, 2 Sep 2011 22:41:57 +1000

The ideas for stronger web authentication at browserauth.net look really interesting, such as Origin-Bound Certificates (TLS-OBC) [draft-balfanz-tls-obc].

TLS-OBC effectively adds a (per-account per-device) identifier to TLS that persists across TLS sessions. The identifier is the public key in the anonymous self-signed origin-bound client certificate. An authenticated user-id (held in, say, a cookie) can be bound to this identifier.

It all works... until the origin-bound certificate is replaced.

I am wondering whether OBC's being replaced at a time of the client software's choosing will cause problems (or at least annoyances). Today, services choose the lifetimes of the cookies they issue, and they can re-issue a replacement cookie if an existing one is about to expire. A service can certainly choose the cookie lifetime so it doesn't expire in the next hour, for instance. An OBC-bound cookie, in contrast, cannot (securely) outlive the OBC. However an OBC may have been created a month ago and be due for replacement in 2 minutes. That could cause a seemingly-arbitrary glitch in the user experience that the service is trying to offer.

Perhaps an OBC replacement will only occur when a TLS session cannot be resumed, which might generally imply a browser restart, which might be a big enough break to warrant a new user login?
Perhaps the draft spec's recommended OBC lifetime of between 1 month and 1 year is long enough so that an OBC expiring at an inconvenient instant will be rare enough to ignore?
Perhaps browsers can add heuristics to reduce OBC replacement occurring in the middle of something important (eg replace an OBC now if it expires in the next 48 hours and it hasn't been used in the last hour)?

--
James Manger