[Standards] Re: [Standards-JIG] Notes on JEP-0178: Best Practices for Use of SASL EXTERNAL - server to server part of the JEP
stpeter at jabber.org
Thu Jan 25 22:27:57 UTC 2007
On 2006-09-10, Matthias Wimmer wrote:
> 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
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
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,
2. one id-on-xmppAddr entry (e.g., example.com) and a wildcard dnsName
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.
> - (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
> 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
> 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.
> - 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.)
> 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.)
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards