Re: [Standards] guest access

[Matthew Wild]

On 26 June 2015 at 15:45, Peter Saint-Andre - &yet  wrote:
> On 6/26/15 6:46 AM, Matthew Wild wrote:
>>
>> On 26 June 2015 at 13:38, Peter Saint-Andre - &yet 
>> wrote:
>>> On 6/26/15 5:26 AM, Matthew Wild wrote:
>> I'm not sure I understand completely, then. Are you proposing that the
>> target of the SRV record is the XMPP host (and thus ignore the port?)?
>
>
> I'm not sure I understand completely either. :-)
>
> We'll probably do something like this:
>
>_xmpp-client._tcp.talky.io. 400 IN SRV 20 0 5222 auth.talky.io
>_xmpp-guest._tcp.talky.io. 400 IN SRV 20 0 5222 anon.talky.io
>
> Naturally the ports might not be 5222 and such, but the general idea is that
> we want to point guest users at a different auth service. By "SRV two-step"
> I mean that the client would still need to resolve auth.talky.io or
> anon.talky.io in the normal ways (we're not necessarily going to point
> directly to what in draft-ietf-dane-srv we called the "connection
> endpoint").

Right, as I suspected. So the flow would be something like:

 1) Client knows it wants to connect to "talky.io" on XMPP, but it
doesn't have credentials for that domain so it...
 2) Attempts to resolve _xmpp-guest._tcp.talky.io, which returns:

   _xmpp-guest._tcp.talky.io. 400 IN SRV 20 0 5222 anon.talky.io

 3) This isn't a network-level connection endpoint, so it discards the
port number and uses "anon.talky.io" as the XMPP service name in a
usual connection attempt, so it
 4) resolves _xmpp-client._tcp.anon.talky.io, etc. and once connected,
authenticates using whatever mechanism it supports (ANONYMOUS, or
whatever)

As I mentioned, I completely agree with the principle, but I don't
think the technique is ideal. I need to think about it more... :)

Regards,
Matthew

Re: [Standards] guest access

[Dave Cridland]

On 26 June 2015 at 13:40, Peter Saint-Andre - &yet  wrote:

> On 6/26/15 5:57 AM, Dave Cridland wrote:
>
>>
>>
>> On 26 June 2015 at 00:51, Peter Saint-Andre - &yet > > wrote:
>>
>> Lance Stout and I had a conversation the other day about what we
>> call "guest access" to an XMPP application. As example, consider a
>> chat service (text, video, what have you) that has registered users
>> and the ability for registered users to invite ad-hoc users to a
>> session or meeting. This kind of functionality is quite common with
>> applications like video conferencing (Talky, Jitsi Meet, WebEx, etc.).
>>
>> If this kind of application is based on XMPP, the invited user needs
>> to gain access to the network (i.e., authenticate somehow) in order
>> to join the conference. However, for security and scaling reasons it
>> makes sense to have these ad-hoc users authenticate at a different
>> place than the registered users. (Often, but not always, the ad-hoc
>> users might "authenticate" using the SASL ANONYMOUS mechanism, but
>> other methods are possible such as token auth.)
>>
>> Thus we need a way for a client to discover where it can
>> authenticate as an ad-hoc or guest user. We don't want to use a DNS
>> SRV Service name of "xmpp-client" because that will point clients to
>> the service endpoint for registered users. What we came up with was
>> to use a new DNS SRV Service name of "xmpp-guest", which would point
>> to the service endpoint for guest access.
>>
>>
>> Can't the invitation include the connection detail?
>>
>
> At least for Talky as it's current structured, the invitation is just a
> URL. Using standard URL-based and DNS-based methods seems best:
>
> 1. Strip off the room name (path) and the URL scheme to get the domain
> 2. Query the domain (via SRV) about where to gain guest network access
>
>
What does this URL look like?

I'm assuming that the inviter knows that the invitee needs guest access, in
which case the invitation URL can presumably encode what's needed, even if
it's just a "guest domain" to be looked up in the normal manner. Or even if
it's an HTTP URL which derefs for more extensive information.

Dave.

Re: [Standards] guest access

[Kim Alvefur]

