Some notes: On Thu, Sep 16, 2010 at 11:55 AM, Mark Kovacevich <[email protected]> wrote: > 1. CAC enabled (Government Smart Card w/ Certificates): > 2. Army Knowledge Online (AKO) and Active Directory authentication:
These should be quite easy to implement. The planned authentication system has 2 parts: An authenticator, which provides the client with a signed token, and a verifier, which verifies the validity of the token. I'm looking at using an RSA key pair to generate & sign the tokens. The verifier will be bolted deeply in fedone. For this, what we need is multiple authenticator implementations. Each implementation needs a copy of the signing key, and a way to talk to the client (to authenticate it, and if its authenticated give it a token). The first implementation of that will be a simple password check. I don't know anything about LDAP or smart cards. But it will be quite easy for someone who does know that stuff to hook it up. > 3. Usable with mobile clients (iPad, iPhone, Android) There are projects to make native clients for ipad, iphone and android. Others on this list will know more. > 4. Automated installation/ Operation on Windows and Linux Servers: The plan is for a totally hands-free installation that does everything except for federation. Federation will require a TLS certificate signed by a trusted party and an XMPP server (which could be bundled). We haven't looked in depth at making an installer. I imagine its not too difficult. Maybe someone on this list can help us out here? > 5. Security/ Standards: > a. Encryption: Client-Server (SSL) and Server-Server (PKI): The > ability to protect data in transit is important. Tick. The client-server protocol will use SSL with a signed certificate. The server-server communication is authenticated as well, though I don't know the details there. > b. Authorization: once authenticated, users should only be able to > access authorized waves/wavelets/blips. This would probably be done > using the authentication system in some manner. Yes. Not done yet, but it will. > c. No use of Google Web Tools (GWT)or other unapproved code: Don't > take this the wrong way, but many of the Government security types are > totally set against anything that uses GWT. They contend it obfuscates > the underlying code and could be an attack vector into the system. This is a hard one. At the moment the entire web client is written using GWT. We plan to make splash (a lightweight non-gwt client) work with fedone, though live typing doesn't work in splash. (There will be a lot of work to make this happen). If this is super important to you guys, it might be worth making a native wave client, or waiting until native wave clients are made by 3rd parties. > d. Servers with full STIG (Security Technical Implementation > Guides): STIGs are just settings on the server that lock down specific > ports, protocols, and portions of the system in question for maximum > security. They can cause things to not work, but have to be followed > as much as possible or exceptions must be sought. I don't know what that is, but making a document detailing which ports need to be open and whatnot should be easy to write. > e. Use approved Federal Government XMPP There's no presence / XMPP-based chat support in WIAB. This is surprisingly difficult to implement. > 6. Full code review/ test throughout development: This is more of a > going-forward concept, but it is important from a security standpoint > to make sure no "sleeper" code gets onto Government networks. Pre-commit code reviews are standard google practice. We are doing code review for all new code added to fedone. Fedone (and hence wave-in-a-box) code reviews take place here: http://codereview.waveprotocol.org/ > 7. Full Presence/ Awareness (XMPP): > 8. Email integration (in and out): > 9. Embed waves in portal pages: None of these things are planned for v1.0 of wave-in-a-box. I think they're all important, but not critical to having a working product. > 10. Robust Search: The ability to search through waves and across > federated servers for keywords and tags is important. Search will work, but there's no current plan to make full-text search work across federated servers. (You will be able to search any wave that you have been added to explicitly, but public waves hosted on other servers won't appear in your search results). > 11. Archive/ persistence of waves: This will be done. Further, all operations are signed in the database (so archives will be tamper proof). > I understand some of these might not be exactly clear to > non-Government types, and I would be happy to elaborate as necessary. > I totally understand many of these are way past what the existing team > is geared up to accomplish. Perhaps the community could take some of > this on, and if we can get support and funding, the FedWave team would > be on point to get much of this work done. > > Please contact me with specific questions or for more information. > > Thanks, > Mark > > -- > Mark R. Kovacevich > > Email: [email protected] > Wave: [email protected] > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
