[JDEV] Security in XMPP/Jabber: some questions && Re: [xmppwg] SASL vs TLS

Fri May 23 07:12:50 CDT 2003

Well, it is just my view, but I feel their should be 2 completely 
different systems for encryption.

1) Client-Server Encryption, based on SASL as stated in some of the XMPP 
standered.  It is already in the log in part of the standered, and after 
log in, is transparent to both the server and client.  While the 
cyrusSASL code is EASY to work with, but the code is not the easyest to 
compile.  To your question, having worked with cyrusSASL, unless you 
force it, the cyrusSASLClient chooses whatever it wants, based on the 
internal code, and you don't get a choice in the matter.  The only way 
to define what it uses is a matter of hard coding it into the program.  
Also, be carful when doing something like that, while cyrusSASL comes 
with a lot, the "Good" encryption is not avalible for distrubtion.  You 
must get it independantly from OpenSSL.  You see cyrusSASL is a project 
of CMU in Pittsburg, PA USA.  So US law gets in the way, as always.

2) Client-Client Message Encryption.  There should be a end to end 
encryption that the server dose not know, to insure message security.  
This is the only way to be 100% sure that no one is reading the 
messages.  I vote for some type of PGP.  Security is 100% known, and the 
server could act as a public key ring.  Just a thought.
FYI: I figure it would look like:
<body><encrypted>djshf;ksdhfsdfhsadufhsuiodfhsdhfkjsdhf</encrypted></body>
Just imagin the Message tage and every other tage I just ignoted.  Also, 
I'm not 100% on the standred but, this might not require changing the 
servers much if at all, if the server knows to ignore everything between 
the body tags.

3)Server-Sercer, I feel there should be an addition in the form of SASL 
for server server, but the question is how?  It would need to be an 
addition to the server dialback procedure.  I admit there is a need for 
it, but that is something that XMPPWG needs to work on.

As to SASL not being up to "Par",  the only whay it will be is if 2 
things happen.
1) The installers download the "good" encryption from openSSL, because 
unless a project is 100% outside the US, they, can't destrubte that code.
2) Every Server and Every Client will have to include a minimum level of 
encryption (I think it is 50 in cyrusSASL) this will force at least some 
encryption to be used including a full stream encryption (as per the 
XMPP and SASL protocols).

Also, we may what to move this descution over to the XMPPWG mailing 
list, because this really is more to XMPPWG then JDEV.

-Matt

(2 messages being replyed to below)
jabber_jdev at aeiou.pt wrote:

>hi all
>
>first of all i would like to say thx to everyone who have answered
>this mail with some explanation, that's the best way to beeing lerning
>about this...
>
>after reading your mail and all the answers, from David, Rob, etc,
>i've made myself a little research too and i would like to keep asking
>about xmpp/jabber security:
>
>if we take a closer look about SASL there's kerberos, tsl - that is
>the ietf version of netscape's ssl ver 3 , GSSAPI - i've to admit that
>i didnt understand this mechanism much , s/key and external mechanisms
>of authentication... and my question is, why not a simple
>authentication using the pki and based on certification authorities?
>public keys, diffie-helman agreement to create session kyes,
>zero-knowledge agreement between servers and clients (note, not
>between clients and servers, server must identify himself first),
>chalange-answer between clients and servers, and one of this two
>between servers and servers ... i think this is pretty much secure
>than anything ...
>
>i would like to have your oppinion about this
>
>thx
>
>
> 
>_________________________________________________________
>
>Bolsa de Emprego AEIOU: simples, rápido, resultados imediatos.
>http://emprego.aeiou.pt
>
>_______________________________________________
>jdev mailing list
>jdev at jabber.org
>http://mailman.jabber.org/listinfo/jdev
>
>
>  
>
RL 'Bob' Morgan wrote:

>On 22 May 2003, Eric Rescorla wrote:
>
>  
>
>>Justin Karneges <justin-jdev at affinix.com> writes:
>>
>>    
>>
>>>>The SASL security layer is not up to par.
>>>>        
>>>>
>>>Care to elaborate?
>>>      
>>>
>>It's an ad hoc mess.
>>
>>The most serious problem is that there isn't a "SASL Security Layer".
>>Each mechanism may or may not provide it's own channel security layer
>>and they're going to be different. Worse yet, some of the individual
>>mechanism layers are... questionable.
>>    
>>
>
>This is FUD, as Eric is well aware.  TLS also is merely a framework via
>which various specific crypto methods may be negotiated (they need not
>even be public-key-based, see RFC 2712), and some TLS/SSL ciphersuites
>might equally be called "questionable".  (This is independent of the fact
>that there are some legitimate issues with RFC 2831 that are being
>addressed in its revision.)
>
>In an ideal world TLS, SASL, and the various SASL-supporting security
>methods wouldn't have been defined at different times by different people
>with different abstractions and limitations, then forced to fit together
>later.  But this is what we have.  A whole bunch of other application
>protocols are defined to work in a more or less consistent way with SASL
>and TLS (IMAP, POP, SMTP, LDAP, BEEP) and it works OK.  Not every
>implementation provides every feature, but in general deployers get to
>choose which mechanisms suit their needs.  It's a big world out there,
>there is no one-size fits all for security mechanisms.  I'm not intimate
>with XMPP scenarios, but I'd encourage folks to let your protocol spec, as
>do the others above, just provide the ability to use TLS and SASL, and let
>implementors and deployers work out which ones will win based on their
>requirements.
>
> - RL "Bob"
>
>
>_______________________________________________
>xmppwg mailing list
>xmppwg at jabber.org
>http://jabber.org/cgi-bin/mailman/listinfo/xmppwg
>
>
>  
>