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] MUC2 - The case for removing semi-anonymous

[Dave Cridland]

On 26 Jun 2015 07:24, "Steve Kille"  wrote:
>
> >
> > I would like us to Get This Right, though. People have been mumbling
about replacing MUC for years, and I’ve always been resistant;
> > the discussions at the summit this year persuaded me that we finally
have requirements that MUC1 can’t easily meet, but I really do
> > not want us to do MUC2 now and MUC3 in 2017 to fix the stuff we got
wrong in MUC2.
>
> [Steve Kille]
> Kev -  I strongly agree with this goal.
>

I think a key criterion for success will be if MUC2 can meet all commonly
deployed use-cases across both XEP-0045 and other multiparty chat
(including non-XMPP cases).

> It seems to me that the default semi-anonymous MUC1 is generally seen as
"the way MUC works" and is not a conscious option selection choice.
>

It's tempting to go that way, but it's very close to saying "I disagree
with the outcome, so the evidence must be wrong."

The problem is that the only evidence we have as to how desirable this
feature is is the number of chatrooms commonly using it. That *could*
easily be that it's the default in many servers, but that in turn raises
the question of why that's so.

In short, I don't claim to know, but I hesitate to ascribe all such use to
ignorance on behalf of the administrators.

What I can tell you is that when I asked about the Prosody default (it's
semi-anonymous), the response was that "we try to make the defaults privacy
friendly"; this implies that the default, at least, was a conscious choice.

I've a feeling that M-Link defaults the same way for the same reason -
maybe that's changed (and if not, maybe it should).

> I've not seen use where this behaviour seems particularly desirable.   I
have seen significant customer concern about controlling mis-leading use of
nicks and people misrepresenting themselves in MUCs. I suspect that
non-anonymous would be better behaviour for many MUC users, but there has
not been active consideration to use it.
>

So what you're saying is that in all the chatrooms I'm usually in, only the
Openfire project leads have considered how to configure their chatroom? I'd
note for the record that I'm usually present in both Prosody chatrooms and
XSF chatrooms (xsf@ and jdev@), all of which are semi-anonymous. It seems
odd to me that anonymity is such a problem if the administrators there are
content to leave it in place - they're hardly unaware of "the way MUC
works". After all, many of those administrators are on this thread.

I think within government, military, and enterprise, strong identity is an
absolute requirement, but I'd note that "misleading use of nicks and people
misrepresenting themselves in MUCs" is soluble already by nickname
enforcement and registration, as part of XEP-0045. So if your customers are
concerned about that, you should show them that, as well as (of course) the
non-anonymous configuration.

Finally, I'd note that under the semi-anonymous model, both the chatroom
itself and any administrators are fully aware of the real jid of the
occupant, and can act directly upon it - so the scope for abuse is limited
entirely to what the chatroom allows. (Unless the abuse is also possible by
non-anonymous users).

> MUC2 will allow MUCs to allow users to read MUCs without sharing
presence.   This seems a highly desirable option (lots of reasons).   This
option will allow people to read MUCs anonymously, which I think for some
MUCs can be a sensible and desirable privacy option.
>

I don't think that the absence of presence means (or should mean) that
subscriptions are anonymous or invisible. Part of basic privacy would be
being aware of people reading your messages, even those messages to a group.

The only way to read such messages would be if the archive was available to
unsubscribed users.

> I think that if you want to share your presence with the group or send a
message to a group, that enforcing that you also share your jid is highly
desirable.In XMPP the jid is "who you are".   I can't see a clear use
case for allowing people to post to a MUC without clearly identifying
themselves.

I absolutely agree that making non-anonymous "better" is highly desirable.
In a number of markets, and certainly in Isode's and Surevine's, "hiding"
the real jid behind an occupant jid is problematic, and the relative
obscurity of the real jid in MUC means that non-anonymous rooms are
somewhat of a second-class citizen. From a technical standpoint, having the
address of an occupant, and therefore the identity, selected by that
occupant causes a number of issues, including security ones.

However, just because non-anonymous is useful for some markets should not
preclude anonymity for others.

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