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

[Matthias Wimmer]

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.)

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. 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.)
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.

- 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.)

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.)


Tot kijk
     Matthias

-- 
Matthias Wimmer      Fon +49-700 77 00 77 70
Züricher Str. 243    Fax +49-89 95 89 91 56
81476 München        http://ma.tthias.eu/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4263 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20060911/e615013c/smime.bin