[JDEV] Re: Verifying Jabber + External Ident apps + Presence scalability + New protocol ideas submissions

[Al Sutton]

Why not have 3rd party apps authenticate to the jabber server using the
digest method? 3rd party apps would receive the users server details, JID,
an active session ID, and password digest calculated using the active
session ID. This should be enough information to authenticate against the
users against a jabber server which had been modified to allow digest
authentications using session IDs that were still "live" (i.e. the user is
still logged in using that session).

Comments?

Al.

----- Original Message -----
From: "Dave Smith" <dave at jabber.org>
To: <jdev at jabber.org>
Sent: Tuesday, June 26, 2001 1:44 PM
Subject: Re: [JDEV] Re: Verifying Jabber + External Ident apps + Presence
scalability + New protocol ideas submissions


>
> Greetings..
>
> This is a very interesting idea -- while I don't necessarily like M$'s
> Passport schema (especially the part where you must auth via M$), I
> think there may be merit there.
>
> I strongly disagree with the idea of sending an IP embedded in
> presence -- not only is it not scalable, it also doesn't really solve
> any authentication problem. Just because you recieve presence from
> someone with an IP doesn't mean that person is actually on that
> box. Also, as someone further down the thread pointed out, many people
> are behind firewalls and pooled connections, so this concept just
> doesn't work.
>
> Realistically, what you're looking for is something along the lines of
> kerberos. In a kerberos style setup, you authenticate once against a
> central server and then are assigned a special "ticket" for a
> specified amount of time. When you visit other entities which support
> kerberos auth, you present the ticket and they query the central auth
> server for the validity of the ticket. In this way, you can be behind
> a firewall or whatever and still have a way of uniquely identifying a
> person. Furthermore, the 3rd party doesn't know your password -- all
> they have is a one-time, time-limited chunk of data with which to
> validate you.
>
> I'm not totally up to speed on the details of kerberos, but I believe
> this is the general operation. Alternatively, one could implement a
> system which behaves similarly using some mix of GPG/PGP.
>
> Diz
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev