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

[Matthias Wimmer]

Hi!

I think when JEP-0178 has been written, there have not been made enough 
thoughts about the difference of authentication and authorization.

In case of TLS + SASL EXTERNAL, authentication is done by the TLS layer, 
while the SASL layer is only left to do authorization.

Therefore some notes on JEP-0178:

- In section 2 (Client-to-Server Recommendation), step 10:

   It is stated, that no authorization identity should be passed within
   the SASL exchange, as the authorization would be done in the resource
   binding step.
   I think this is wrong. In resource binding, we do only select
   resources, that are used. We cannot pass authorization identites
   there.

   E.g.: my JID is "mawis at amessage.info", and I am the administrator of
   the "amessage.info" server. The administrator here is allowed to
   authorize as any user of the server. (It is not, but let's assume it
   is ... *g*)
   For this example, I want to authorize as "someuser at amessage.info" to
   set a new password for this user, and I want to bind the resource
   "helped by administrator".

   The authentication step is done when TLS is established. My
   authentication identity is "mawis at amessage.info", therefore that is
   the id-on-xmppAddr in my certificate.

   To authorize as "someuser at amessage.info" I now HAVE to pass the
   authorization identity "someuser at amessage.info" in the SASL exchange,
   but JEP-0178 currently prohibits this.

   After I authorized as "someuser at amessage.info", I will now bind the
   resource "helped by administrator", and the server will confirm, that
   I bound to the address "someuser at amessage.info/helped by
   administrator".

   Proposal:
   Change wording to: "The client SHOULD NOT include an authorization
   identity (i.e., XML character data for the <auth/> element), if it
   wants to authorize as the identity, that has been authenticated by
   the TLS layer (i.e., the XMPP address that is contained in the client
   certificate). If the client certificate contains more than one
   XMPP address, the client SHOULD always include an authorization
   identity."

- In section 2 (Client-to-Server Recommendation), step 11:

   The authentication is already done by the TLS layer. Therefore this
   step is not about "authentication" but about "authorization".

   Proposal:
   Change the following sentence: "Server determines whether to allow
   authentication of user." to "Server determines whether to allow
   authorization of user."

   Proposal:
   Change the following sentence: "If the certificate presented by the
   client contains only one valid XMPP address [4] that corresponds to a
   registered account on the server, the server SHOULD allow
   authentication of that JID." to "If the certificate presented by the
   client contains only one valid XMPP address [4] that corresponds to a
   registered account on the server, and the client did not pass an
   authorization identity, the server SHOULD allow authorization of that
   JID."

   Clause 2 would not be required that way, if the client passed an
   authorization identity in case of having multiple XMPP addresses in
   the certificate. But we might specify what the server should do, if
   the client certificate contains multiple XMPP addresses, but no
   authorization identity has been passed. - I have no proposal yet for
   the wording for this case.

   Clause 3: I do not think, that we have to check the existence of
   the account the user authenticated as (= that has been included in
   the certificate). We just have to check, that the account the user
   tries to authorize as does exist. The authorization identity should
   always be an XMPP address, therefore we do not need this clause that
   way. But we may have some words on an authentication policy. Therefore
   it might be possible that the authentication identity is just a
   Common Name in the certificate, and the certificate with that CN
   might be allowed (e.g. by an LDAP entry) to authorize as an XMPP
   address, that is passed in the SASL exchange, and that has been found
   in that LDAP directory.

   Clause 4: When we cleanly differentiate between authentication and
   authorization, this as well gets a bit fuzzy. Maybe we can write
   something like: "If the identity a client tries to authorize as
   does not represent a registered account on the server, the server
   MUST return a SASL failure of <not-authorized/> and close the
   stream." - But we should think about, if <invalid-authzid/> would
   not be the better error condition.


Okay, I just noticed, that this mail gets a bit longer. Sorry for that. 
I'll split here and write an additional mail for section 3 
(Server-to-Server Recommendation) of this JEP.


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/382b40ee/smime.bin