Re: IM2000 over XMPP (warning: long)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 02 September 2003 9:27 am, Clemens Fischer wrote:

<snip>

> could you summarize jabbers approach to authentication and encryption,
> please?  

</snip>

Jabber/XMPP can use various forms of authentication and encryption. It can use 
TLS between client and server (but then you run into the problem that most 
messages over IM2000 will be hopping from server to server, at which point (I 
believe) they become cleartext. I'll investigate s2s TLS more in depth...
It is for this reason, I think, that many Jabber clients employ built-in GPG 
encryption, to ensure end-to-end encryption and decryption only by the 
intended recipient.

Authentication can be customized to use various backends. For instance, by 
default it is extremely easy to register a new account on a public Jabber 
server (this would need to be addressed for IM2000) because it uses a simple, 
XML-file based auth backend. You simply log on, and if the server doesn't 
find your account, it asks if you'd like to create one. From then on, it can 
store information related to your account on the server to allow roaming from 
client to client. However, in an XMPP-based chat installation I did last 
year, I set up authentication to check against the same MS-SQL stored 
procedure that the web application was using for auth. So in that case, you 
were only authenticated on the Jabber server if you had an active session and  
a valid account in the web app.

Now, IM2000 capabilities will most likely need to handled by a Jabber 
component. These connect to the Jabber server and are configured to handle 
certain packet types (in this case the jabber:iq:im2000 namespace from my 
examples in the 'draft protocol' message I sent yesterday). So, we can 
basically add any functionality we want to that component, and enforce any 
rules we want in that component. Just as an example, we could require that 
all IM2000 clients/servers recognize the CACert root certificate (they are 
like Verisign, but give free certificates) and then only allow traffic that 
is TLS encrypted and has a valid certificate. By requiring the CACert root 
certificate, we would still allow those who cannot afford a Thawte or 
Verisign certificate to run an IM2000 server. Or, as another example, we 
could check all accounts attempting to use the IM2000 component against some 
extra security check, and then flag them as 'verified' or something like 
that. This would allow the Jabber server, as such, to continue allowing 
ridiculously open account creation, but it would require some extra measure 
of identity verification or accountability before one could access the IM2000 
component.

> note that im2000 must be able to handle one-to-many emails
> with a central, possibly mirrored repository for mailinglists in
> addition to the customary one-to-one emails.  the former can be
> signed, the latter must also allow encryption.  note also that one of
> the merits of im2000 must be spam-resistance, covered well assuming
> that senders will have to provide storage facilities.  we will have
> more and more roaming users, and their communication partners might
> not want large binary atachments like pictures or presentations:  the
> protocol must allow a certain degree of negotiation, and the
> negotiation must at least be partly automatic, steered by recipients
> preferences!

For the one-to-many emails, I assume that these lists can be stored on the 
list creator's IM2000 server (at their ISP, I'm assuming). Then, when someone 
sends a message to the list, [email protected], let's say, the IM2000 
component will send a new message notification to [email protected]. Then the 
IM2000 component at myhost.com, upon receiving this notification, will look 
up the addresses in the mylist list and forward the new message notification 
to each of them. Those addresses will then download the email from the 
original sender's IM2000 server (if they choose to download it at all). We 
could require that IM2000 components honor 'remove-me' requests that are sent 
to them for lists they manage (assuming an appropriate level of identity 
verification of the sender). We could also require authorization before 
people could be addedd to lists. Of course, none of this would help if 
someone simply wrote a non-conforming IM2000 component that ignored these 
requirements. But that is where requiring TLS w/ a valid certificate would 
come in handy because we would then be reasonably assured of a point of 
contact for getting that server to clean up its act.

As for negotiation, we can simply add flags to the new message notification 
that informs the receiver what kind of payload is being sent to them. They 
can then elect which parts they want to download, if any. We can send 
basically any data that cannot be easily made to grow ridiculously large by 
the sender (so, for example, size of attachment would be OK, but an unlimited 
length 'description' field would not). As long as we limit it to computed 
data (and not sender-input data), the new message notifications can be quite 
informative. And, because they're XML and inherently machine parsable, we can 
allow users to automate any part of that negotiation they desire (e.g. 
auto-download attachments <=100KB of type text/plain, but nothing else).

