[standards-jig] Advanced authentication
iainshigeoka at yahoo.com
Wed Apr 17 17:35:29 UTC 2002
On 4/16/02 8:19 PM, "David Waite" <mass at akuma.org> wrote:
> 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?
:) Well, I'd say its actually worse. In something like TCP, you may not
trust it, but you can do some interesting things to increase your security.
In addition, it is hard-ish to do things like man-in-the-middle attacks
because you can't really guarantee that you'll be able to intercept all
packets going between the communication pair you're trying to attack.
With Jabber, if you're the server, you're guaranteed to get everything
passed between two participants. You also have intimate access and control
to routing, timing, ordering, etc. I'd also imagine that most security
issues would like to rely on the server to provide 'network time'. However
if you can't trust the server, it could be harder to eliminate the chances
for replay attacks which normally are thwarted with timestamps. This is
especially bad if the security system allows you to negotiate your security
methods. The server can then ensure that communication pairs always use the
lowest acceptable level of security.
Still. I agree that its basically communication via a non-trusted medium.
> 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).
Right. Although practically speaking, authenticating with everything you
interact with on the Jabber network will become unwieldy and expensive for
all parties involved. In most cases, the server will probably need to serve
as transport _and_ security proxy. The typical use case will still be IM
and it makes no sense for the server to be completely untrusted while
presence management etc (which is hosted in the server) is completely
>>> 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.
True. Configuration should probably be outside of the Jabber spec though.
> 2. /authentication differs based on the type of service/ : users
> authenticate, but servers currently consider DNS to be a trusted party.
:) Of course you don't want me to get started again on how bad it is to
> 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.)
True again. But we should be careful to not get bound up in jsm. There
are other ways to build a server.
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
More information about the Standards