Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

2016-03-01 Thread Dave Cridland 
On 1 Mar 2016 10:17 pm, "Florian Schmaus"  wrote:
>
> On 01.03.2016 20:52, Dave Cridland wrote:
> > FWIW, ISR is 1-RTT, unless you pipeline through, which doesn't really
> > count. Calling it 0-RTT is marketing.
>
> Independent on which label you put on that claim, it doesn't change that
> the it is true.
>

If a client sends a stanza prior to receiving the response to an
authentication request, it's doing so prior to channel binding having
completed. That may fit your security model, I suppose.

Certainly the stream hasn't been authenticated or resumed as far as the
client knows until one round trip time later.

TLSv1.3's 0RTT does, in contrast, show the client to safely send
application data prior top the handshake completing.

> > So the main reason I'm thinking of wrapping ISR around SASL is because
> > ISR replaces SASL to some degree, which is where Thijs and Tobias's
> > concerns come from.
>
> The way I see it, is that it does not replace SASL, not even to some
> degree, as SASL is (still) used to authenticate entities. ISR does
> authenticate a stream resumption in an efficient manner.
>

It authenticates the connection, I hope. If it doesn't, we have serious
problems.

> > If you wrap ISR around SASL - and we can discuss removing the stream
> > restart post-SASL in this case, too - then the security properties of
> > the authentication portion of ISR become a matter of choosing the SASL
> > mechanism, which is both vastly simpler to define and also allows us to
> > easy handle things like hash agility.
>
> I deliberately choose to not build ISR on top of SASL. First, I believe
> it's not possible to achieve a zero round trip resumption doing so.

Um. Didn't I demonstrate that in my previous mail? Or at least, the same
number of round trips.

> And
> secondly, it just feels wrong to have the stream in a different state
> after  depending on whether or not ISR is used.
>

Okay. But it feels wrong to me to have different authentication mechanisms.
We don't design authentication mechanisms here. The times we have, like
XEP-0078, haven't ended well.

> > To put it another way, ISR effectively combine the authentication and
> > 198 into one step. Your proposal builds ISR by taking '198, and adding a
> > brand new authentication mechanism. I'm suggesting that it seems
> > worthwhile to explore building it the other way around, so we take SASL
> > and add the '198 bits we need onto that.
>
> I'm looking forward seeing something like that put in a more formal
> specification. But I fear that it won't be able to achieve the same
> properties as ISR, will be a more elegant and/or straightforward solution.
>
> > The net result will be identical, except that the bits most likely to
> > require changing have already-existing discovery and selection.
> >
> > For example, assuming we remove post-SASL stream restarts if ISR is in
> > play, using SASL PLAIN gives the same number of RTTs, and the same
> > security properties, as the original ISR proposal. Using YAP would be
> > 1-RTT with channel binding. Using SCRAM would be 2-RTT, with SASL-level
> > mutual authentication.
>
> That *is not* an identical result. ISR using HMAC and
> tls-server-end-point provides mutual authentication and channel binding
> with a zero round trip resumption [1].
>

The mutual auth from TLS? Sure. But a YAP variant can do that; the last
draft happens to use a different binding, is all.

The main difference with my approach is that if a particular hash algorithm
gets weakened, switching is a well defined process.

> > I think your proposal is trying to be a one-size-fits all approach, and
> > I don't think such an approach is either viable or desirable.
>
> I think most mobile developers using XMPP would disagree. The
> "Token-based reconnection" ProtoXEP was created because of this
> requirement. And I also pointed out [1, p19] that the round trip intense
> session establishment process is an issue for mobile XMPP.
>

I think most mobile developers would like us to design a method of resuming
a stream with the minimal amount of round trips. I also think they'd like
us to think carefully about the security.

> We have SM, CSI, MAM, and soon hopefully MIX. And another important
> building block for mobile friendliness is a zero round trip stream
> resumption mechanism providing good security properties.
>
> - Florian
>
>
> 1: Note that this is not the ISR version submitted as ProtoXEP, but the
> one based on the input from Thijs, which happened after the submission.
> 2:
>
https://archive.fosdem.org/2015/schedule/event/xmpp_and_android/attachments/slides/749/export/events/attachments/xmpp_and_android/slides/749/xmpp_and_android.pdf
>
>
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

2016-03-01 Thread Florian Schmaus 
On 01.03.2016 20:52, Dave Cridland wrote:
> FWIW, ISR is 1-RTT, unless you pipeline through, which doesn't really
> count. Calling it 0-RTT is marketing.

Independent on which label you put on that claim, it doesn't change that
the it is true.

> So the main reason I'm thinking of wrapping ISR around SASL is because
> ISR replaces SASL to some degree, which is where Thijs and Tobias's
> concerns come from.

