(I have read the entire theread, but I think it's most suitable to
respond to this)
On Wed Dec 19 18:44:22 2007, Alex Jones wrote:
A few months ago, I became concerned with XEP-70: Verifying HTTP
Requests via XMPP[1]. As far as I can tell, deployment of this XEP
would potentially allow for malicious abuse.
The protocol seems to be a little backward, in that I can provide a
relying party with any arbitrary JID (in the HTTP request), and
then they will send a message to that JID. This is a bad idea, and
it allows me to initiate spam against anyone I know the JID of.
It's also a bit of a hack - a single website can't support more than
one XEP-0070 authentication realm, for instance.
What's going on with XEP-101: HTTP Authentication Using Jabber
Tickets[2]? It's "Deferred", yet it seems to, more or less, do the
same thing in a better fashion.
Although the HTTP client needs to support a new authentication
method, this seems closer to the ideal. But the authentication itself
is somewhat weak - it's relying on ticket expiration to try to
mitigate replay attacks, and pretty well all of the Security
Considerations section looks a little hand-wavy to my (jaded and
cynical) eyes.
I envisage going to a website, clicking "Authenticate via XMPP",
having my browser and my XMPP client do some IPC magic and prompt
me to choose an identity (i.e. a JID) for which to authenticate
as, and then be authenticated with the website.
Both XEP-0070 and XEP-0101 appear to require client support to get
the kind of usability that you want, but XEP-0070 has the interesting
advantage that with a naïve browser, and a clever user, one might
recognise the "xmpp" realm and react accordingly.
I'm wondering if we can do a little better by merging the two.
If the realm in XEP-0070 contained a full JID of the entity to
contact for the ticket, rather than just a fixed string, that might
help. HTTP servers would then have the capability to handle multiple
realms. But rather than the client sending a JID for the server to
contact, I prefer the notion of acquiring a ticket, as with XEP-0101.
However, the form of the ticket in XEP-0101 is really no better than
a plaintext password, so I'm not too keen on that either - if you're
going to go to the extent of having a new HTTP authentication method,
it seems logical to make it secure.
If you want to reuse Basic, then it seems more cunning to just reuse
Basic, and make the "dumb" HTTP interaction be a simple account
provision.
So, how about this as a XEP-0070 replacement:
a) The HTTP negotiation uses XEP-0070 style, but with an XMPP URI as
the realm of Basic Auth (or, I think, any password-based HTTP auth
mechanism). This URI would contain both a full JID of the
authentication entity.
b) A clever client or user can then provision an account:
i) Using an <iq/> stanza that includes the URI of the resource
requested, and a client-key.
The client-key is a plaintext equivalent string which should be
unique to the server's realm. A simple method for generating such a
key is to calculate a hash over the server's authentication JID and a
client "master password", which implies that the hash used must be
strong against preimage attacks. (Luckily, they all are).
ii) The HTTP server then stores this client-key, responding suitably.
c) This is then used as a password, with the username of the bare
JID, by the client. If the authentication is rejected, the client can
assume that the password has expired, and go setup a new one.
Note that client-key is a plaintext equivalent, but I couldn't think
of a way of securing it without breaking something else. The nice
thing about this is that it's possible to code it purely in XMPP -
the HTTP server itself doesn't need any code, since this is about
provisioning an account in the .htpasswd or equivalent, and setting
the realm. Even the JID doing the provisioning could, if needs be, be
a human.
The HTTP server needs to trust the entity provisioning the account -
nothing new there. The entity doing the provisioning needs to trust
that the JID is uncompromised, so nothing new there.
Now, a replacement for XEP-0101 - ie, inventing a new HTTP auth
mechanism which interacts with XMPP in some useful way - requires a
bit more thought, and thought is currently reserved for what to get
my wife for Christmas, so I'll try to remember to post some thoughts
in the new year.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
