[Standards] Proposed XMPP Extension: References

[XMPP Extensions Editor]

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: References

Abstract: This document defines XMPP protocol for multi-user chat for text 
messages and sharing other information such as images.   The protocol includes 
core chatroom features such as room topics and invitations and defines a strong 
room control model, including the ability to kick and ban users, to name room 
moderators and administrators, to require membership or passwords in order to 
join the room.  The protocol aims to maximise use of standard XMPP building 
blocks and in particular makes use of PubSub and MAM.

URL: http://xmpp.org/extensions/inbox/references.html

The XMPP Council will decide in the next two weeks whether to accept this 
proposal as an official XEP.

___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Token-based reconnection

[Sam Whited]

Oops, hit send early. Another point:

> a regular XMPP authentication mechanism like SCRAM-SHA-1 or DIGEST-MD5

DIGEST-MD5 is old, broken, and we're having a hard enough time getting
rid of it as is. While I'm aware that this statement isn't an
endorsement of DIGEST-MD5 (I hope), I feel that we shouldn't reference
it in the hopes that it will eventually go away.

A bit of a nit pick, I know, but I'd like to remove the reference from
new XEPs lest someone reads it as a recommendation.

Best,
Sam

On Fri, Feb 5, 2016 at 10:15 AM, XMPP Extensions Editor  wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Token-based reconnection
>
> Abstract: This specification defines a token-based session authentication 
> mechanism similar to OAuth.
>
> URL: http://xmpp.org/extensions/inbox/token-reconnection.html
>
> The XMPP Council will decide in the next two weeks whether to accept this 
> proposal as an official XEP.
>
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___



-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Token-based reconnection

[Sam Whited]

> This specification defines a token-based session authentication mechanism 
> similar to OAuth.


The token based reconnect can be used with any token (eg. JWT tokens,
which are valid oauth tokens, are given as an example below), if I'm
understanding the intent behind this spec correctly. The reference to
a specific token format should probably be removed from the abstract.

With my work hat off, we may have some interest in implementing this
at HipChat since we do something very similar (but with oauth tokens)
with our existing web-based clients, and use JWT tokens for auth with
other Atlassian services. Will advise in a more official capacity
after I've reviwed this more.

Thanks!

Best,
Sam


On Fri, Feb 5, 2016 at 10:15 AM, XMPP Extensions Editor  wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Token-based reconnection
>
> Abstract: This specification defines a token-based session authentication 
> mechanism similar to OAuth.
>
> URL: http://xmpp.org/extensions/inbox/token-reconnection.html
>
> The XMPP Council will decide in the next two weeks whether to accept this 
> proposal as an official XEP.
>
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___



-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Token-based reconnection

[Thijs Alkemade]

> On 5 feb. 2016, at 17:15, XMPP Extensions Editor  wrote:
> 
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Token-based reconnection
> 
> Abstract: This specification defines a token-based session authentication 
> mechanism similar to OAuth.
> 
> URL: http://xmpp.org/extensions/inbox/token-reconnection.html
> 
> The XMPP Council will decide in the next two weeks whether to accept this 
> proposal as an official XEP.

As it is currently written this looks like a rather bad idea to me, or at
least needs a much longer Security Considerations section than it currently
has.

SCRAM offers protection from replay-attacks, mutual authentication and
optionally channel binding. Not only does this specification give up on all of
those, but it also makes it trivial for an active attacker to cause a
reconnection where SCRAM will be downgraded to this. One of suggestion to fix
is by requiring the client to verify that the server's certificate is
unchanged.

Other comments:

* It's named "X-OAUTH". How does it compare to RFC 7628?

* It should probably have a disco feature so the client can determine whether
  it can retrieve a token.

Regards,
Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Proposed XMPP Extension: Multi-stage IBR

[XMPP Extensions Editor]

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Multi-stage IBR

Abstract: This specification defines an augmentation of In-Band Registration to 
allow for multiple stages of user input.

URL: http://xmpp.org/extensions/inbox/multistage-ibr.html

The XMPP Council will decide in the next two weeks whether to accept this 
proposal as an official XEP.

___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Multi-stage IBR

[Dave Cridland]