The way I see it, is that it does not replace SASL, not even to some
degree, as SASL is (still) used to authenticate entities. ISR does
authenticate a stream resumption in an efficient manner.

> If you wrap ISR around SASL - and we can discuss removing the stream
> restart post-SASL in this case, too - then the security properties of
> the authentication portion of ISR become a matter of choosing the SASL
> mechanism, which is both vastly simpler to define and also allows us to
> easy handle things like hash agility.

I deliberately choose to not build ISR on top of SASL. First, I believe
it's not possible to achieve a zero round trip resumption doing so. And
secondly, it just feels wrong to have the stream in a different state
after  depending on whether or not ISR is used.

> To put it another way, ISR effectively combine the authentication and
> 198 into one step. Your proposal builds ISR by taking '198, and adding a
> brand new authentication mechanism. I'm suggesting that it seems
> worthwhile to explore building it the other way around, so we take SASL
> and add the '198 bits we need onto that.

I'm looking forward seeing something like that put in a more formal
specification. But I fear that it won't be able to achieve the same
properties as ISR, will be a more elegant and/or straightforward solution.

> The net result will be identical, except that the bits most likely to
> require changing have already-existing discovery and selection.
> 
> For example, assuming we remove post-SASL stream restarts if ISR is in
> play, using SASL PLAIN gives the same number of RTTs, and the same
> security properties, as the original ISR proposal. Using YAP would be
> 1-RTT with channel binding. Using SCRAM would be 2-RTT, with SASL-level
> mutual authentication.

That *is not* an identical result. ISR using HMAC and
tls-server-end-point provides mutual authentication and channel binding
with a zero round trip resumption [1].

> I think your proposal is trying to be a one-size-fits all approach, and
> I don't think such an approach is either viable or desirable.

I think most mobile developers using XMPP would disagree. The
"Token-based reconnection" ProtoXEP was created because of this
requirement. And I also pointed out [1, p19] that the round trip intense
session establishment process is an issue for mobile XMPP.

We have SM, CSI, MAM, and soon hopefully MIX. And another important
building block for mobile friendliness is a zero round trip stream
resumption mechanism providing good security properties.

- Florian


1: Note that this is not the ISR version submitted as ProtoXEP, but the
one based on the input from Thijs, which happened after the submission.
2:
https://archive.fosdem.org/2015/schedule/event/xmpp_and_android/attachments/slides/749/export/events/attachments/xmpp_and_android/slides/749/xmpp_and_android.pdf



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

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

2016-03-01 Thread Dave Cridland 
On 1 March 2016 at 17:13, Florian Schmaus  wrote:

> On 01.03.2016 09:26, Dave Cridland wrote:
> > I wonder - and I've not thought through the implications of this -
> > whether instead of trying to build a SASL-equivalent authentication into
> > '198, with all that entails, is it worth approaching this from the other
> > direction?
> >
> > I mean instead of something like this:
> >
> >
> > > S:  > > xmlns='urn:xmpp:sm:3'
> > > xmlns:isr='urn:xmpp:isr:0'
> > > isr:id='6956e8e5-b123-4a1a-9d23-939199568c4f'
> > > isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'/>
> > >
> >
> >
> >
> > Something more like:
> >
> >  > isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'>...
>
> There is a reason ISR is built on top of SM, and thus the token/key is
> found only after successful SM activation, i.e. in . As far as
> I understand it, your suggestion doesn't provide the same key feature as
> the current ISR approach does: 0-Round Trip session resumption
> (neglecting the TLS handshake, which is not in the scope of ISR).
>
>
FWIW, ISR is 1-RTT, unless you pipeline through, which doesn't really
count. Calling it 0-RTT is marketing.

So the main reason I'm thinking of wrapping ISR around SASL is because ISR
replaces SASL to some degree, which is where Thijs and Tobias's concerns
come from.

If you wrap ISR around SASL - and we can discuss removing the stream
restart post-SASL in this case, too - then the security properties of the
authentication portion of ISR become a matter of choosing the SASL
mechanism, which is both vastly simpler to define and also allows us to
easy handle things like hash agility.

To put it another way, ISR effectively combine the authentication and 198
into one step. Your proposal builds ISR by taking '198, and adding a brand
new authentication mechanism. I'm suggesting that it seems worthwhile to
explore building it the other way around, so we take SASL and add the '198
bits we need onto that.

The net result will be identical, except that the bits most likely to
require changing have already-existing discovery and selection.

For example, assuming we remove post-SASL stream restarts if ISR is in
play, using SASL PLAIN gives the same number of RTTs, and the same security
properties, as the original ISR proposal. Using YAP would be 1-RTT with
channel binding. Using SCRAM would be 2-RTT, with SASL-level mutual
authentication.


