[standards-jig] Advanced authentication
rob at cataclysm.cx
Thu Apr 18 00:20:40 UTC 2002
> > What is the server? Is it jabberd? c2s? jsm?
> It is an entity in the Jabber network that implements the server side of the
> c2s protocol, and optionally the server side of the s2s protocol. Jabberd
> is an implementation of a server. Jsm is an internal part of jabberd and is
> not a separate Jabber entity.
The thing that handles user sessions (the session manager) is a distinct
Jabber entity. A transport is another entity. The bit of the code that
handles client connections and server connections may be combined into
this, but thats OK, because you don't authentication to these anyway -
you authenticate to an entity that provides a service you're interested
> > I'm thinking of this scenario: some entity on the Jabber network (be it
> > a session manager, a transport, a c2s client) wants to offer a service.
> > But, it only wants to allow certain other entities to use it. So, it
> > requires remote entities to authenticate to it before they use it.
> When you are talking about Jabber standards, it is important to divorce
> yourself from the jabberd implementation. Forget about jsm, the session
> manager and other internal components of jabberd, or how it functions
> internally. Other developers can implement a jabber server in extremely
> different ways. This also goes for things like chat managers, chatbots,
Agreed, but there will still be discrete entities attached to the
> > This could be the traditional case of a c2s client authenticating to a
> > session manager, but what about (say) a blogging component
> > authenticating to a pub/sub service? Or a c2s client authenticating to
> > msn-t?
> Ideally, transports are supposed to be transparent to clients. Clients are
> simply sending IM packets to a Jabber endpoint. The server takes care of
> getting it there in its role as router. The fact that transports are built
> the way they are in jabberd doesn't mean that is the way it should be.
Transports will never be completely transparent to clients, because you
have to know their address so you can route to them.
AAF is trying to address authentication to endpoints, not authentication
to the network itself.
> >>> 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?
> > That's not true. A component is a valid Jabber entity, and must speak a
> > standard protocol if it expects anything to talk to it. Every transport
> > does this, for example.
> No that is not correct. That is how it is done in jabberd. All components
> that wish to work with jabberd must speak some standard protocol in order to
> plug-in to it. It's like saying all web components must speak Apache module
> API. This is obviously not true.
I'm not talking about how jabberd handles things internally. Entities
attached to the network must communicate in a defined way, otherwise,
what's the point? It doesn't matter what type of entity they are, or
where they are in the network (remember, the network spans multiple
"servers" (routers)) - they should perform tasks in a standard way.
> Plugins/components to other servers can use a completely different protocol.
> For example, I can build a Java jabber server that uses the Java Messaging
> Service or Enterprise JavaBeans to provide component integration. Someone
> else may use shared memory, native RPC libraries, NFS, etc.
You can, but what if I (connected to the session manager of my stock
Jabber server) wants to communicate with an internal component on your
server (a transport, perhaps)? I still need to be able to talk to that
component via a standard interface, regardless of how you implement it.
> > It is a client/server role insofar as a one entity initiates an
> > authentication to another, but the type of service that the "server"
> > entity provides could be anything. jabber-client and jabber-server are
> > for two specific cases, c2s clients communicating in the jabber:client
> > namespace, and servers talking via s2s.
> Right but they are the only standard entities in the jabber protocols.
> Components are part of the server. Chatbots can be implemented as pure
> clients (although for efficiency you may want to shortcut that).
Components are part of the network. I can talk to a component on another
"server" without ever being directly connected to that server (or even
being aware that it is another server).
> > BEEP is a transport layer, yes? (I admit, I don't have much experience
> > with it). AAF operates at a higher level than the Jabber transport (ie
> > the <stream:stream/> stuff). It is for authenticating individual
> > entities, any entities.
> Yes. BEEP is transport. Currently in Jabber there is only one type of
> authentication, client-server using authentication credentials associated
> with a user account. (Technically s2s authentication exists but I'd not
> really classify it as secure authentication). Once authenticated, the
> Jabber client is associated with the established session and the only
> additional option is to secure the transport (SSL). Once the session
> authentication is established all actions taken by the client uses that
> authentication (basically, it becomes completely trusted by the system).
Agreed, to an extent. Remember, however, than you're only actually
authenticated to the session manager, and all actions taken by the
client go through the sm. It is the session manager (as an actual entity
on the network) that is trusted by the system.
This is what I'm attempting to address. After you authenticate to the
session manager, you can do anything you want anywhere on the network
(which is not just the stuff attached to the local router, but stuff
attached to any other "router"). All remote entities trust you, because
you (via the session manager) are on the network.
This is analagous to me having complete access to every service provided
by every host on the global Internet, just because I have my machine
connected to that same network. This of course is not good, which is why
we require people to authenticate to some services.
> BEEP provides this level of authentication and security using SASL. I'm
> mostly using it as an example of SASL though. We could be talking about
> SASL for secure email or https but BEEPs SASL implementation uses XML so
> would probably look more familiar to jabber developers.
Not really. I read through RFC 3080 and I struggled. The use of SASL
looks somewhat contorted, which is what I wanted to avoid. AAF is
simpler (though perhaps not as generic - which shouldn't matter, since
its specific to Jabber). The authentication mechanisms, need not be
> I guess the issue here is that Jabber authentication is currently
> client-server session authentication. If you are talking about something
> else, then you're introducing a new security model to Jabber. When
> introducing a new model, you will probably have to illustrate it with
> use-cases and justify the need in order for us to understand where you're
> going with it.
I'm talking about generic entity-entity authentication, not the specific
case of user client to session manager authentication. Perhaps it is a new
security model, though I would argue that it is a more generic version
of what we already have, and one that is conceptually the same as the
way service authentication works in the Internet proper.
Robert Norris GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 232 bytes
Desc: not available
More information about the Standards