On Tue May 13 19:29:33 2008, Justin Karneges wrote:
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. One that says "If any xmppAddr is present, use only xmppAddr",
another that says "but fallback to dNSName". This is okay as long as
both ends know which identities are authenticated.
> > 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.
There isn't, this is highlighting that we need to ensure that an
authzid is explicitly stated.
> > 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.
Well, yes - there being no point I can think of in having a channel
there unless it's to be mutually trusted.
> 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.
Why? If it's mutually authenticated, this seems silly.
> 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.
Drastically so for deployments with significant numbers of
identities. Two servers with two identities need 4 bidirectional
channels, or 8 unidirectional channels. Two servers with three
identities would need 18 unidirectional channels - you need N*M
directions.
> 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.
*nods* I think dialback itself will essentially work, the trouble is
that an originator won't be expecting a dialback initiated by the
receiver.
Dialback is an assertion that states "I am this identity". Typically,
the receiver tests the assertion by dialling back, but realistically,
nothing stops the receiver testing the assertion by checking a
certificate associated with the channel.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