> > I would think this design would address Tobias's current veto:
> >
> > [16:11:09] Tobias: but yeah..i'm -1, will post on list, and as it aims
> > to replace the whole SASL step for a reconnection it's currently pretty
> > light on the discussion on how it obtains the same level of security
>
> I'm still waiting for Tobias's mail. :)
>
> There are different views that will come to different answers to this
> concern. For example one could say that ISR doesn't need to provide the
> same level of security that SASL does, since ISR is only possible after
> at least one successful SASL authentication. The lifetime of an ISR key
> is limited, and I assume, since I didn't hear anyone complaining yet,
> that the latest HMAC based scheme proposed for ISR provides sufficient
> security for the use case.
>
> Or, one could say that, if you neglect 2FA and such, a securely
> generated key with 128 or more bits is good enough. I believe the real
> answer lies in between. For what ISR tries to achieve, it's pretty
> solid, sound and more then sufficiently secure. If I wrong, then I'm
> more than happy be corrected and (if possible) fix the issues in the ISR
> approach.
>

I think your proposal is trying to be a one-size-fits all approach, and I
don't think such an approach is either viable or desirable.


>
> - Florian
>
>
>
> ___
> 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] Proposed XMPP Extension: Instant Stream Resumption

2016-03-01 Thread Tobias Markmann 
Hi Florian,

On Tue, Mar 1, 2016 at 6:13 PM, Florian Schmaus  wrote:

>
> There is a reason ISR is built on top of SM, and thus the token/key is
> found only after successful SM activation, i.e. in . As far as
> I understand it, your suggestion doesn't provide the same key feature as
> the current ISR approach does: 0-Round Trip session resumption
> (neglecting the TLS handshake, which is not in the scope of ISR).


Right, we should aim for a minimum number of round trips for ISR, else you
could just do normal SASL for authentication.



> > I would think this design would address Tobias's current veto:
> >
> > [16:11:09] Tobias: but yeah..i'm -1, will post on list, and as it aims
> > to replace the whole SASL step for a reconnection it's currently pretty
> > light on the discussion on how it obtains the same level of security
>
> I'm still waiting for Tobias's mail. :)
>

Yes, sorry for the delay.

>
> There are different views that will come to different answers to this
> concern. For example one could say that ISR doesn't need to provide the
> same level of security that SASL does, since ISR is only possible after
> at least one successful SASL authentication. The lifetime of an ISR key
> is limited, and I assume, since I didn't hear anyone complaining yet,
> that the latest HMAC based scheme proposed for ISR provides sufficient
> security for the use case.


> Or, one could say that, if you neglect 2FA and such, a securely
> generated key with 128 or more bits is good enough. I believe the real
> answer lies in between. For what ISR tries to achieve, it's pretty
> solid, sound and more then sufficiently secure. If I wrong, then I'm
> more than happy be corrected and (if possible) fix the issues in the ISR
> approach.


Right. My major concern was that the way it was described in the proposed
XEP, the resumption provided less secure authentication compared to SASL
with SCRAM-* or SCRAM-*-PLUS, and did very little on describing what level
of authentication it provides compared t the SASL layer it proposed to
replace.

With standard TLS and SCRAM at the first authentication the client is
authenticated only by proving knowledge of the password and the server by
TLS certificate authentication and also proving knowledge of the password
to the client, both without leaking the clear password.

Something like Thijs proposal or your adaptation sounds like a sensible way
to go, considering a more depth security analysis when it's accepted.

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

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

2016-03-01 Thread Florian Schmaus 
On 01.03.2016 09:26, Dave Cridland wrote:
> I wonder - and I've not thought through the implications of this -
> whether instead of trying to build a SASL-equivalent authentication into
> '198, with all that entails, is it worth approaching this from the other
> direction?
> 
> I mean instead of something like this:
>  
> 
> > S:  > xmlns='urn:xmpp:sm:3'
> > xmlns:isr='urn:xmpp:isr:0'
> > isr:id='6956e8e5-b123-4a1a-9d23-939199568c4f'
> > isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'/>
> >
> 
> 
> 
> Something more like:
> 
>  isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'>...

There is a reason ISR is built on top of SM, and thus the token/key is
found only after successful SM activation, i.e. in . As far as
I understand it, your suggestion doesn't provide the same key feature as
the current ISR approach does: 0-Round Trip session resumption
(neglecting the TLS handshake, which is not in the scope of ISR).

> I would think this design would address Tobias's current veto:
> 
> [16:11:09] Tobias: but yeah..i'm -1, will post on list, and as it aims
> to replace the whole SASL step for a reconnection it's currently pretty
> light on the discussion on how it obtains the same level of security

I'm still waiting for Tobias's mail. :)

There are different views that will come to different answers to this
concern. For example one could say that ISR doesn't need to provide the
same level of security that SASL does, since ISR is only possible after
at least one successful SASL authentication. The lifetime of an ISR key
is limited, and I assume, since I didn't hear anyone complaining yet,
that the latest HMAC based scheme proposed for ISR provides sufficient
security for the use case.

