[jdev] SASL EXTERNAL for s2s in jabberd14

[Matthias Wimmer]

HI Justin!


Thanks for your suggestions.

Justin Karneges schrieb:

>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
>  
>
Sounds good to me. I can integrate this into the other host based s2s 
configuration options, that I already have to force or forbid STARTTLS.

>
>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.'
>  
>
Maybe I should reread or RFCs completely again. Did not check this 
section ... ;)

>>- 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.
>  
>
I don't really like to allow subdomains either. But it might be handy if 
you do not have to include all services offered by a server into the 
certificate (so you need to get a new certificate whenever you add a 
service) or get separate certificates for all services.

>>- 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.
>  
>
Currently I am using the certificates distributed by Debian on my own 
server, plus the class 1 certificate of cacert.org. - And have added no 
certificates to the snapshot packages of jabberd14.
If I'd bundle the certificates with the distribution, it would also get 
more important to secure the distribution of the software. Same with 
products like Firefox. You download them using a unprotected connection 
and most of the time you do not even verify the hash value of the 
package. - But you trust the certificates in this browser afterwards.

>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?
>  
>
No, I didn't talk about multiple domains or wildcards. The thing was 
about the decission if I offer SASL EXTERNAL. In short:
If there is no from attribute, I offer SASL EXTERNAL whenever I can 
verify the certificate to be valid, doesn't matter for which identity it 
is valid.
If there is a from attribute, I make the same checks as if there is no 
from attribute, but in addition I check if the content of the from 
attribute (after stringprep) matches one of the identities in the 
certificate (after stringprep).

With SASL EXTERNAL the client sends the authorization identity in the 
initial response (base64 encoded as CDATA in the <auth/> element). At 
that point I recheck the certificate, if it contains the authorization 
identity and authenticate and authorize this ID (even if it differs from 
the domain sent in the from attribute).

At present I allow only to authenticate as the same as you authorize. 
Checking cerficicates and espacially deciding which certificate to 
present to the peer, when proxy authorization gets implemented might 
become an interesting and complex job ;)


Tot kijk
     Matthias