<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Iain Shigeoka wrote:<br>
<blockquote type="cite" cite="midB8E1AD73.5254%25iainshigeoka@yahoo.com">
  <pre wrap="">On 4/15/02 6:39 PM, "Robert Norris" <a class="moz-txt-link-rfc2396E" href="mailto:rob@cataclysm.cx"><rob@cataclysm.cx></a> wrote:<br><br></pre>
  <blockquote type="cite">
    <pre wrap="">First, it should be noted that AAF is not simply a replacement for the<br>current authentication system, which is only really used during client<br>(c2s) authentication. It is intended to be allow for authentication<br>between any two Jabber entity, not just for authentication of a client<br>to a session manager.<br></pre>
  </blockquote>
  <pre wrap=""><!----><br>Client-Client authentication is interesting.  What kind of security model<br>are you thinking about?  If you can't trust the server at least as much as a<br>client you communicate with through the server I can't see this as having<br>that much value with the current Jabber setup.  Unless you encrypt packets<br>separately and are negotiating authentication and perhaps exchanging keys<br>with these other clients.  I have a hard time imagining how secure you can<br>make it though if you can't trust the server...</pre>
</blockquote>
You can make it as secure as anything else using a non-trusted medium for
transmission (such as TCP), right?<br>
<br>
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).
<blockquote type="cite" cite="midB8E1AD73.5254%25iainshigeoka@yahoo.com">
  <blockquote type="cite">
    <pre wrap="">1. Jabber has two "services" in the IANA service registry, jabber-client<br> and jabber-server. These are completely ambiguous in the context of<br> component-component authentication, for example. And, even in the places<br> where they might have relevance (ie connections to c2s/s2s via TCP),<br> what purpose does their use actually serve?<br></pre>
  </blockquote>
  <pre wrap=""><!----><br>Each is playing different roles.  Jabber component protocols IMO are<br>implementation specific and shouldn't be in the Jabber standard.  A clear<br>server and client role is very normal isn't it?</pre>
</blockquote>
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:<br>
1. <i>configuration</i> : client and server handling daemons can run in different
processes or on different (sets of) machines for non-simple firewall or server
configurations.<br>
2. <i>authentication differs based on the type of service</i> : users authenticate,
but servers currently consider DNS to be a trusted party.<br>
3. <i>authorization is hard-coded based on connection type :</i> 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<br>
4. <i>routing differs based on connection type</i> : 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.)<br>
<br>
Take service lookup to be the solution for (1) - you could just have jabber-client
and jabber-server resolve to different machines. Additional authentication
mechanisms solve (2), while a non-implied authorization mechanism solves
(3). The only real difference is that a client connection has the proxy of
jsm to shortcut a ton of logic, such as presence broadcasts.<br>
<br>
-David Waite<br>
</body>
</html>