On Tuesday 13 May 2008 9:51 am, Dave Cridland wrote: > On Tue May 13 16:38:22 2008, Justin Karneges wrote: > > "Sort of up to me" sounds like there's guesswork. Compare a jid > > against the > > certificate according to the rules, and you'll know if it is > > authorizable. > > Sure. Which rules, given that there are two sets in rfc3920bis? And > how do I know which you're using?
Two sets? > > Yes. I believe authzid is necessary with SASL EXTERNAL. And yes, > > you can > > only authorize one identity per TCP connection. > > Ah... Firstly, authzid isn't required for SASL EXTERNAL - you can > request that the other end uses the default - but it's certainly a > sensible choice here. I'm not sure how you work out a default authzid from a certificate, but assuming there's an unambiguous way to do that then yes this would be fine. > > The receiving entity is authorized as whatever domain was present > > in the > > stream 'to' attribute sent by the initiating entity. This field is > > optional > > if you plan to use dialback, but required if you plan to use > > TLS/SASL. > > Okay, so we assume that the S2S originator authenticates us if it > continues to use SASL EXTERNAL? That's okay, I suppose - what mildly > concerns me is that the S2S originator is forced into trusting the > reciever even if the receiver's certificate is not trustworthy, but I > can't think of a reason why you'd want to authenticate anyway if that > meant you weren't happy to receive stanzas. So yeah, I'll go along > with this, with some relief. The initiatior is not forced into trusting the receiver. It nukes the TCP connection if the receiver's certificate is no good, before proceeding to SASL. > This gets us as far as a bidirectional channel between identities. Yes, a mutually authenticated bidirectional channel. To clarify though, if this is an s2s channel then stanzas can only flow in the initiator->receiver direction. > Now, if each server has two identities, both represented in the same > certificate, then this would mean 4 connections, whereas we currently > use 2 unidirectional streams. This seems a bit silly, so I was > wondering how to reduce this. Right. It is not as efficient as dialback. > So consider a server A with two identities A-1 and A-2, contacting a > server B, which has identities B-1 and B-2. If A uses identity A-1 in > its SASL EXTERNAL, and addresses streams to B-1, then A and B know > they have authenicated each other as A-1 and B-1. > > It seems logical that if a server A sends a stanza to server B from a > jid which relates to A-1, to a jid which relates to identity B-2, > then B can then assume that A will accept stanzas from B-2. This > really suggests that on connection, both ends could ping the other's > known identities, so the traffic immediately after A authenticates > with SASL EXTERNAL to B would be pings from A-1 to B-2, and B-1 to > A-2, thus reducing the connections to a single bidirectional > connection. > > The problem is that any identity that is only matched by the > certificate using wildcards isn't going to be known to the other side > - not sure how we might handle that, although using a simple <iq/> to > ask the other side would work, it'd just need stream features to > support it, so not be as cleanly backwards compatible. Optimizing SASL-based s2s would be nice. I'm not sure if I agree with the ping approach though. I'd have to give it more thought. Dialback doesn't "probe" for known identities, so I don't think we need that here. We'd just need a way to specify additional explicit from/to domains on an as-needed basis (exactly like dialback), which also avoids wildcard problems. -Justin
