[standards-jig] Advanced authentication

Robert Norris rob at cataclysm.cx
Thu Apr 18 23:03:00 UTC 2002


> > 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
> > in.
> 
> 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.

This is the specific case of user client authentication. User clients
will always be a special case, since they never actually attach to the
network directly, but instead sit behind a session manager.

> 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".

A transport can talk to any other entity connected to the network. It
can't talk directly to user clients, because they aren't connected
directly to the network - all their traffic is mediated by the session
manager.

> > Agreed, but there will still be discrete entities attached to the
> > network.
> 
> 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
> network).

Are you saying that any entity connected directly to the network can be
considered a "server", while any entity that is not connected directly
(a user client) is a "client"?

> > 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.

I'm not sure I understand this. What I meant, is that to talk to, say, a
user on AIM, I need to know that I need to send messages to
user at aim-t.host.

If there is some sort of mapping like this, its news to me.

> > 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.

Almost. I expect it to replace the user client to session manager user
client, and also provide a generic means for two arbitrary entities to
authenticate.

> > 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...

Agreed, sort of. You mean that the protocols need to be in either the
jabber:client or the jabber:server namespaces. The problem is that
neither of these are defined, per se, and the line between them is very
fuzzy.

> >> 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.

I agree.

I understand what you're saying about two components internal to your
router - there may be better ways for them to authenticate (or you may
decide that they are implicitly trusted, whatever). However, it an
entity is providing a service to any other entity on the entire network,
it must speak a standard protocol, regardless of how it is actually
connected.

Of course, that standard protocol may be handled elsewhere, and mapped
to some internal representation of the same request. As long as the
remote entity thinks it is talking directly to the other entity, it
won't care.

> >>> 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
> standardized.

I think I misunderstood earlier. I agree - how internal components
communicate is entirely up to them, but any entity that provides a
service to anyone on the network must provide a standard interface.

> > 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
> session manager.

Not really, because a Jabber "server" is actually more like a network
router than a single server (like a web server). You only authenticate
to the session manager. Every other entity implicitly trusts the session
manager because it is connected to the network.

> > 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.

It is different to the tradition user client to session manager
authentication. It's more generic.

> > 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
> can do.

I don't expect that every entity would require authentication. That
would just be silly. For example, I don't expect that IM session
managers will ever require authentication to each other, that wouldn't
make a great deal of sense.

As for the problems with it (having 100 different passwords), these are
the same problems that normal "Internet" authentication has, and are the
type of problems that things like Kerberos attempt to address.

(Using AAF, it would be entirely possible to implement a Kerberos
authentication mechanism without too much trouble).

> 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
> discussed.  :)

I'm doing the best I can - just resisting the urge to shout "No! You're
doing it wrong! You're spoiling it!" ;)

Rob.

-- 
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
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20020419/284792dc/attachment.sig>


More information about the Standards mailing list