On Fri, Jun 14, 2013 at 9:23 PM, Thijs Alkemade <th...@xnyhps.nl> wrote:
> I don't see any possible downside to the client always sending its desired > authzid, except for maybe ~20 characters of extra data. The server can > still > do the same checking. I propose clients SHOULD send an authzid, except in > case > the certificate contains exactly one xmppAddr field, in which case they MAY > omit the authzid and send "=". > Here's some history for you. Once upon a time, various people noticed that IMAP had only a simple "LOGIN" command, and wanted to make a challenge-response based login. Because they thought that maybe other ideas might come up in the future, they made a generalized AUTHENTICATE command, which supported multiple mechanisms. This is where SASL came from, and explains why many mechanisms are distinctly text-flavoured (even though IMAP base64's them in order to handle those that aren't). Some protocols - most notably Kerberos, but also Digest-MD5 - had an extra slot aside from the login name, which was used for what's known as "proxy authentication" - that is, logging in as someone else's proxy. It was basically an assertion that this other guy was letting you login as them. So you'd use your principal, or login name (now "Authentication Identifier") and password, but you'd ask to be logged in as somebody else - the Authorization Identifier. Obviously if the same name was used in both places, this was the same as not requesting Proxy Auth. As SASL became genericised for multiple protocols, this shifted slightly, and two things happened: a) The Authorization Identifier became protocol-specific, whereas the Authentication Identifier became mechanism-specific. In IMAP, this had made little difference, as IMAP doesn't even have a native format, but for other protocols, like XMPP and LDAP, it does. b) *Any* Authorization Identifier officially means you're trying to do Proxy Auth. So when we wrote XEP-0178 this was fairly vague, but the upshot is that it probably needs some revision: 1) The right way to specify the jid you're expecting to become is by using the from attribute of the stream. This is most especially true for servers. 2) As far as I'm aware, all servers will handle you specifying it as the Authorization Identifier as well, even if the certificate is unambiguous. 3) Not specifying it anywhere will probably be OK. You don't know how the server will map the certificate anyway. 4) The client should know how to find a jid from a certificate, otherwise it can't validate the server's certificate... So a sane UI will be doing this anyway. Dave.
