On 20.03.2017 23:23, Dave Cridland wrote: > On 20 March 2017 at 22:04, Florian Schmaus <f...@geekplace.eu> wrote: >> On 20.03.2017 22:32, Dave Cridland wrote: >>> Loosely, this is OK, but, in order: >>> >>> 1) Section 6 must go. I don't believe that the XSF has the required >>> expertise to adequately review a SASL mechanism. I'm saying this >>> without commenting on the mechanism described in Section 6. This needs >>> to go through the IETF (this document can reference any particular >>> SASL mechanism for MTI it likes, including this one). The right >>> working group is - probably - Kitten, though traditionally XMPP itself >>> works through the ART area, and we might want to give an ART AD or two >>> a heads-up. This issue is a blocker for me. >> >> Section 6. was written in mind being probably factored out. So I'm happy >> to bring this to the IETF. Anyone who wants to shepherd me? > > I'm confident we can find a shepherd, but I can do that if we need > one. (Assuming you actually do mean a Document Shepherd).
Shepherding in no particular sense, so not strictly limited to a document shepherd (but that would be also very appreciated). > Incidentally, I think a token-based SASL mechanism might be generally > useful; Surevine could use one if it existed, certainly. It's useful > to have a device-specific token which can then be managed and/or > revoked, independent of ISR - this implies a multiple-use token rather > than a single-use one, however. I have a vague feeling that something > based around a fusion of HOTP and YAP might yield something that > satisfies this. If you're open to the idea, I'll outline a quick > design. Well, I do think that X-HT-* does already everything required for ISR and for a generic token-based SASl mechanism. The only thing missing for an official IETF SASL mech is probably support for auth(c|z)id, which is trivial to add. I looked into Kurt's YAP as SASL mech for ISR, as you know. And compared to X-HT-*, it is missing the mutual authentication part, which I consider very important for the X-HT-*'s use case. And somehow X-HT-* is a fusion of HOTP and YAP. But I'm not sure what exactly you mean with "multiple-use token" and how it fits into the picture. That said, I think it would be really great if you could do a strawman, elaborate a bit what you are trying to solve and if prepare yourself for some stupid follow up questions from my side. :) >>> 2) I don't think §5.2.3 is right - I don't think ISR should be placing >>> any requirements on the upper layer. You might think - correctly - >>> that a server requiring 2FA on a resume is not behaving very sensibly, >>> but I don't think it's behaving in a way that would cause >>> interoperability problems. >> >> I'm sorry, but I'm confused (maybe it is already to late for me :)). You >> mean ISR should not allow 2FA on resume? Why not? Care to elaborate what >> you mean with "placing any requirements on the upper layer"? If ISR is >> based on SASL2, why shouldn't it also support <continue/> XEP-0388 § 2.6.3? > > No, I mean the reverse. §5.2.3 says: > > Performing instant stream resumption using multiple SASL mechanisms > MUST only be done if the 'without-isr-token' attribute is set to > 'true'. > > I took that to mean, "Servers MUST NOT use <continue/> if the > without-isr-token attribute is set to true". Noted. It appears the negation of without-isr-token was not a good idea. I'll try to improve the wording and how it turns out without the negation. - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