<snip>

> this XMPP server would be the senders email-ISP, and it would only
> accept authenticated "posts"?

</snip>

Yes, that's what I'm envisioning. For instance, I run an email ISP at my site 
(libretech.org) for just a few people. If I installed an XMPP server on my 
libretech.org colo box, and then got a working IM2000 component on it, I 
could then modify IMP (the PHP-based webmail app that my users use) to log on 
to the XMPP server when a user logs on to IMP. I simply use system accounts 
for auth, so I would need to install or write a system-account auth backend 
for my XMPP server. Since they're using the same auth backend, any user that 
gets onto IMP should get onto the XMPP server too (but of course we check 
both times). Then, when an IMP user composes a message and clicks Send, a new 
message notification is sent to the XMPP server, addressed to the email 
address of the recipient with a resource of im2000client or something like 
that (we need to discuss this part some more). So, it would simply take the 
person's existing email address, and append '/im2000client' to the end to 
create a valid XMPP id. This packet, because of its XML namespace, would be 
forwarded to the IM2000 component by the XMPP server. The IM2000 component 
could then do whatever voodoo it needed to to the packet, and send it off to 
the recipient's XMPP server. Now, here's where it gets interesting... If the 
recipient's domain resolves to an IP address w/o a listening XMPP server 
(maybe we need to propose an MX-type DNS record for XMPP servers?), then the 
packet will bounce. When this occurs, the IM2000 component can simply use the 
Jabber -> SMTP gateway to send the message to the same address (minus the 
resource, obviously) via SMTP. Either way, the message gets there, but if the 
recipient is set up for IM2000, then it uses that. All of this is completely 
transparent to the sender using IMP. They simply typed in the same email 
address they have always used for that person.

> your description sounds good, but it
> may happen that authenticated access will be made mandatory.  there
> might be email transports and im2000 transports, where the latter only
> allow authenticated traffic.  then there are countries - and even
> companies - not allowing encrypted emails, this must be accounted for
> in the XML namespace used.

</snip>

Did I cover all that above? If I leave any concerns unaddressed, let me 
know...

>
> > If we assume this is an unknown sender, the receiver can now decide,
> > based on the limited information sent in the 'new mail notification'
> > packet, whether to download the message or 'delete' (ignore) it.
>
> i don't think recipients should be able to delete messages on the
> senders side, so "ignore" is the better term.

Agreed.

>
> > Popular XMPP clients already have TLS and GPG integration for
> > ensuring transaction privacy and could also be used w/ signing to
> > ensure that senders are who they say they are.
>
> btw, are there unix XMPP (jabber?) commandline clients?  without or
> with optional GUI?

Yes, there are... But the names of them are escaping me at the moment. If you 
look at the clients on http://www.jabber.org/ you should be able to find some 
command-line clients.

>
> > Am I off base here? Has this already been discussed?
>
> no, not off base, not at all.  we have discussed quite a lot, finding
> some issues needing clarification.  unfortunately, we don't have a
> reliable wiki right now, which we used to keep our respective
> proposals HTML/HTTP accessible.
>

I may be able to host a Wiki on my site (http://www.libretech.org/) if that is 
the issue...

> a little rundown of XMPP/jabber would be nice.

Hmm... I could try to do that, but I would do a much worse job than this page: 
http://www.jabber.org/about/techover.html

>
>   clemens

Thanks for the feedback! It has already caused me to rethink some things I 
wasn't looking at in the right way. :) Keep it coming!

Wes Morgan
- -- 
This American dream may be poisonous
Violence is contagious
Crowded or empty
I walk these city streets alone
Whoever brought me here
Is gonna have to take me home

"What I'll Remember Most" - Over the Rhine
- ----------------------------------
Libretech.org - Technology Is Free (http://www.libretech.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/VNG2I89ooLagmnQRAjwnAKC5f981oemS62p2ILtol9F/pO6kQQCaA5IW
0py88AcXxy5hjOltjkUBfuQ=
=B40h
-----END PGP SIGNATURE-----