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

Peter Saint-Andre stpeter at jabber.org
Thu Jan 25 21:12:44 UTC 2007


I'm finally working on this...

On 2006-09-10, Matthias Wimmer wrote:
> 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."

Done.

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

Well, SASL stands for "Simple Authentication and Security Layer" and I 
know the SASL folks prefer to talk about authentication. So I think that 
in the case of SASL EXTERNAL the authentication credentials are 
presented during the TLS negotiation and SASL EXTERNAL refers back to 
those credentials, but the SASL folks would not like it if we said that 
authentication occurred during TLS negotiation because TLS is not an 
authentication protocol (insert IETF politics here...).

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

How about this? "Server determines whether to allow authentication and 
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."

Done.

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

I changed the wording to be as follows:

If the certificate contains more than one valid XMPP address that 
corresponds to a registered account on the server (e.g., because the 
server offers virtual hosting), the server SHOULD allow authentication 
and authorization of the JID specified as the authorization identity (if 
no authorization identity is included, the server MUST return a SASL 
failure case of <invalid-authzid/> and close the stream).

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

Well pgm and I talked about this use case about a year ago -- the idea 
is that the cert does not contain any XMPP address but does contain a 
Common Name and the server can use that information to match the CN with 
an XMPP address. But it seems in this case that the client should 
(must?) include an authorization identity, right?

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

I cleaned this up a bit in my working copy.

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/5add5079/attachment.bin>


More information about the Standards mailing list