[Standards] Re: [Standards-JIG] Notes on JEP-0178: Best Practices for Use of SASL EXTERNAL - server to server part of the JEP

Peter Saint-Andre stpeter at jabber.org
Thu Jan 25 22:27:57 UTC 2007


Continued... :-)

On 2006-09-10, Matthias Wimmer wrote:
> Hi!
> 
> This is the second part of my notes about JEP-0178 not differenting 
> between authentication and authorization while it should.
> 
> In section 3 (Server-to-Server Recommendation), step 11 this JEP 
> specifies indirectly, that for s2s communication the authentication 
> identity and the authorization identity always have to be the same. (By 
> clause 2 defining, that if clause 1 does not match, the server MUST 
> return <not-authorized/>.)
> 
> I do not think that this is neccessary. In some environments, it might 
> be acceptable, that a different authorization policy might be configured 
> on the server. E.g. it might be configured, that the server, that 
> authenticates as "example.com" (i.e. having "example.com" in his 
> certificate) might as well authorize as "transport.example.com". (While 
> I consider it better, that the transport transport.example.com would 
> have its own certificate, or its XMPP address would be at least included 
> in the certificate as an additional XMPP address, and therefore it would 
> be an authentication identity, I do not think we have to require this by 
> JEP-0178.)

Well yes, this also brings up the question of wildcards in certs, as we 
have done with the ICA. So the admins for example.com might in fact 
request a cert with *.example.com as the id-on-xmppAddr or dnsName. We 
had some debate about this on the xmppnet list back in December, see the 
thread here:

http://mail.jabber.org/pipermail/xmppnet/2006-December/000131.html

Our conclusion was that the id-on-xmppAddr should be "example.com" but 
that the dnsName should be "*.example.com". Does that seem correct? If 
so we should add something about that to the best practices.

So there would be two ways to encode multiple XMPP service addresses:

1. multiple id-on-xmppAddr entries, one for each address (example.com, 
transport.example.com, etc.)

2. one id-on-xmppAddr entry (e.g., example.com) and a wildcard dnsName 
entry (*.example.com)

I'm not sure how we should virtual hosts, though...

> In step 9 of section 3 this JEP defines, that a server advertizes the 
> EXTERNAL mechanism because the other server presented a certificate. I 
> do not think, that a server should always advertize EXTERNAL, if the 
> other server presented a certificate, but only if it expects that SASL 
> EXTERNAL will succesfully authorize the other server. 

That makes sense.

> Reasons:
> 
> - (Section 3, step 7:) Different from the c2s case (section 2, step 7), 
> the connection is only closed in the s2s case if the certificate of 
> server 1 has been revoked. (Explicit: Server 2 does not close the 
> connection if the certificate of server 1 is from an unknown 
> certification authority. - And yes, this is a good thing to have it that 
> way.)

Right.

> Server 1 cannot know, that server 2 does not know (or trust) the 
> certification authority, that signed server 1's certificate. If the 
> EXTERNAL mechanism is presented by server 2, server 1 would select this 
> mechanism. The authorization would fail, as server 2 should not accept 
> the SASL authorization of that identity in that case.
> But if server 2 would not have advertized the EXTERNAL mechanism, server 
> 1 could have chosen another way to catch up on authentication and do 
> authorization by another SASL mechanism (or if nothing better is left by 
> dialback).
> Therefore I propose, that before sending the SASL mechanisms, server 2 
> should check, if it will allow authorization of server 1 to use the 
> address, that has been passed in the from attribute of the last stream 
> root element (if the from attribute is present). If it will, it should 
> advertize the EXTERNAL, if it will not, it should not advertize the 
> EXTERNAL mechanism.

Agreed.

> - If we do remove the restriction, that the authentication identity has 
> to be the same as the authorization identity (i.e. if we allow, that a 
> server can be configured to accept authoriation as 
> "transport.example.com" to the server presenting the certificate of 
> "example.com") we have the same problem as above:
> The server example.com wants to authorize as "transport.example.com" and 
> presented the certificate "example.com" because it does not have a 
> special certificate for "transport.example.com". Server 1 (example.com) 
> cannot know if server 2 does allow it to authorize as 
> "transport.example.com". If server 2 always advertizes EXTERNAL, server 
> 1 just have to try if server 2 will accept the authorization as 
> "transport.example.com". And if it does not, the stream will get closed 
> by server 2 which causes communication to fail.
> But if server 2 only advertizes the EXTERNAL mechanism, if it expects 
> authorization to succeed, server 1 can safely authorize as the 
> transport.example.com, while not even trying to do this, if server 2 
> will not accept this anyway. (And server 1 is now able to find another 
> way to authenticate and authorize as transport.example.com, e.g. by 
> another SASL mechanism or if nothing better is left by doing dialback.)

Yes.

> Note:
> When closely following the current steps in section 3, we even have a 
> security problem in s2s. Closely following the current steps in section 
> 3 allows spoofing of addresses!
> The steps in section 3 never check if the certificate is signed by a 
> trusted certification authority. As I said, I think it is a good thing, 
> that we do not close streams, when a untrusted certificate is presented. 
> If the TLS layer is established, we should just not expect the stream to 
> be authenticated yet (as it would be if the certificate is trusted). 
> Therefore we have to check at a later point, if the certificate is 
> trusted (i.e. if the stream has been authenticated).
> I think the correct place for this step is when server 2 checks 
> authorization (i.e. server 2 should first checks if the certificate is 
> trusted when it decides if EXTERNAL is advertized, and it should only 
> advertize EXTERNAL if the certificate is trusted, and again server 2 
> should check if the certificate is trusted, if SASL EXTERNAL is tried by 
> server 1 - while server 1 should not try to use SASL EXTERNAL when it is 
> not advertized by server 2, we still have to check that server 1 does 
> not try to use it anyway.)

Duly noted.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070125/152a1a62/attachment.bin>


More information about the Standards mailing list