[Standards] TLS certificate fun

Dave Cridland dave at cridland.net
Tue May 13 18:40:50 UTC 2008


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:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list