Or, one could say that, if you neglect 2FA and such, a securely
generated key with 128 or more bits is good enough. I believe the real
answer lies in between. For what ISR tries to achieve, it's pretty
solid, sound and more then sufficiently secure. If I wrong, then I'm
more than happy be corrected and (if possible) fix the issues in the ISR
approach.

- Florian




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

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

2016-03-01 Thread Dave Cridland 
On 19 February 2016 at 20:12, Florian Schmaus  wrote:

> On 18.02.2016 09:45, Thijs Alkemade wrote:
> > Of course, there are situations where a certificate legitimately
> changes, but
> > quick resumption failing once every 3 months and having to fall back to a
> > normal XEP-0198 resume sounds fine to me. I'd assume the possibility of
> > specifying the IP address + port on which to resume makes it easy to
> always
> > redirect the client to the same server in the cluster.
>
> Exactly my thought: It's not really an issue if once every few months
> ISR would fail because of a changed cert.
>
> > The YAP draft Dave linked looks interesting, though it only offers
> channel
> > binding and not mutual authentication, but I think that can be easily
> fixed by
> > something like:
> >
>

I wonder - and I've not thought through the implications of this - whether
instead of trying to build a SASL-equivalent authentication into '198, with
all that entails, is it worth approaching this from the other direction?

I mean instead of something like this:


> > S:  > xmlns='urn:xmpp:sm:3'
> > xmlns:isr='urn:xmpp:isr:0'
> > isr:id='6956e8e5-b123-4a1a-9d23-939199568c4f'
> > isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'/>
> >
>


Something more like:

...

I would think this design would address Tobias's current veto:

[16:11:09] Tobias: but yeah..i'm -1, will post on list, and as it aims to
replace the whole SASL step for a reconnection it's currently pretty light
on the discussion on how it obtains the same level of security



> > Resumption uses SASL with:
> >
> > C: id || HMAC(key, "Client" || ChannelBinding)
> > S: HMAC(key, "Server" || ChannelBinding)
> >
> > Where the id is only necessary so the server can find the key
> efficiently (it
> > could be made stateless by making the id an encrypted token containing
> key, or
> > by deriving key from id using HMAC).
>
> I'd like to take on this approach and modify it a bit:
>
> - Instead of xsr:id we simply use the stream ID that's in  if
> resume=true. I'd assume that ISR supporting servers will always also
> support (ver likely) xep198 stream resumption.
> - I'd like to fix ChannelBinding to tls-server-end-point. Mostly because
> the situation hasn't much improved since Tobias asked in 2011 [1]: You
> can't implement tls-unique in Java SE or Android without resorting to a
> custom TLS stack.
> - Don't use SASL for ISR. The XMPP session state after SASL 
> is a fundamentally different one then after .
>
> So basically we have now:
>
> * Client receives  with ISR key
>
>xmlns='urn:xmpp:sm:3'
>   xmlns:isr='urn:xmpp:isr:0'
>   id='some-long-sm-id'
>   resume='true'
>   isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52' />
>
>
> * Client performs ISR with HMAC(isr:key, "Initiator" || cb)
>
>   from='jul...@im.example.com'
>  to='im.example.com'
>  version='1.0'
>  xml:lang='en'
>  xmlns='jabber:client'
>  xmlns:stream='http://etherx.jabber.org/streams'>
>xmlns='urn:xmpp:isr:0'
>   previd='some-long-sm-id'
>   h='42'>
>   
> initiator-hmac
>   
> 
>
>
> * Server acknowledges ISR with HMAC(isr:key, "Responder" || cb)
>
>from='im.example.com'
>   id='t7AMCin9zjMNwQKDnplntZPIDEI='
>   to='jul...@im.example.com'
>   version='1.0'
>   xml:lang='en'
>   xmlns='jabber:client'
>   xmlns:stream='http://etherx.jabber.org/streams'>
> 
>  
> 
>xmlns='urn:xmpp:isr:0'
>   key='006b1a29-c549-41c7-a12c-2a931822f8c0'
>   h='21'>
>   
> responder-hmac
>   
> 
>
> where
>   initiator-hmac = Base64(HMAC(key, "Initiator" ||
> cb-tls-server-end-point))
>   responder-hmac = Base64(HMAC(key, "Responder" ||
> cb-tls-server-end-point))
>
>
> I'm not even sure if we need verify the server cert with the one at the
> time of . I don't see a point, since the server is
> authenticated by responder-hmac.
>
> Or am I missing something? If not, then I'm going to change the ISR
> ProtoXEP to this.
>
> - Florian
>
> 1: https://www.ietf.org/mail-archive/web/kitten/current/msg02767.html
>
>
> ___
> 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
___