[jdev] SASL EXTERNAL for s2s in jabberd14

[Justin Karneges]

Hi,

On Friday 04 November 2005 12:33, Matthias Wimmer wrote:
> - When do you offer SASL EXTERNAL on an incoming connection? I
> implemented, that the s2s connection manager always checks the peers
> certificate as soon as a TLS layer is established. Only if the
> certificate could be validated (not expired, if the incoming stream had
> a from attribute if this matches the certificate, signed by a trusted
> CA, ...) I offer the peer to use SASL EXTERNAL. In all other cases I
> know that SASL EXTERNAL would fail anyway so I do not have to offer it.
> Better for the peer to try dialback.

This sounds fine to me.

> - What do you do if you connected to an other server which offered you
> SASL auth but the authentication failed? Do you retry the connection
> using dialback or do you consider it as a final auth failure? Currently
> I do not retry it using dialback but bounce the stanza back to the
> sender. I am aware that this might be wrong and retrying the connection
> using dialback could be better.

Since I suspect it will be easy to have TLS misconfigurations, I would 
recommend that we treat a failed TLS/SASL auth as the same as not even 
supporting it in the first place.  In that case, I would not consider it 
wrong to attempt dialback as a fallback.

I'd say this is just a policy choice for the sending server.

Personally, I don't like these kinds of auto-mechanisms because they are 
susceptible to downgrade attacks.  If I were designing a server, maybe I'd 
have two security modes:
  1) default insecure, have a list of domains required to be secure
  2) default secure, have a list of domains allowed to be insecure

For auto-security, you'd probably go with #1 and keep the list empty.  This 
means there should never be any assumption about having s2s security.  It 
might be there, or it might not.

For full security you could go with #2 and keep the list empty.  But things 
would probably be very boring.

> - I guess at least for now we have to handle certificates, that do not
> contain the id-on-xmppAddr object as well and therefore have to support
> domains as commonName as well. Right? In that case, it is known practice
> in such certificates to have wildcards in domains, e.g. "*.example.com".
> Do you handle these? How do you handle these? I am allowing this
> certificate for "subdomain.example.com", but not for "example.com".

XMPP-Core 14.2 says: 'The certificate SHOULD then be checked against the 
expected identity of the peer following the rules described in [RFC 2818], 
except that a subjectAltName extension of type "xmpp" MUST be used as the 
identity if present.'

It is unclear how this pertains to wildcards though, since the xmpp extension 
contains a JID and not a domain.  If I had to make a decision here, I'd say 
that for domain-only JIDs, wildcards should be allowed.  The RFC 3920bis todo 
grows...

> - If the certificate is for "example.com", do you accept this
> certificate to be used for "service.example.com" as well? Currently I
> don't. But I am not sure if this is correct/intended by RFC3920.

You shouldn't.  And I don't think XMPP-Core says to do this either.  However, 
given that the draft does mention subdomains in places, maybe we could use a 
clarification.  I personally don't think the word 'subdomain' should exist in 
the entire draft, but it is there.

> - Do you support having a SASL authenticated link in one direction and a
> dialback "authenticated" link in the other direction between two
> servers? Especially do you accept and process to receive db:verify
> requests on a SASL link? Currently I do.

Protocol-wise, I'd say having different types of channels is allowed.  
However, this again seems like a security policy decision.  If a domain is 
explicitly configured to be secure, then I would want to protect both 
directions.

Allowing <db:verify> requests over a SASL link is questionable.  I'm still 
very confused about the intermixing of dialback, SASL, stream:features, and 
the notion of a "1.0" stream.

> - Do you package a set of CA certificates with your server distribution?
> Which CAs should be trusted/included?

I say leave the selection of CAs to others more qualified.

My recommendation is to use the certificates of the operating system if 
possible, or ship a copy of the CAs found in Mozilla.  This is how QCA 2.0 
works.

If you need a way to extract from Mozilla, there are some tools you might be 
able to google for.  If you have trouble finding something usable, QCA 2 has 
one called 'mozcerts'.  If you want to try it, you can get 2.0 beta1 and the 
qca-openssl plugin here:
  http://delta.affinix.com/qca/2.0/beta1/
Note: you need Qt 4 and openssl libraries to build.  and of course a copy of 
the firefox source code to extract from.

From your other mail:
> I got asked (on Jabber) how I do this verification and how I know which
> domain the server wants to authenticate later on.
>
> If the connecting server sent a from attribute in the stream root, I am
> checking against this. If there was no from attribute (the other server
> does not have to send this attribute), I just check if the certificate
> is not expired and I can validate the certification chain up to a
> trusted root CA certificate.

Of course, this is only a problem with a wildcard domain or multiple domains 
in the connecting server's cert, correct?

This is an interesting problem.  I could be wrong, but I think you can pass an 
identifier with SASL EXTERNAL.  Maybe in here we should pass a JID?

-Justin