On 5 February 2016 at 16:14, XMPP Extensions Editor  wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Multi-stage IBR
>
> Abstract: This specification defines an augmentation of In-Band
> Registration to allow for multiple stages of user input.
>
> URL: http://xmpp.org/extensions/inbox/multistage-ibr.html
>
> The XMPP Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
>
>
First, the good news:

This is important and necessary work, and it's great to see someone come to
the XSF with a solid idea and bring it through to a proposal for a XEP so
quickly.

Now the critique...

Firstly, this is altering a Final XEP via the backdoor, by reusing the same
XML namespace for an altered protocol. This is trivial to fix - just use a
different namespace - but in its current form I'll have to veto it.

Secondly, I expect there to be resistance to using a hardcoded set of
elements rather than a form. I dislike using forms everywhere - I think
they're best used only when human interaction is expected, rather than as a
solution to every case of extensibility, but I think this is a case where
we are not only expecting, but ideally requiring, the process to be
human-driven.

Thirdly, my gut feeling is that once you swap the hardcoded element set
with forms, it'll look remarkably like XEP-0050. XEP-0050 works for *most*
cases where we use the old XEP-0077 protocol - registration for chatrooms
and gateways - but it won't work for account registration. This is because
you'd have to process ad-hoc commands in the pre-auth state, and any IQ
processing is already a scary proposition at that point from a security
standpoint.

Of course, maybe we don't need account registration anymore, or maybe we
can figure out a better pattern.

Dave.
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Token-based reconnection

[Thijs Alkemade]

> On 5 feb. 2016, at 20:04, Lance Stout  wrote:
> 
> 3) This does not really decrease the initial authentication and subsequent
> stream setup time. It is still using the full SASL process, so time wise
> it is exactly the same as PLAIN. It is exactly one round trip faster than
> SCRAM-SHA-1. It does use less hashing, which I agree can have a noticeable
> delay in some browsers; however, the derived materials generated during
> SCRAM-SHA-1 can be cached to significantly reduce the calculation time
> for subsequent logins, and also serve as a secure replacement for the
> plaintext password (which is also revokable by the server using a new salt).

I agree with most of your points, however, the salt can only be changed by the
server if the server is not using hashed storage. If the server stores only
ServerKey and StoredKey (plus the salt and iteration count) it can not change
the salt without downgrading to PLAIN or resetting the user's password. I
think the iteration count can be increased with hashed storage, but I'm not
100% sure.

Provided the client has cached the ClientKey and StoredKey the only intensive
computations are 3 times HMAC-SHA1. This will likely be negligible even on
phones.

Regards,
Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Multi-stage IBR

[Stephen Paul Weber]

Firstly, this is altering a Final XEP via the backdoor, by reusing the  
same  XML namespace for an altered protocol. This is trivial to fix - just 
use a different namespace


This is barely an alteration.  In fact, I originally thought this would work 
with XEP-0070 until is seemed no client implemented this.


If we used a different namespace, we'd lose the backwards-compatability, 
which I think would be pretty unfortunate.



Secondly, I expect there to be resistance to using a hardcoded set of
elements rather than a form.


There's no intent on my part that this be "rather than a form".  
I explicitly copied the " If the host requires additional information above 
and beyond the data elements specified in the schema, it SHOULD use Data 
Forms as described in the Extensibility section of XEP-0077. " -- 
realistically I expect many implementations to use forms (most that I see 
already do for XEP-0077), but to keep it compatible as an extension of 
XEP-0077 of course one would need to support both.  Since this isn't really 
a protocol-level change, just an interpretation change.



Thirdly, my gut feeling is that once you swap the hardcoded element set
with forms, it'll look remarkably like XEP-0050. XEP-0050 works for *most*
cases where we use the old XEP-0077 protocol - registration for chatrooms
and gateways


I'm unclear on where XEP-0050 fits in to the picture for structured 
interactions like this.  Registering (either with a server or with 
a gateway) isn't an "adhoc" command, but rather a known command that clients 
want to provide specific UI for (that is, it's not just in a big list of 
"commands the entity supports" as with the normal UI for XEP-0050).  Perhaps 
there could be (or is?) a registry of "well known" ad-hoc commands that 
clients could check for the support of and omit from the normal XEP-0050 UI 
and provide seperate UI for them?  If that makes sense.


signature.asc
Description: Digital signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___