[Standards] TLS certificate fun

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Tue May 13 18:29:33 UTC 2008

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
> 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 

> 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 

> 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.


More information about the Standards mailing list