Augmented PAKE + discharge?

[Judson Lester]

The idea I've been entertaining is to have a browser-local discharging service, where the discharging reference provided by the server is essentially the server's first exchange in a PAKE protocol.

I'm not sure how reasonable this approach is, because all the AugPAKE schemes I've been able to find assume that the exchange is client initiated, and I'm beginning to understand the math behind that. It almost seems like the actual password holder in any AugPAKE (i.e. the client) has to initiate, or else a wealth of easy dictionary attacks become possible.

At the same time, once I started to consider it, it seemed really obvious and worthwhile, so I'm assuming I'm not the only one to have considered the possibility. Is there any existing work along these lines that I haven't been able to find?

Judson 

[Tony Arcieri]

On Mon, Dec 14, 2015 at 11:18 AM, Judson Lester <nya...@gmail.com> wrote:

The idea I've been entertaining is to have a browser-local discharging service, where the discharging reference provided by the server is essentially the server's first exchange in a PAKE protocol.

Can you briefly describe the user experience you're going for with this? It sounds like it's useful if you want to periodically prompt for a password (perhaps for privileged actions) without keeping state about the password server-side (e.g. w\ SPAKE2+). Is that your intended use case? 

--

Tony Arcieri

[Evan Cordell]

I'm not as familiar with PAKE, but from your description I think a small proof-of-concept project that I wrote a while ago could fit the bill with some minor changes. It uses a local iframe to refresh credentials.

I intend to look at the various PAKE schemes when I have some time to see if any fits well, but for now here's a link to the project: https://github.com/ecordell/macaroon-session-example/blob/master/README.md

--
You received this message because you are subscribed to the Google Groups "Macaroons" group.
To unsubscribe from this group and stop receiving emails from it, send an email to macaroons+...@googlegroups.com.
To post to this group, send email to maca...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/macaroons/CAHOTMV%2BEUx-ZVgXXxb0%3DoB3zLF_9z3epc-gBKM0e7duKLrd%2B3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Judson Lester]

I was roughly imaging something like Evan Cordell's demo (which he helpfully linked to: https://github.com/ecordell/macaroon-session-example/blob/master/README.md), in the context of a web application.

Basically, (assuming SRP) I imagine that the user "log in" process would be fairly usual; the iframe would capture the username and password, and make the username and the initial client side component of the SRP exchange available to the main application.

The application would request macaroons with the username/srp pair, and the server would return a macaroon that required a discharge, identified with the server's part of the SRP exchange. The app would hand that to the iframe for discharge, which would discharge in short expiration using the SRP session key. To maintain the session, the web app would continue to request discharges on new requests from the local iframe.

I'm concerned somewhat by the fact that this omits the final proof of key steps, which would make the exchange vulnerable to someone masquerading as the server; if it's conducted over TLS, though, that seems like it might be mere handwringing, and if it's not, I don't know that it's that much of a win.

Alternatives to SRP all seem to require more exchanges in the protocol - which I suppose could be accomplished with a kind of mutual discharge solution (I imagine the client application as Sam Lowry in Brazil, going from desk to desk to get the appropriate stamps on his documents), which might also nicely incorporate various timeouts to the session: the server's discharge would limit the overall session, local discharge would limit the current macaroon.

Judson

[Evan Cordell]

I've started to work on something very similar to this, so I thought I'd update. (Did you keep going with this idea?)

I'm working on an implementation in which the server returns a macaroon with a third party caveat that can be locally discharged. The caveat key/discharge key will be agreed upon through SRP so that the user can discharge the third-party caveat by entering their credentials locally. That discharge macaroon would have another "freshness" third-party caveat that can also be locally discharged (but no SRP needed) to logout a user due to inactivity. 

I'm concerned somewhat by the fact that this omits the final proof of key steps, which would make the exchange vulnerable to someone masquerading as the server; if it's conducted over TLS, though, that seems like it might be mere handwringing, and if it's not, I don't know that it's that much of a win.

I hesitate to answer without a true analysis, but I believe the macaroon verification step will serve as a proof of key step. The SRP-agreed shared secret "caveat key" is encrypted in the verification id of the third party caveat, so if the keys don't match the macaroon tree verification will fail.

[Tony Arcieri]

On Tue, Jan 19, 2016 at 3:05 PM, Evan Cordell <cordel...@gmail.com> wrote:

I'm working on an implementation in which the server returns a macaroon with a third party caveat that can be locally discharged. The caveat key/discharge key will be agreed upon through SRP

As a general recommendation: don't use SRP. *Secure* implementations are difficult to find for various languages, and it's very side-channel prone.

You can get the same properties of SRP out of SPAKE2+ without the side-channels. The interoperable implementation problem still exists, but could be easily solved if e.g. libsodium (which all Macaroons libraries are all using) provided the proper APIs for things like scalar multiplication and point addition of Ed25519 group elements (which is something I've wanted to work on but haven't).

Also consider checking out SPAKE2 "Elligator edition": https://moderncrypto.org/mail-archive/curves/2015/000424.html

--

Tony Arcieri

[Tony Arcieri]

Also I guess your "local discharge service" is using JavaScript to do all this stuff, so never mind, all security guarantees are already lost ;)

--

Tony Arcieri

[Evan Cordell]

I appreciate the feedback. SPAKE2+ looks excellent, even if there's a dearth of implementations.

SRP (or really any key exchange) seemed like a nice alternative way to agree on a shared key for third-party caveats. I saw it as an opportunity to remove a round-trip. I should also have specified that all of this is over a TLS connection in the first place.

The desired behavior is: a user must re-authenticate with their credentials once every x minutes, but if they're inactive after y ( < x) minutes their session should expire. The latter part is easily achieved with a local discharge (no SRP).

Throwing some form of PAKE in there lets you remove the round trip to the server for the re-authentication step. There isn't really that much of a benefit over simply giving the caveat key to the client directly, since we're talking about an existing TLS connection. I suppose if the TLS session were compromised it might be helpful.

I've actually soured on the whole idea since yesterday, and am leaning toward simply issuing another request to the server to reauthenticate. I liked the idea of distributing the load out to users but I think it comes at the cost of too much complexity. There isn't actually a way to make this secure without issuing a new request to the server on each re-authentication, and at that point you may as well just send the actual credentials. My original suggestion without modification is also susceptible to a simple session extension. 

I think this is also the conclusion to Judson's original ideas:

> The app would hand that to the iframe for discharge, which would discharge in short expiration using the SRP session key. To maintain the session, the web app would continue to request discharges on new requests from the local iframe.

Basically, if the iframe has the information necessary to create a discharge, you probably don't want to use that discharge as an authentication proof. If you just want a freshness proof, though, there are much simpler ways (namely my toy session expiration example on github).