-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/15/13 4:05 AM, Thijs Alkemade wrote: > > On 14 jun. 2013, at 23:10, Dave Cridland wrote: > >> On Fri, Jun 14, 2013 at 9:23 PM, Thijs Alkemade <[email protected] >> <mailto:[email protected]>> 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>?
IMHO that would indeed be the 'from' on the initial stream header. It would be good to clear that up in the spec, eh? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRwnOwAAoJEOoGpJErxa2puPcP/1hDb4OCuZ+nfc440k6PZ8EA JAX0rhgbDKpOWO1IkSdud62xszt27mX7MRflzDaATDBWE/0RilubGu8XIkAzU5Bc 01rGVDEse0P9K6LaHpgJ0ViQumDNG8tclxrZF6lN/mePaTfwqrflR9z+vcMyhXPC fNwNkUrDG0Ufpx2/PsFz21Z0rfMIuCxEYbUAm2nBAYuhTAdNM40SexN/vxx4nycf TWvDQNXH1V5DGyW7KWPyyuD0q6Cmhuz5Igfet1fBAKX0/JW1MMKWqkv0fhZewZaz 4CdwmCc9SEd5bDV7xtprtQIi4OO19BEpU5TNfcCXN5m/YyOV+TSbu0vHY5obX2ud RCo2ow8ifkTNKsPkFG2Yfg9i3QFD+9FOVEflQFBQV221prlquFZqrzakSoB5uOVH xlJ5+0pQO1+8szM2k3nDkYxPEPa5BO0oeg8vaz3ryWoZ0p84quRmKiHUbVwrMaBh ffxeaEZKfXPGFv8h2+2G773VOvfY5YfQ5PePIUBA7JTlh/CMPRIgq4xcNElAyzBf TBilPkz+lIsXpUAiEs8+a+pFq83DVtRLR8V8FbxEMSFDakXQYoB1Tq73YO46iuRL EHtJhYgBMdsVl1sX5b7BQnP4YCS4h5kf9oq2d+mmtXwGQQCX0DHLjANKG8Awhxvv A4MWhaI6LVbxSfQgwJcn =5IYc -----END PGP SIGNATURE-----