fre jun 26 16:45:56 2015 GMT+0200 skrev Peter Saint-Andre - &yet:
> >> Sure, you need to do the SRV two-step.
> >
> > I'm not sure I understand completely, then. Are you proposing that the
> > target of the SRV record is the XMPP host (and thus ignore the port?)?
> 
> I'm not sure I understand completely either. :-)
> 
> We'll probably do something like this:
> 
> _xmpp-client._tcp.talky.io. 400 IN SRV 20 0 5222 auth.talky.io
> _xmpp-guest._tcp.talky.io. 400 IN SRV 20 0 5222 anon.talky.io
> 
> Naturally the ports might not be 5222 and such, but the general idea is 
> that we want to point guest users at a different auth service. By "SRV 
> two-step" I mean that the client would still need to resolve 
> auth.talky.io or anon.talky.io in the normal ways (we're not necessarily 
> going to point directly to what in draft-ietf-dane-srv we called the 
> "connection endpoint").

Surely there must be something more appropriate? Eg PTR or such. 

Or you might advertise something in-band.

Or why not advertise SASL ANONYMOUS and bind then in a different host? So that 
you connect to example.com but are given a jid on anon.example.com during 
resource binding. 

--
Kin Alvefur

Re: [Standards] guest access

On 6/26/15 6:46 AM, Matthew Wild wrote:

On 26 June 2015 at 13:38, Peter Saint-Andre - &yet  wrote:

On 6/26/15 5:26 AM, Matthew Wild wrote:


On 26 June 2015 at 00:51, Peter Saint-Andre - &yet 
wrote:

Thus we need a way for a client to discover where it can authenticate as
an
ad-hoc or guest user. We don't want to use a DNS SRV Service name of
"xmpp-client" because that will point clients to the service endpoint for
registered users. What we came up with was to use a new DNS SRV Service
name
of "xmpp-guest", which would point to the service endpoint for guest
access.

Has anyone else deployed this kind of pattern? If so, how did you solve
the
problem of service endpoint discovery? Would you find it helpful to have
a
DNS SRV Service name for this kind of access?



Would a TXT record not be more appropriate?



Not according to IETF folks. There's a real animus against TXT records for
SRV-ish things (and this seems like one of them).


Containing the XMPP host
of a suitable place to authenticate anonymously? A SRV will tell you
where to connect to, but not which XMPP host to use.



Sure, you need to do the SRV two-step.


I'm not sure I understand completely, then. Are you proposing that the
target of the SRV record is the XMPP host (and thus ignore the port?)?


I'm not sure I understand completely either. :-)

We'll probably do something like this:

   _xmpp-client._tcp.talky.io. 400 IN SRV 20 0 5222 auth.talky.io
   _xmpp-guest._tcp.talky.io. 400 IN SRV 20 0 5222 anon.talky.io

Naturally the ports might not be 5222 and such, but the general idea is 
that we want to point guest users at a different auth service. By "SRV 
two-step" I mean that the client would still need to resolve 
auth.talky.io or anon.talky.io in the normal ways (we're not necessarily 
going to point directly to what in draft-ietf-dane-srv we called the 
"connection endpoint").


Peter

--
Peter Saint-Andre
https://andyet.com/

Re: [Standards] guest access

[Matthew Wild]

On 26 June 2015 at 13:38, Peter Saint-Andre - &yet  wrote:
> On 6/26/15 5:26 AM, Matthew Wild wrote:
>>
>> On 26 June 2015 at 00:51, Peter Saint-Andre - &yet 
>> wrote:
>>> Thus we need a way for a client to discover where it can authenticate as
>>> an
>>> ad-hoc or guest user. We don't want to use a DNS SRV Service name of
>>> "xmpp-client" because that will point clients to the service endpoint for
>>> registered users. What we came up with was to use a new DNS SRV Service
>>> name
>>> of "xmpp-guest", which would point to the service endpoint for guest
>>> access.
>>>
>>> Has anyone else deployed this kind of pattern? If so, how did you solve
>>> the
>>> problem of service endpoint discovery? Would you find it helpful to have
>>> a
>>> DNS SRV Service name for this kind of access?
>>
>>
>> Would a TXT record not be more appropriate?
>
>
> Not according to IETF folks. There's a real animus against TXT records for
> SRV-ish things (and this seems like one of them).
>
>> Containing the XMPP host
>> of a suitable place to authenticate anonymously? A SRV will tell you
>> where to connect to, but not which XMPP host to use.
>
>
> Sure, you need to do the SRV two-step.

