Re: [Standards] A new SASL Profile strawman

[Alexey Melnikov]

On 04/05/2016 22:58, Peter Saint-Andre wrote:

On 5/4/16 8:00 AM, Dave Cridland wrote:

Folks,

I had a nice chat with Ralph Meijer, and we idly discussed replacing the
SASL profile in order to gain access to 2FA, fold in the Stream
Resumption (Florian Schmaus's design, in effect), and make it a little
more extensible, particularly with more detailed error messaging.

Since then I've found some fo these might be being addressed by work
Adam Roach and Matthew Miller are doing,


Got a pointer to that work?

Doing this work (eventually) at the IETF might make the most sense, 
but what makes even more sense is making sure that implementers are on 
board with whatever approach we come up with.

+1.

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

Re: [Standards] A new SASL Profile strawman

[Peter Saint-Andre]

On 5/4/16 8:00 AM, Dave Cridland wrote:

Folks,

I had a nice chat with Ralph Meijer, and we idly discussed replacing the
SASL profile in order to gain access to 2FA, fold in the Stream
Resumption (Florian Schmaus's design, in effect), and make it a little
more extensible, particularly with more detailed error messaging.

Since then I've found some fo these might be being addressed by work
Adam Roach and Matthew Miller are doing,


Got a pointer to that work?

Doing this work (eventually) at the IETF might make the most sense, but 
what makes even more sense is making sure that implementers are on board 
with whatever approach we come up with.


Peter


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

Re: [Standards] A new SASL Profile strawman

[Dave Cridland]

On 4 May 2016 at 21:16, Ralph Meijer  wrote:

>
>
> On 04-05-16 20:45, Lance Stout wrote:
>
>>
>> On May 4, 2016, at 7:00 AM, Dave Cridland  wrote:
>>>
>>> Folks,
>>>
>>> I had a nice chat with Ralph Meijer, and we idly discussed replacing the
>>> SASL profile in order to gain access to 2FA, fold in the Stream Resumption
>>> (Florian Schmaus's design, in effect), and make it a little more
>>> extensible, particularly with more detailed error messaging.
>>>
>>>
>> The basic proposal here looks sensible to me, and support for 2FA would
>> be awesome. However, it does carry the cost of needing to upgrade one of
>> the fundamental parts of XMPP session negotiation.
>>
>> To be honest, if any such price is to be paid, I want it to bring
>> significant benefits that can simplify the startup process.
>>
>
> While Dave proposes an entirely new namespace for this, I believe that
> all of the new features could be done by extending the current
> functionality:
>
>  * The new attributes could be used as-is on the current  and
> elements.
>
>  * Instead of having , you'd have to use  more
>creatively:
>
> * Introduce a new defined condition  (or somesuch).
>
> * Allow for meta-data of this condition, to hold the
>   optional success data and mechanisms for the next step, either
>   as child-elements or as an application-specific condition element.
>
> * If we would start allowing application-specific error conditions,
>   we could use  as the main condition.
>   Unfortunately that is currently defined to only be in response to
>   an  request, and not after .
>
> * After this 'failure', the next step would simply be a new round
>   starting with .
>
>
> The down-side of this might be that we need to do this work at the IETF.
>
>
I think the other downside is that it's getting pretty hacky - but even the
strawman I proposed would need to be run through the IETF, probably. This
is all very much RFC territory.


> Dave and I also discussed doing (just) 2FA from within new SASL
> mechanisms, but for me that has some downsides:
>
>  * Harder to reuse existing implementations of mechanisms, as you need
>to somehow wrap the exchanges.
>
>  * Often, a server will determine the need for another factor only
>*after* completing the first one, based on the verified identity. So
>a server cannot advertise such wrapping mechanism, nor can the client
>choose this if presented with it.
>
> In practice, uou are quickly building a protocol within a mechanism.
>
>
> The proposal is already tying itself to stream management, so let's push
>> that further:
>>
>> 1. Opting to use new-SASL is also enabling stream management. This seems
>> to be implied already for the proposal to meet its goals, but it would need
>> to be more explicit.
>>
>
> Yeah, this might be a bit weird. I wonder if, instead, we could do the
> stream management exchange around SASL like so:
>
>   C: 
>
>   C: 
>   [..]
>   S: 
>
>   C: 
>   S: 
>   S: 
>   S: 
>
> Maybe with some indicator that the client knows that it has to complete
> SASL before resumption is acknowledged. I am thinking of an attribute on
>  to that effect. This way, it could all still be a single round
> trip.
>
>
> 2. JID binding included in new-SASL success response, so no need to
>> manually request a binding (maybe even go so far as to not allow requesting
>> a resource, just be assigned one)
>>
>
> Even though people have suggested that client-chosen resource is a bad
> idea, I haven't seen compelling argument for it yet. A stable identifier
> for specific client instances still seems like a valid use-case to me.
> Also note that this is a all Core, so isn't specific to IM-type
> applications.
>
> If you are saying that one shouldn't need / be able to bind a resource
> when resuming a session, I fully agree. I expect switching resources for
> a resumed session yields all kinds of weird issues.
>
>
> Yes, this combines several existing, but related, stream features. This
>> combination of features is one of the most well-trod of cow paths, and is
>> what inflates the number of round-trip requests needed to start a usable
>> session.
>>
>
> Agreed.
>
> --
> Cheers,
>
> ralphm
>
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] A new SASL Profile strawman

[Ralph Meijer]

On 04-05-16 20:45, Lance Stout wrote:



On May 4, 2016, at 7:00 AM, Dave Cridland  wrote:

Folks,

I had a nice chat with Ralph Meijer, and we idly discussed replacing the SASL 
profile in order to gain access to 2FA, fold in the Stream Resumption (Florian 
Schmaus's design, in effect), and make it a little more extensible, 
particularly with more detailed error messaging.



The basic proposal here looks sensible to me, and support for 2FA would be 
awesome. However, it does carry the cost of needing to upgrade one of the 
fundamental parts of XMPP session negotiation.

To be honest, if any such price is to be paid, I want it to bring significant 
benefits that can simplify the startup process.


While Dave proposes an entirely new namespace for this, I believe that
all of the new features could be done by extending the current
functionality:

 * The new attributes could be used as-is on the current  and
elements.

 * Instead of having , you'd have to use  more
   creatively:

* Introduce a new defined condition  (or somesuch).

* Allow for meta-data of this condition, to hold the
  optional success data and mechanisms for the next step, either
  as child-elements or as an application-specific condition element.

* If we would start allowing application-specific error conditions,
  we could use  as the main condition.
  Unfortunately that is currently defined to only be in response to
  an  request, and not after .

* After this 'failure', the next step would simply be a new round
  starting with .


The down-side of this might be that we need to do this work at the IETF.

Dave and I also discussed doing (just) 2FA from within new SASL
mechanisms, but for me that has some downsides:

 * Harder to reuse existing implementations of mechanisms, as you need
   to somehow wrap the exchanges.

 * Often, a server will determine the need for another factor only
   *after* completing the first one, based on the verified identity. So
   a server cannot advertise such wrapping mechanism, nor can the client
   choose this if presented with it.

In practice, uou are quickly building a protocol within a mechanism.



The proposal is already tying itself to stream management, so let's push that 
further:

1. Opting to use new-SASL is also enabling stream management. This seems to be 
implied already for the proposal to meet its goals, but it would need to be 
more explicit.


Yeah, this might be a bit weird. I wonder if, instead, we could do the
stream management exchange around SASL like so:

  C: 

  C: 
  [..]
  S: 

  C: 
  S: 
  S: 
  S: 

Maybe with some indicator that the client knows that it has to complete
SASL before resumption is acknowledged. I am thinking of an attribute on
 to that effect. This way, it could all still be a single round
trip.



2. JID binding included in new-SASL success response, so no need to manually 
request a binding (maybe even go so far as to not allow requesting a resource, 
just be assigned one)


Even though people have suggested that client-chosen resource is a bad
idea, I haven't seen compelling argument for it yet. A stable identifier
for specific client instances still seems like a valid use-case to me.
Also note that this is a all Core, so isn't specific to IM-type
applications.

If you are saying that one shouldn't need / be able to bind a resource
when resuming a session, I fully agree. I expect switching resources for
a resumed session yields all kinds of weird issues.



Yes, this combines several existing, but related, stream features. This 
combination of features is one of the most well-trod of cow paths, and is what 
inflates the number of round-trip requests needed to start a usable session.


Agreed.

--
Cheers,

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

Re: [Standards] A new SASL Profile strawman

[Dave Cridland]

On 4 May 2016 at 19:45, Lance Stout  wrote:

>
> > On May 4, 2016, at 7:00 AM, Dave Cridland  wrote:
> >
> > Folks,
> >
> > I had a nice chat with Ralph Meijer, and we idly discussed replacing the
> SASL profile in order to gain access to 2FA, fold in the Stream Resumption
> (Florian Schmaus's design, in effect), and make it a little more
> extensible, particularly with more detailed error messaging.
> >
>
>
> The basic proposal here looks sensible to me, and support for 2FA would be
> awesome. However, it does carry the cost of needing to upgrade one of the
> fundamental parts of XMPP session negotiation.
>
>
Yes, indeed.


>
> To be honest, if any such price is to be paid, I want it to bring
> significant benefits that can simplify the startup process.
>
>
The (possibly hopeful) intention is that we should be able to "tack on"
other startup costs into the same exchange.


>
> The proposal is already tying itself to stream management, so let's push
> that further:
>
> 1. Opting to use new-SASL is also enabling stream management. This seems
> to be implied already for the proposal to meet its goals, but it would need
> to be more explicit.
>

Seems entirely reasonable; though we could simply make the negotiation
explicit.


> 2. JID binding included in new-SASL success response, so no need to
> manually request a binding (maybe even go so far as to not allow requesting
> a resource, just be assigned one)
>
>
Great idea! And one that proves the initial extensibility isn't there, too.
However, I'll resist having entirely server-assigned resource strings.
There's a number of cases where not having the client able to specify a
resource string makes things much more complex (and introduces round-trips,
in fact).

Perhaps if we add an inner element to  and
 to enclose the initial response?

Something like:


  
SW1wcm92ZWQgZW5jYXNwdWxhdGlvbiBvZiBvcHRpb25hbCBTQVNMLUlSIGRhdGE=
  


Then the bind request can be embedded in with the :


  
U0FTTC1JUiBlbmNvZGVkIGFsb25nc2lkZSBiaW5kIHJlcXVlc3Q=
  
  Office


We'd want the bind result to be embedded into the  and/or
.


>
> Yes, this combines several existing, but related, stream features. This
> combination of features is one of the most well-trod of cow paths, and is
> what inflates the number of round-trip requests needed to start a usable
> session.
>
>
Summarizing the chat Lance and I had over IM:

- Lance wasn't clear there was any point in offering a list of next
mechanisms in , I suggested that only having one was probably
the usual case but it didn't hurt to have the capability for multiple
options.
- Lance also suggested that having a  indicator for why the continue
was requested would be useful. We may have to think this through if there's
multiple next mechanism choices.
- We agreed that at the  and  points, the client
should be told its bare jid (and maybe full in the bind case).

Dave.


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

Re: [Standards] A new SASL Profile strawman

[Lance Stout]

> On May 4, 2016, at 7:00 AM, Dave Cridland  wrote:
> 
> Folks,
> 
> I had a nice chat with Ralph Meijer, and we idly discussed replacing the SASL 
> profile in order to gain access to 2FA, fold in the Stream Resumption 
> (Florian Schmaus's design, in effect), and make it a little more extensible, 
> particularly with more detailed error messaging.
> 


The basic proposal here looks sensible to me, and support for 2FA would be 
awesome. However, it does carry the cost of needing to upgrade one of the 
fundamental parts of XMPP session negotiation.


To be honest, if any such price is to be paid, I want it to bring significant 
benefits that can simplify the startup process.


The proposal is already tying itself to stream management, so let's push that 
further:

1. Opting to use new-SASL is also enabling stream management. This seems to be 
implied already for the proposal to meet its goals, but it would need to be 
more explicit.
2. JID binding included in new-SASL success response, so no need to manually 
request a binding (maybe even go so far as to not allow requesting a resource, 
just be assigned one)


Yes, this combines several existing, but related, stream features. This 
combination of features is one of the most well-trod of cow paths, and is what 
inflates the number of round-trip requests needed to start a usable session.


/Lance


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

Re: [Standards] A new SASL Profile strawman

[Adam Roach]

Dave Cridland wrote:


Since then I've found some fo these might be being addressed by work Adam
Roach and Matthew Miller are doing, so I thought I'd jot down a very
ill-thought-through design - it may very well be that Adam/M's design is
far superior, or it may be that we can borrow from each other to produce
something else. I'm not expecting this to be anything more than a
discussion starter.



To be clear: in my earlier comment, I meant to convey that we were 
working in the general space of XMPP security, not with authentication 
in particular. We don't have a proposal that fills the same niche you're 
looking at. :)


Some of our discussions have dealt with pseudonyms and anonymous 
identifiers, which may interact with what you're thinking of doing (I 
actually haven't had time to look at it yet); and it was on that front 
that I thought we should maybe touch base.


I'll be sure to ping you when we start moving the ball forward again.

/a

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