On 22 January 2018 at 11:16, Jonas Wielicki <[email protected]> wrote: > URL: https://xmpp.org/extensions/xep-0397.html
So now this is published, I think I can list my (current) blockers for advancing it, as well as more general improvements that I think ought to be made, and suggestions for unblocking. The essential problem is that, while it now delegates the authentication itself to the SASL layer, it also requires a single, specific, SASL mechanism. Where the client has a client certificate, for example, or where we can (via ATLAS, perhaps) imbue a resumed TLS session with application-layer authentication detail, we can just use EXTERNAL. In more general terms, while HT-* has been developed into a quite nice 1-RTT one-shot authentication method, it's not the only 1-RTT SASL mechanism we could use sensibly. Equally, the implication that HT-* is only used during ISR also gets lost this way - clients could use HT-* in other cases (like those suggested by CLIENT-KEY). So, with that in mind: Section §3: If we follow the logic above, then any SASL mechanism available could be used with ISR, so the child <mechanisms/> element would go. I do appreciate there's limited utility in using ISR with, say, SCRAM, but the functionality would not be limited and there would be no negative security implications. As a comment, I don't think it's possible to advertise both <bind/> and <isr/> together, and I'm pretty sure you'd need to advertise SASL2 here. Section §4: Usual comment about made-up "Nonza" word here. This is the area which we'd lose most by breaking the hard link to HT-*, by introducing a possible further RTT. That said, we might coalesce that RTT into the authentication exchange instead, by using more SASL2 magic. So what you'd do here is this: Within the <authenticate/> element you add (whether doing ISR or not) a <ht-token/> element. (Or <ht-request/>, or whatever). This requests the ht-* token - presumably it'd need a mechanism element - much like Example 3. In the <success/> element, the server would provide the client with a token and scope, like Example 4. Note that I'm somewhat conflating HT-* support and ISR here, and it might be as well to split them into to distinct documents. Section §5.1 XEP-0198 already has a "location", shouldn't we be using that? Section §5.2 I don't think the client can be the one to choose if HT-* is performed with a password or not - my gut feeling is that HT-* with a traditional password is an entirely distinct proposition to HT-* with a one-shot token due to the distinction is security criteria for password storage. Section §5.2.1 I think the token disappears here. I'm also concerned with the deviation of including XEP-0138 here, but not in XEP-0198. I think overall I'd rather we looked into recasting XEP-0138 as a SASL2 extension, which would then bring benefits throughout. There's a risk that everyone will think that I want all stream negotiation to be part of SASL2. They're right. This is, roughly, the point of SASL2. There's no need to try to introduce such things via the backdoor inside another SASL2 extension. Section §5.2.3-4 I don't think these sections are needed, are they? They're restating things from XEP-0388 which have been stated already in the SASL2 document. (More seriously, I worry people might think there's a difference, when there isn't). Section §6 I believe that the second paragraph ought to be covered by the draft-schmaus-ht-* draft, and you probably ought to point specifically to that draft at this point. The first paragraph is probably generic to any <authenticate/> extension, and I'd welcome text for XEP-0388 on that basis. Summary: Not ready for Draft, but actually surprisingly close for a newly adopted XEP. The main thing preventing me from implementing this in Openfire today is actually the overhead of implementing HT-* properly, which'd take me a little longer. I think this is very likely to be a general problem for implementors, and removing the hard dependency between them (even if it remains a SHOULD, which seems sensible) would improve deployment. If my comments above are all addressed - and I think they still leave the same essential properties of a secure 1-RTT resumption - I'd be happy to see this advance. Dave. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