I'm not sure I understand completely, then. Are you proposing that the
target of the SRV record is the XMPP host (and thus ignore the port?)?

>> TXT gives you
>> both (because you can proceed with the usual SRV lookups for the guest
>> host, once you know it).
>>
>> If you're using the same XMPP host for non-guest and guest, I don't
>> see the need for an extra DNS record. I don't see a use-case for for
>> non-guest and guest on the same XMPP host but different network hosts
>
>
> To my mind, it's about separation of concerns - I'd rather not mix my
> anonymous users with my registered users.

That aspect I understand and agree with completely.

>> (just use clustering(TM)).
>
> Given that we're using Prosody, I suppose I'll take up *that* topic in the
> Prosody chatroom. ;-)

Any time :)

Regards,
Matthew

Re: [Standards] guest access

On 6/26/15 5:57 AM, Dave Cridland wrote:



On 26 June 2015 at 00:51, Peter Saint-Andre - &yet mailto:pe...@andyet.net>> wrote:

Lance Stout and I had a conversation the other day about what we
call "guest access" to an XMPP application. As example, consider a
chat service (text, video, what have you) that has registered users
and the ability for registered users to invite ad-hoc users to a
session or meeting. This kind of functionality is quite common with
applications like video conferencing (Talky, Jitsi Meet, WebEx, etc.).

If this kind of application is based on XMPP, the invited user needs
to gain access to the network (i.e., authenticate somehow) in order
to join the conference. However, for security and scaling reasons it
makes sense to have these ad-hoc users authenticate at a different
place than the registered users. (Often, but not always, the ad-hoc
users might "authenticate" using the SASL ANONYMOUS mechanism, but
other methods are possible such as token auth.)

Thus we need a way for a client to discover where it can
authenticate as an ad-hoc or guest user. We don't want to use a DNS
SRV Service name of "xmpp-client" because that will point clients to
the service endpoint for registered users. What we came up with was
to use a new DNS SRV Service name of "xmpp-guest", which would point
to the service endpoint for guest access.


Can't the invitation include the connection detail?


At least for Talky as it's current structured, the invitation is just a 
URL. Using standard URL-based and DNS-based methods seems best:


1. Strip off the room name (path) and the URL scheme to get the domain
2. Query the domain (via SRV) about where to gain guest network access

Peter

--
Peter Saint-Andre
https://andyet.com/

Re: [Standards] guest access

On 6/26/15 5:26 AM, Matthew Wild wrote:

On 26 June 2015 at 00:51, Peter Saint-Andre - &yet  wrote:

Lance Stout and I had a conversation the other day about what we call "guest
access" to an XMPP application. As example, consider a chat service (text,
video, what have you) that has registered users and the ability for
registered users to invite ad-hoc users to a session or meeting. This kind
of functionality is quite common with applications like video conferencing
(Talky, Jitsi Meet, WebEx, etc.).

If this kind of application is based on XMPP, the invited user needs to gain
access to the network (i.e., authenticate somehow) in order to join the
conference. However, for security and scaling reasons it makes sense to have
these ad-hoc users authenticate at a different place than the registered
users. (Often, but not always, the ad-hoc users might "authenticate" using
the SASL ANONYMOUS mechanism, but other methods are possible such as token
auth.)

Thus we need a way for a client to discover where it can authenticate as an
ad-hoc or guest user. We don't want to use a DNS SRV Service name of
"xmpp-client" because that will point clients to the service endpoint for
registered users. What we came up with was to use a new DNS SRV Service name
of "xmpp-guest", which would point to the service endpoint for guest access.

Has anyone else deployed this kind of pattern? If so, how did you solve the
problem of service endpoint discovery? Would you find it helpful to have a
DNS SRV Service name for this kind of access?


Would a TXT record not be more appropriate?


Not according to IETF folks. There's a real animus against TXT records 
for SRV-ish things (and this seems like one of them).



Containing the XMPP host
of a suitable place to authenticate anonymously? A SRV will tell you
where to connect to, but not which XMPP host to use.


