Improved authentication and security

[GoogleCodeExporter]

From reading the protocol spec, it appears that UCE (Or Unsolicited
Commercial Waves (UCW)?) could still be a problem. I have read in the spec
that the underlying XMPP connections will be secured using TLS, but perhaps
we should go one step further and require validation of domain certificates
in order to prevent anonymous and ubiquitous junk-mail which has plagued
e-mail systems for years. One possible answer might be to use a resource
record in DNS to store the public key for a wave-domain and require the
validation of the certificate in order for wavelets to propagate between
wave-domains. An additional measure might be a methodology for allowing
wave-domains to validate users when wavelets are propagating. So,
wave-domains would be ensured that the source of the wavelet is from the
indicated server and that the user account is a valid user in good standing
prior to allowing that user to participate in a wave. This would make
current UCE/UCW all but impossible because every user would have to be
validated and could be individually denied. Bot nets would have no chance
because they cannot be validated. Mass accounts created on public servers
would be quickly sniffed out and locked upon suspicion of spamming. It
would solve many of the problems of modern messaging.

Original issue reported on code.google.com by deven.phillips on 2 Jun 2009 at 12:58

[GoogleCodeExporter]

Additional. To prevent overloading of servers, you could cache validation 
information
for a limited (administrator defined) period of time. So, if an 
account/certificate
has been validated in the last 20 minutes, then no additional validation is 
needed
for individual wavelets.

Original comment by deven.phillips on 2 Jun 2009 at 1:02

[GoogleCodeExporter]

This would be a great way to block out bots, but what if a server is hacked and 
used as 
a spamming server. There really needs to be a good way to have the wave-domains 
re-
evaluate the server to allow it access to the waves again once it's been 
cleaned. As 
far I know it's almost impossible on most servers these days to get yourself 
whitelisted once blacklisted.

Original comment by rstam...@gmail.com on 5 Jun 2009 at 3:24

[GoogleCodeExporter]

Folks, in XMPP the server certificates should be checked against the full trust 
chain down to the root CA. Self-
signed certificates tell you nothing, so they should not be trusted. I take it 
this is what deven.phillips means 
by "require validation of domain certificates". It's standard XMPP.

XMPP also requires servers to stamp the sender addresses of individual users, 
and for servers to check the 
sending domain as well. So it's simply not possible for an entity to fake the 
sender address as it is in email.

Yes, rogue servers could join the network, but they can be easily blacklisted.

Please take a little time to read RFC 3920 -- it will answer many of your 
questions about XMPP security.

--stpeter

Original comment by stpe...@gmail.com on 5 Jun 2009 at 3:49

[GoogleCodeExporter]

Keep however in mind the virtual domain problems we have with SSL certificates 
and
HTTP. With IPv4 the address space is not that large to give every domain a 
unique IP.

SSL certificates for the server, as well for the client to authenticate are very
important on this type of protocol, because of the possible sensitive data 
traveling
it. Man in the Middle shouldn't be possible with the system. With HTTP(S) it's 
doable
to do MitM. So that point does need attention.

I don't like the user validation part. User validation can lead to 
brute-forcing for
allowed users, which will be rather useful for spammers and crackers.

@stpeter,
The Email servers, with current SMTP protocol can also be blacklisted, on where
spammers are sending from, but that will also kill a lot of good connection. So
please be aware to not make the same mistakes we made with the SMTP protocol 
and the
security of it.

Original comment by michiele...@gmail.com on 20 Jul 2009 at 4:43

[GoogleCodeExporter]

Original comment by btkalman@gmail.com on 29 Aug 2009 at 2:12

[GoogleCodeExporter]

Hello,

I'm astounded by Wave's collaboration potential, but also its immense security 
risks.

One huge thing it could do from the get-go is provide for (or better mandate) 
all 
users/recipients on a Wave are real and legit and all group content is secure.  
In 
the snail mail context, this means all msg's are digitally signed and content 
encrypted.  In the Wave context, it could(??) mean that when joining the 
conversation 
one must login with strong authentication (to include smart cards), that login 
has to 
be validated by a 3rd trusted party (PKI, certificates), a trustworthy endnode 
is 
being used (be it a browser version or deep inspection), and the communication 
tunnel 
protected (https).  Likewise, different Wave servers have to be trusted.  By 
making 
these and other simple, common-place efforts, Wave could become a ___TRUSTED___ 
collaboration environment.  This would reduce spam, malware, cyber-crime, and 
cyber-espionage yet at the same time increase collaboration.

Kevin the Wave-newbie and DoD cyber-security engineer

Original comment by swee...@gmail.com on 8 Apr 2010 at 5:25

[GoogleCodeExporter]

Hello again,

Might there be a better forum in which to discuss Wave security?  The Google 
Wave 
Help forums don't seem to be the best place either.  

I see great potential in Wave but it won't be adopted by major organizations 
unless 
it provides a trusted environment.  Bolt-on security costs too much and offers 
poor 
protection.  Wave is simple cloud model but with immense interaction at then 
end-
nodes.  Many fundamental solutions exist.  I'd like to talk more on this 
but.... 
where?

Kevin from spi.dod.mil

Original comment by swee...@gmail.com on 8 Apr 2010 at 5:57

[GoogleCodeExporter]

Keven the best place to post your questions is
http://groups.google.com/group/wave-protocol/ You can post messages directly at 
the
URL or subscribe to the mail list.

Also, you can find a lot of information at: http://www.waveprotocol.org/
You can start by reading the federation specification.

Original comment by Tad.Glines@gmail.com on 8 Apr 2010 at 6:27