On Donnerstag, 27. April 2017 19:03:34 CEST Georg Lukas wrote: > * Daniel Gultsch <dan...@gultsch.de> [2017-04-27 18:58]: > > As stated in MUC I'm fine with an HMAC. > > +1 > > > I think it might be useful for a client to know if they can rely on the > > server to dealwith the authentication or if they will have to do that > > themselves. > > I don't think this matters in any practical way. Your client will either > receive a subscription request with a PARS token which it needs to > verify, or it will receive a roster push ;) > > > > I see the UX problems, but I'm not sure if this is a good idea > > > security-wise. I'd like to hear other opinions on this. > > > > I guess in theory 'approving entities' can still do a rate limiting on the > > tokens? However I would find it very hard to come up with a good N that > > both works (me showing my QR code at a party to a bunch of people standing > > around me) and also prevents annoying DOS attacks. > > Yeah, but what do you do if somebody posts your PARS link on twitter, > to copy-cat a potential attack scenario from xsf@ ;) > > > In any case i don't think N should be configurable by the user. > > I can at least see use cases for N=1 and N=infinity. But yeah, it's > making the UX harder. > > I'd really love to hear more opinions on this trade-off.
The UX is one thing. I’d first like to clear how N=1 would work implementation wise. (UX is easy, I think a checkbox "Create a reusable link" is a good start and default to N=1). N=1 requires that the server strikes the token off some list. Since PEP doesn’t normally allow multiple items, using a PEP node with many items won’t work. We could use the usual approach of abusing PEP nodes to store multiple items to store the single-use tokens (single-use and multi-use tokens can be distinguished by their length, we don’t need that many bytes for single-use tokens because we save the timestamp and a simple nonce is sufficient). The PEP node should then also contain a timeout after which the server (or a client writing to the node) may purge the token off the list. Also, a server (or client) should not accept an expired token. thoughts? Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
