[standards-jig] Advanced authentication
iainshigeoka at yahoo.com
Wed Apr 17 17:20:35 UTC 2002
On 4/16/02 4:13 PM, "Robert Norris" <rob at cataclysm.cx> wrote:
>> 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...
> 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.
> 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,
> 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
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.
>>> 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.
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.
> 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).
>>> The thing that occured to me while writing the above list is that SASL
>>> is really suited to simple client/server-based services where a client
>>> connects to a server via TCP, authenticates, does some work, and then
>>> disconnects (ie SMTP/IMAP/HTTP/POP/LDAP/ACAP/whatever). It is not
>>> suited to the kind of peer-to-peer communication that Jabber does most
>>> of its work with.
>> I'm not sure I'm understanding this correctly. Jabber is client-server. In
>> fact, its strictly client-server. Something like BEEP that uses SASL is
>> peer-to-peer. A challenge response protocol doesn't imply a client-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).
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.
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.
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
More information about the Standards