[JDEV] Re: SASL, deployment and coding
SyOp at Reigm.Com
Tue Feb 4 18:33:07 CST 2003
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:
>> 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
> 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
> 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.
More information about the JDev