Sure, you need to do the SRV two-step.


TXT gives you
both (because you can proceed with the usual SRV lookups for the guest
host, once you know it).

If you're using the same XMPP host for non-guest and guest, I don't
see the need for an extra DNS record. I don't see a use-case for for
non-guest and guest on the same XMPP host but different network hosts


To my mind, it's about separation of concerns - I'd rather not mix my 
anonymous users with my registered users.



(just use clustering(TM)).


Given that we're using Prosody, I suppose I'll take up *that* topic in 
the Prosody chatroom. ;-)



Finally, if we were to use TXT, then maybe this is a candidate for
inclusion in XEP-0156?


If we were to use TXT, yes.

Peter

--
Peter Saint-Andre
https://andyet.com/

Re: [Standards] guest access

[Dave Cridland]

On 26 June 2015 at 00:51, Peter Saint-Andre - &yet  wrote:

> Lance Stout and I had a conversation the other day about what we call
> "guest access" to an XMPP application. As example, consider a chat service
> (text, video, what have you) that has registered users and the ability for
> registered users to invite ad-hoc users to a session or meeting. This kind
> of functionality is quite common with applications like video conferencing
> (Talky, Jitsi Meet, WebEx, etc.).
>
> If this kind of application is based on XMPP, the invited user needs to
> gain access to the network (i.e., authenticate somehow) in order to join
> the conference. However, for security and scaling reasons it makes sense to
> have these ad-hoc users authenticate at a different place than the
> registered users. (Often, but not always, the ad-hoc users might
> "authenticate" using the SASL ANONYMOUS mechanism, but other methods are
> possible such as token auth.)
>
> Thus we need a way for a client to discover where it can authenticate as
> an ad-hoc or guest user. We don't want to use a DNS SRV Service name of
> "xmpp-client" because that will point clients to the service endpoint for
> registered users. What we came up with was to use a new DNS SRV Service
> name of "xmpp-guest", which would point to the service endpoint for guest
> access.
>

Can't the invitation include the connection detail?

Dave.

Re: [Standards] guest access

[Matthew Wild]

On 26 June 2015 at 00:51, Peter Saint-Andre - &yet  wrote:
> Lance Stout and I had a conversation the other day about what we call "guest
> access" to an XMPP application. As example, consider a chat service (text,
> video, what have you) that has registered users and the ability for
> registered users to invite ad-hoc users to a session or meeting. This kind
> of functionality is quite common with applications like video conferencing
> (Talky, Jitsi Meet, WebEx, etc.).
>
> If this kind of application is based on XMPP, the invited user needs to gain
> access to the network (i.e., authenticate somehow) in order to join the
> conference. However, for security and scaling reasons it makes sense to have
> these ad-hoc users authenticate at a different place than the registered
> users. (Often, but not always, the ad-hoc users might "authenticate" using
> the SASL ANONYMOUS mechanism, but other methods are possible such as token
> auth.)
>
> Thus we need a way for a client to discover where it can authenticate as an
> ad-hoc or guest user. We don't want to use a DNS SRV Service name of
> "xmpp-client" because that will point clients to the service endpoint for
> registered users. What we came up with was to use a new DNS SRV Service name
> of "xmpp-guest", which would point to the service endpoint for guest access.
>
> Has anyone else deployed this kind of pattern? If so, how did you solve the
> problem of service endpoint discovery? Would you find it helpful to have a
> DNS SRV Service name for this kind of access?

Would a TXT record not be more appropriate? Containing the XMPP host
of a suitable place to authenticate anonymously? A SRV will tell you
where to connect to, but not which XMPP host to use. TXT gives you
both (because you can proceed with the usual SRV lookups for the guest
host, once you know it).

If you're using the same XMPP host for non-guest and guest, I don't
see the need for an extra DNS record. I don't see a use-case for for
non-guest and guest on the same XMPP host but different network hosts
(just use clustering(TM)).

Finally, if we were to use TXT, then maybe this is a candidate for
inclusion in XEP-0156?

Regards,
Matthew

Re: [Standards] guest access

[Kevin Smith]

