On Tue May 13 16:38:22 2008, Justin Karneges wrote:
On Tuesday 13 May 2008 5:50 am, Dave Cridland wrote:
> After carefully reading RFC 4985, I think we shouldn't be using
> SRVName to identify a remote entity, due to the closing points of
its
> Section 2.
Right, we shouldn't use this, since XMPP-Core does not specify that
it should
be used. But this may change.
Right.
> This leaves id-on-xmppAddr and dNSName. The former is,according to
> RFC 3920 Section 14.2, and similar text in Section 15.2 of the bis
> draft, always preferred over the latter - ie, if the former
exists,
> the latter is ignored.
>
> This means, amongst other things, that we cannot identify the XMPP
> service responding to conference.jabber.org via the certificate it
> presents, since it doesn't include an id-on-xmppAddr of
> conference.jabber.org.
>
> But wait, because rfc3920bis does state that, in 6.4.2, servers
> SHOULD use a representation where jids MUST be included as a
dNSName
> - and conference.jabber.org does indeed match one of the
> certificate's dNSNames. So essentially, it's sort of up to me
whether
> I accept its certificate, and what jids I authorize it to use.
"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?
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. Secondly, this seems like a step down in terms
of efficiency.
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.
This gets us as far as a bidirectional channel between identities.
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.
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.
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
