[JDEV] Re: SASL, deployment and coding

[Matthew Beacher]

David Waite wrote:
> Matthew Beacher wrote:
> 
>> Robert Norris wrote:
>>
>>> This hasn't really been discussed in any detail. I would suggest joining
>>> the XMPP working group and bringing this question up there:
>>>
>>>   http://www.jabber.org/cgi-bin/mailman/listinfo/xmppwg/
>>
>>
>>
>> I'll read that as: Use the one built in the standered, not SASL as it 
>> is not in any clients.  So I ask, Anyone know how to interface with 
>> SASL password files?  I am guessing they are based on Unix Password 
>> Files. 
> 
> 
> The jabber:iq:register namespace is non-normative within the XMPP IM 
> draft. Implementations can choose to implement registration, but it is 
> not really required or standardized.

Mabey you missunderstand me.  I want every user to have to log in, and 
SASL, at least the implementaion I am using, cyrus SASL, holds the 
usernames and passwords itself.  It also alows users to be created 
within the Challeneg / Responce cycle.  If I can not add users using 
SASL itself, then I need to know how to interface with the SASL password 
files, because I only want one password list, not 2.

> 
>> <message to='receve-id' from='send-id'>
>>
>> fexable - Accept this code
>> hard line - elements not in correct order, dump line. 
> 
> 
> Attributes are always order-independant. Now, if you mean something like
> <message>
>  <body/>
>  <subject/>
> </message>
> 
> The body and subject childs are allowed in any order by the existing DTDs.
> 
>> Well, not for everyone, but all server and clients that support SASL 
>> must use it with a minimum level of encription.  And then make sure 
>> that   EVERYONE starts including SASL.  It is very easy to include IFF 
>> (if and only if) you use the cyrus SASL code relesed by Carnegie 
>> Mellon University.
> 
> 
> I do not want to use transport encryption, because
> 1) it does not provide any solid security because of existing 
> non-encrypted connections, and because you cannot guarantee trust of the 
> remote endpoint across hops (in real-world terms, "a friend of a friend 
> of a friend once told me about this guy" should not have the same amount 
> of trust as actually knowing the person being talked about directly.)
> 2) it is impractical for many embedded applications.
> 3) it puts unneccessary load on the server
> 
> -David Waite
  The use of Transport Encryption is not up to the server, if a 
Transport Encryption is negoshiated during SASL, you must use it, if it 
is nigoshiated. This is according to cyrus SASL docs.

Matt
SyOpReigm
http://www.Reigm.Com