On 26 Jun 2015, at 00:51, Peter Saint-Andre - &yet  wrote:
> 
> Lance Stout and I had a conversation the other day about what we call "guest 
> access" to an XMPP application. As example, consider a chat service (text, 
> video, what have you) that has registered users and the ability for 
> registered users to invite ad-hoc users to a session or meeting. This kind of 
> functionality is quite common with applications like video conferencing 
> (Talky, Jitsi Meet, WebEx, etc.).
> 
> If this kind of application is based on XMPP, the invited user needs to gain 
> access to the network (i.e., authenticate somehow) in order to join the 
> conference. However, for security and scaling reasons it makes sense to have 
> these ad-hoc users authenticate at a different place than the registered 
> users. (Often, but not always, the ad-hoc users might "authenticate" using 
> the SASL ANONYMOUS mechanism, but other methods are possible such as token 
> auth.)
> 
> Thus we need a way for a client to discover where it can authenticate as an 
> ad-hoc or guest user. We don't want to use a DNS SRV Service name of 
> "xmpp-client" because that will point clients to the service endpoint for 
> registered users. What we came up with was to use a new DNS SRV Service name 
> of "xmpp-guest", which would point to the service endpoint for guest access.
> 
> Has anyone else deployed this kind of pattern? If so, how did you solve the 
> problem of service endpoint discovery? Would you find it helpful to have a 
> DNS SRV Service name for this kind of access?
> 
> If there is wide enough interest, I'd be happy to write a spec and pursue 
> registration of the service name with our friends at IANA.

I guess the two options are either another SRV entry, or using the standard 
client endpoint and then advertising after connection.

I know a surprising number of people have issues with SRV, so that’s an 
argument in favour of doing a redirection in stream:features or the like, but 
SRV is the neater solution, I think.

/K

Re: [Standards] guest access

[Peter Saint-Andre]

> On Jun 25, 2015, at 8:13 PM, Bernard Aboba  wrote:
> 
> 
> 
> 
> 
>> On Jun 25, 2015, at 4:51 PM, Peter Saint-Andre - &yet  
>> wrote:
>> 
>> Has anyone else deployed this kind of pattern? If so, how did you solve the 
>> problem of service endpoint discovery?
> 
> [BA] For WebRTC apps, the "guest service" is typically configured on the web 
> server (e.g. In a config.js file) and pushed down to the WebRTC JS app,

Sorry, I should have mentioned that Lance and I were thinking about mobile 
apps, not web apps. 

Peter

Re: [Standards] guest access

[Bernard Aboba]

> On Jun 25, 2015, at 4:51 PM, Peter Saint-Andre - &yet  
> wrote:
> 
> Has anyone else deployed this kind of pattern? If so, how did you solve the 
> problem of service endpoint discovery? 

[BA] For WebRTC apps, the "guest service" is typically configured on the web 
server (e.g. In a config.js file) and pushed down to the WebRTC JS app, so no 
discovery is required. 

[Standards] guest access

Lance Stout and I had a conversation the other day about what we call 
"guest access" to an XMPP application. As example, consider a chat 
service (text, video, what have you) that has registered users and the 
ability for registered users to invite ad-hoc users to a session or 
meeting. This kind of functionality is quite common with applications 
like video conferencing (Talky, Jitsi Meet, WebEx, etc.).


If this kind of application is based on XMPP, the invited user needs to 
gain access to the network (i.e., authenticate somehow) in order to join 
the conference. However, for security and scaling reasons it makes sense 
to have these ad-hoc users authenticate at a different place than the 
registered users. (Often, but not always, the ad-hoc users might 
"authenticate" using the SASL ANONYMOUS mechanism, but other methods are 
possible such as token auth.)


Thus we need a way for a client to discover where it can authenticate as 
an ad-hoc or guest user. We don't want to use a DNS SRV Service name of 
"xmpp-client" because that will point clients to the service endpoint 
for registered users. What we came up with was to use a new DNS SRV 
Service name of "xmpp-guest", which would point to the service endpoint 
for guest access.


Has anyone else deployed this kind of pattern? If so, how did you solve 
the problem of service endpoint discovery? Would you find it helpful to 
have a DNS SRV Service name for this kind of access?


If there is wide enough interest, I'd be happy to write a spec and 
pursue registration of the service name with our friends at IANA.


Thanks,

Peter

--
Peter Saint-Andre
https://andyet.com/