Subject: [dispatch] Authentication for SIP+XMPP clients

From: Emil Ivov <[email-masked]>
Date: Wed, 10 Mar 2010 16:08:32 +0100

Hey all,

A couple of months ago we had a discussion here about how SIP-XMPP
clients would discover and authenticate against its SIP and XMPP parts.

Enrico and I have recently posted a draft [1] detailing the problem and
summarizing two ways of addressing it. We'd be happy to be able to
discuss this in Anaheim and comments are of course welcome at any time.

Cheers,
Emil

[1] - http://tools.ietf.org/html/draft-ivov-sipxmpp-auth-01

-- 
Emil Ivov, Ph.D.                               67000 Strasbourg,
Project Lead                                   France
SIP Communicator
[email-masked]                     PHONE: +33.1.77.62.43.30
http://sip-communicator.org                    FAX:   +33.1.77.62.47.31

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Mar 2010 10:33:17 -0700

> discuss this in Anaheim and comments are of course welcome at any time.

Regarding section 2, I have a few questions:

1. What kind of URI are you talking about?

2. Is this a URI that the SIP+XMPP service provides to the client? If
so, how?

3. How exactly can a URI and a password be used for authentication in
XMPP (i.e., using which SASL mechanism)?

4. Does the client derive a username from the URI so that it can use an
authentication mechanism that experts a username and password?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Emil Ivov <[email-masked]>
Date: Thu, 11 Mar 2010 20:59:18 +0100

Hey Peter,

> 1. What kind of URI are you talking about?

The the [email-masked] kind.

> 2. Is this a URI that the SIP+XMPP service provides to the client?

Not the service itself but rather the provider.

> If so, how?

Out of scope (but basically via a web registration or any other means  
that people are using for mail and IM registration)

> 3. How exactly can a URI and a password be used for authentication  
> in XMPP (i.e., using which SASL mechanism)?

Below.

> authentication mechanism that experts a username and password?

Yes, exactly. The way most clients would do for SIP and XMPP already.  
This is just about making sure that they would be able to bring the  
assumption over to a SIP+XMPP service.

Cheers,
Emil

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Mar 2010 13:20:17 -0700

> The the [email-masked] kind.

Since it lacks a scheme, [email-masked] is not a URI.

> assumption over to a SIP+XMPP service.

That is unclear to me. Do I visit a website, receive an email with a
URI, click that to authorize, and receive credentials for my combined
SIP+XMPP account?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Mar 2010 15:56:15 -0500

> Since it lacks a scheme, [email-masked] is not a URI.

That was unclear to me too.

I was *guessing* that the intent is that

	[email-masked]

would imply support for a variety of url schemes that can have that as 
their body:

	sip:[email-masked]
	xmpp:[email-masked]
	mailto:[email-masked]

whatever protocols the domain cares to support. IOW its just a 
convention for linking things based on similar name. And then using the 
same, or related, credentials for all.

	Thanks,
	Paul

---

From: Emil Ivov <[email-masked]>
Date: Thu, 11 Mar 2010 23:07:24 +0100

> Since it lacks a scheme, [email-masked] is not a URI.

True. I guess ID would have been a better choice. Is this a problem
for any other reason than the misuse of the term?

> URI, click that to authorize, and receive credentials for my combined

Yes, for example. Pretty much the same way you would get them at
register.jabber.org (while it worked ;) ).

Cheers,
Emil

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Mar 2010 19:38:36 -0700

> for any other reason than the misuse of the term?

Life certainly is simpler if your chat ID and your voice ID are the same
-- and *really* simple if the same as your email ID. This is how service
providers such as Google do things. Naturally, not every provider wants
to offer a combined email+chat+voice service because it's a lot more work.

>>>> authentication mechanism that expects a username and password?
>>>
> Yes, for example. 

OK. But it's still now clear what engineering work is required here. In
the flow you describe, there is some social communication with the end
user ("your chat+voice account has been created!"), but no automated way
of informing the user's software that the account supports XMPP for chat
and SIP for voice. How exactly does the provider communicate that fact
to the application, given that the user's SIP+XMPP application is not
involved in the account provisioning process (as far as I can tell)? Are
you thinking that the end user will employ their SIP+XMPP application to
complete account provisioning, or that the application will communicate
with a web-based registration system somehow? Is there discovery
involved on the part of the SIP+XMPP application?

> Pretty much the same way you would get them at

Yeah yeah yeah. :P We're working on it. Running code isn't always a lot
of fun for those who run the service...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Enrico Marocco <[email-masked]>
Date: Fri, 12 Mar 2010 10:59:16 +0100

> to offer a combined email+chat+voice service because it's a lot more work.

The discussion is getting very close to the point. If you are a
multi-service provider with a user base of millions, you can expect
developers to offer custom integration of your services in their
platforms in order to make life easier to the users. That's basically
why iPhone and Android devices offer a shortcut for configuring
email+IM+calendar+whatever Google services altogether, simply entering
your credentials once.

Of course things work like that for Google and maybe for a few others,
but certainly not for small providers. The goal of the draft is to
stimulate discussion on the topic and to explore how existing mechanisms
(like, e.g., the domain parameter used in DIGEST authentication) can be
used to achieve seamless integration of SIP and XMPP accounts in a
standard way. We certainly do not want to mandate service providers to
offer both services, nor to standardize some exotic multi-purpose
configuration framework that will take years to define and will never
see the light.

-- 
Ciao,
Enrico

---

From: Emil Ivov <[email-masked]>
Date: Fri, 12 Mar 2010 13:54:11 +0100

Adding to what Enrico said,

Peter Saint-Andre написа:
> involved in the account provisioning process (as far as I can tell)? 

The provider doesn't need to communicate that fact to the application.
The user does this by choosing to create a SIP+XMPP account. Again, it's
pretty much what what already happens with multi protocol clients for
SIP and XMPP only accounts.

Cheers,
Emil

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 12 Mar 2010 08:06:53 -0700

> SIP and XMPP only accounts.

Yes, this is all quite beautiful. But I still don't see what engineering
work is required within the IETF to make this happen.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 12 Mar 2010 08:08:40 -0700

On 3/12/10 2:59 AM, Enrico Marocco wrote:
> but certainly not for small providers. 

Indeed.

> The goal of the draft is to
> standard way. 

OK, I do think that's worth exploring.

> We certainly do not want to mandate service providers to

+1 to that!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Emil Ivov <[email-masked]>
Date: Fri, 12 Mar 2010 16:35:33 +0100

> work is required within the IETF to make this happen.

Ideally - none. If we can agree that SIP+XMPP clients can assume they
can SRV query the SIP and XMPP counterparts of a SIP+XMPP using the
usual records, and that they can also assume they would be using the
same credentials to log against both of these protocols and people feel
that this fits the charter (and doesn't violate the the
no-modifications-on-the-server-side requirement), then all we need is a
paragraph in the sip+xmpp document that describes this. At worst we can
put it in a BCP doc.

Otherwise, people may think that the subject is more complicated than
that and that it needs to be explored further for some reason and in
this case there maybe something else to do, and of course I have no idea
what it may be.

Cheers,
Emil