On 14 jun. 2013, at 23:10, Dave Cridland wrote: > 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.
Thanks for clearing that up, the lack of an authcid in this XEP confused me. > 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. I'm still not sure I understand 10(c), though. Does "the address specified during SASL negotiation" refer to the "from" attribute on the <stream>? Thijs
signature.asc
Description: Message signed with OpenPGP using GPGMail
