[standards-jig] Advanced authentication
iainshigeoka at yahoo.com
Thu Apr 18 18:22:51 UTC 2002
On 4/17/02 5:20 PM, "Robert Norris" <rob at cataclysm.cx> wrote:
>>> 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
As I understand the protocols, this is not true. You authenticate with the
server. The server can decide how authentication is assigned to a
particular connection (a session manager or other mechanisms). The server
can't be purely a transport as the authentication packets are not addressed
so routing can't be separated from authentication in a generic sense.
In other words, a pure Jabber "transport" is impossible because it must
actually understand the jabber protocols and the context for a session in
order to properly route packets. This mixed role means you can't treat
these things separately in the current protocols. The finest grain entity
really must be a "server".
Of course, I could be wrong... :)
>>> 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
Right. But they must play either a server or client role. If they don't
play one of those roles, they are part of some other client or server entity
(you couldn't separate them and have them function separately on the Jabber
>>> 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.
> Transports will never be completely transparent to clients, because you
> have to know their address so you can route to them.
Is that true? I thought the server can maintain a map of addresses and
clients using one set of addresses can be completely ignorant of how the
messages are delivered to a particular address.
> AAF is trying to address authentication to endpoints, not authentication
> to the network itself.
Right. I understand that now. I guess my main point is that this is a
completely new feature for Jabber. Not an extension, improvement, etc for
something that already exists. So you really need to explain why we need
it, where we'd use it, etc.
>>>>> 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.
Right. But that's only defined in Jabber for c2s and s2s communication.
There is nothing else. So the protocols must be c2s or s2s...
>> 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.
Right. Using standard IQ in a established protocol. How the server
communicates with its own components is up to the server. The standard only
exists from the outside to the server. How the server communicates with its
components is not specified.
By analogy, look at the web. You have a standard protocol, http, to
communicate from clients or other servers to a particular server. And you
have a standard way of addressing a component you want to access on the
server (the http URL). And the client may be communicating with that
component using some standard protocol like http POST or GET. But how the
server passes the information it gets over http to its component is entirely
up to the server. It could use CGI. Or servlets, or ASP. You, as the
standard client accessing the standard server don't know, don't care, and in
fact, can't care about it.
Similarly for Jabber, we have the c2s protocol for how the client talk to
the server. Jabber Ids for addressing component "services" in the server.
And standard IQ protocols for the data you send to the component. But there
is no standard (nor should there be) for how the server sends the data to
the component, how the components work, or any other details of
server-component communication. Frankly it is just none of the client or
outside world's business.
>>> 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).
Right. But did my earlier analogy make sense? You can talk to a component
in someone else's server, but how the components talk to their server is not
>>> 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.
No, it is the server you are authenticated with that is acting on your
behalf and must be trusted by the system. I'm very uncomfortable with
calling a server a session manager. It's like saying a web server is a
> 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.
True. And this need is something different from what I originally thought
you were doing (improving Jabber authentication). This is much more in line
with the profile and single signon work.
>> 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.
Right. I agree that this is getting much more to our existing internet
security model. I think this isn't a great model to have though as with
that model, you basically need a different authentication credential for
every single thing you interact with. Like how I have about 10 different
passwords for various webmail accounts, 100 different website passwords,
etc. It's a mess. I'd hate to have the same thing happen in IM so just to
chat with someone I need different passwords... However, since it is a hard
problem to solve, perhaps going with something we know works is the best we
ps - I really enjoy and appreciate this conversation. I know how hard it is
to stay on track and debate on technical grounds when your ideas are being
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
More information about the Standards