[standards-jig] Advanced authentication

David Waite mass at akuma.org
Wed Apr 17 03:19:21 UTC 2002


Iain Shigeoka wrote:

>On 4/15/02 6:39 PM, "Robert Norris" <rob at cataclysm.cx> wrote:
>
>>First, it should be noted that AAF is not simply a replacement for the
>>current authentication system, which is only really used during client
>>(c2s) authentication. It is intended to be allow for authentication
>>between any two Jabber entity, not just for authentication of a client
>>to a session manager.
>>
>
>Client-Client authentication is interesting.  What kind of security model
>are you thinking about?  If you can't trust the server at least as much as a
>client you communicate with through the server I can't see this as having
>that much value with the current Jabber setup.  Unless you encrypt packets
>separately and are negotiating authentication and perhaps exchanging keys
>with these other clients.  I have a hard time imagining how secure you can
>make it though if you can't trust the server...
>
You can make it as secure as anything else using a non-trusted medium 
for transmission (such as TCP), right?

I am gathering that there are two different views of the system; one 
looking at the existing client/server IM setup, and one at a more 
generic system that is using jabber solely as a transport. If you are 
only playing the transport role, then you cannot trust the network to do 
either authentication or authorization, which means you need to do this 
with individual endpoints (or a trusted party, like with kerberos).

>>1. Jabber has two "services" in the IANA service registry, jabber-client
>> and jabber-server. These are completely ambiguous in the context of
>> component-component authentication, for example. And, even in the places
>> where they might have relevance (ie connections to c2s/s2s via TCP),
>> what purpose does their use actually serve?
>>
>
>Each is playing different roles.  Jabber component protocols IMO are
>implementation specific and shouldn't be in the Jabber standard.  A clear
>server and client role is very normal isn't it?
>
In the transport sense, there is no distinction: everything is either 
providing access to an endpoint or a collection of endpoints. There are 
a few to have separate client and server functionality externally exposed:
1. /configuration/ : client and server handling daemons can run in 
different processes or on different (sets of) machines for non-simple 
firewall or server configurations.
2. /authentication differs based on the type of service/ : users 
authenticate, but servers currently consider DNS to be a trusted party.
3. /authorization is hard-coded based on connection type :/ A user 
session has a one to one binding to a connection, while a server can 
send IM messages from any user and any session on its bounded hostname
4. /routing differs based on connection type/ : User sessions are 
actually proxied to and from jsm, and have a ton of rules executed on 
their behalf. Servers send data directly to the target endpoint (which 
might be a jsm session.)

Take service lookup to be the solution for (1) - you could just have 
jabber-client and jabber-server resolve to different machines. 
Additional authentication mechanisms solve (2), while a non-implied 
authorization mechanism solves (3). The only real difference is that a 
client connection has the proxy of jsm to shortcut a ton of logic, such 
as presence broadcasts.

-David Waite
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20020416/0f727687/attachment.html>


More information about the Standards mailing list