[standards-jig] Advanced authentication
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards