[Sugar-devel] Auto-authentication for Browse -

[Simon Schampijer]

Martin Langhoff wrote:
> 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,

I wonder if it would not be best to generate a cert per user when we 
authenticate the first time with the XS and add this then to the 
cert8.db in the profile. This works fine - rainbow wise - as we do this 
already for the OLPC - Root CA.

Does that sound like what you are looking for?

Cheers,
    Simon

PS: sorry for the ridiculous reply delay