[Sugar-devel] Auto-authentication for Browse -

[Martin Langhoff]

On Thu, Jan 22, 2009 at 12:39 PM, Simon Schampijer <simon at schampijer.de> wrote:
> ===Topics===
> c) Auto-authentication for Browse when visiting web-based tools on the
> XS it has registered to (guest speaker Martin Langhoff)

First, *apologies* for the no-show -- I got confused between 14hs UTC
and 14hs EST.

In terms of what to do with Browse.xo, I have a couple of rough ideas
to propose. It's a very tentative thing -- and I don't want or expect
to dictate the implementation. There's been a few discussions verbally
(at 1CC, and at SugarCamp),
plus quite a bit on the devel@ list. Might be worthwhile a re-read.

Here's my outline of opportunities and constraints as I understand
them

* We want seamless, magic auto-authentication for the XO when
visiting web-based tools on the XS it has registered to.

* We hope this to be low-impact on Browse.xo and 9.1 in general. It'd
be a big win if the feature works on 8.2 as well. It cannot hamper
using normal websites.

* It is better to avoid making it too OLPC-specific. XOs should be
able to interop with a XS or something roughly like it. (Later down
the path, perhaps more than one XSish server...)

* We'd like conventional browsers to able to use the same mechanism
(but I can add suitable fallbacks on the XS to support non-XO
users...)

* We hope this is low impact on the XS too. It cannot hamper other clients.

* The XO shares at 'registration' time its local and unique public
ssh key with the XS. We can use that bit of knowledge clearly and
without more infra changes.

* We can change the registration protocol to exchange more data, but
that will widen the impact of this change significantly.

* The general idea is to hook a special "in the background" handshake
when Browse.xo visits a server that looks like an XS. (But for
example, I don't know what hooks we have in there!). After that
handshake, which we'd like to be reasonably secure against
eavesdroppers and replay attacks, traffic falls back to plain http
with the client having an http cookie. Based on that general idea, two
approaches have been discussea

Plan A - HTTPS to the rescue

Use HTTPS and client certs. On the Browse.xo, either create a client
cert at first boot or derive one from the SSL priv key we already
have. Lacking a PKI ( in this case XSs will have self-signed certs,
and the whole network will often be offline), we will need to grab the
cert from the
XS at registration time so we can whitelist it for Browse.xo. This is
safer, allows us to upgrade later to always using HTTPS if desired.

It has downsides however
 - we'll have to change the registration protocol, and deal with
up/downwards compat issues.
 - https is significantly more costly in terms of CPU on the XS

Plan B - Secure handshake -> http cookie -  option

Assuming Browse.xo can get its grubby hands on
.sugar/default/owner.key (not sure how to negotiate that with Rainbow)
then it can perform a simple handshake with the XS over plain HTTP,
where the XS issues a challenge string that has to be signed by
Browse.xo with the private key. The XS, having the public key can
verify the signature. Once it has verified it, it gives Browse.xo a
traditional HTTP cookie.

This is cryptographically much weaker because

- It allows third parties to pose as an XS, and generally play MITM.
- After the handshake - the interaction continues over plain http. The
cookie may be set to short-lived, but within its lifetime it is
trivially sniffed and reused.

On the other hand, it allows us to just issue an updated Browse.xo
perhaps even for 8.2.

Plan C - Simple HTTP cookie

Bryan Berry mentioned this strategy at XOCamp: at Browse.xo startup
time create a 'fake' cookie in cookies.sqlite . We could use the
pubkey -- or a hash of it -- as a cookie. This is trivially MITM'able,
and trivially sniffable and reused. It cuts to the chase on plan B.

 - - - - -

Thoughts? Opinions? Code?

cheers,




m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff