[Security] XEP-0189 and XEP-0178 Interaction

Dirk Meyer dmeyer at tzi.de
Wed Sep 10 04:24:03 CDT 2008

Johansson Olle E wrote:
> 9 sep 2008 kl. 20.51 skrev Dirk Meyer:
>> Hi,
>> In the thread Thread 'Hosted solutions - client/user certs' started by
>> Johansson Olle E. the idea of client cert with SASL came up.
>> I want to use a new client. I do not trust that client for its
>> life-time. E.g. a mobile phone can get stolen. It would be nice if
>> this client can log into my account without having my password.
>> XEP-0178 defines SASL-EXTERNAL but it is unclear where the certificate
>> comes from.
> I propose that you separate the public key, private key and the cert
> to be able to discuss the logic here. The cert is just a signed wrapper
> around the public key. The private key is a very important part.
> My idea was to have a client ID and a user ID. The user ID was
> allowed to delegate authority to clients by signing the client's
> public key in a cert format with the CN being the clients full JID,
> that is with a locked resource to prevent multiple logins.

So I client ID is the full JID and each full JID MAY have it's own
private key and certificate. The ressource is encoded in the
certificate. The CN being the clients full JID is a problem because
AFAIK you can not use a slash in the CN.

> Storing it with pubsub seems like a smart idea. The question
> is how the "client" gets access to pubsub without authorization.
> That's food for thought. You don't want to open up for DOS attacks.
> Thinking about your original analogy with bluetooth or the
> AppleTV synch authorization, a shared secret might work.
> * The USER uploads a pin code to a pubsub node.
> * The CLIENT uploads a CERT to a pubsub node which
>    has an ID in the form of a PIN number.

How can the client do that without a way to log in into my account?
Maybe we can do something like iq-register together with tokens. This
is independed of PubSub right now and only a basic idea.

1. USER sends a temp. password and ressource name to the server. This
   information is passed to the new client (e.g. it is again the user
   wanting to use this client).

2. CLIENT logs in and presents the certificate during STARTTLS

3. Server presents the SASL feature AND a feature to use the temp
   password. E.g. it could use sha1(temp.password+ressource) in SASL.

4. CLIENTS sends temp password and ressource. After that the temp
   password is invalid and can never be used again.

5. Server checks ressource against ressource in the certificate and if
   the temp password matches. If it does it adds the client
   certificate as client to be used for login. E.g. it could auto-add
   it to the pubsub node or use something else which provides the user
   to check which certificates are in the system

For a new bot in the network link-local messaging can be used

1. CLIENT starts and has no idea about its JID, server, password. It
   creates a certificate with the ressource it wants to have.

2. CLIENT searches for other clients using mDNS and discovers
   someone. It opens a connection to USER.

3. They can not verify each other and use SRP (the password is in the
   handbook of the CLIENT or printed at the back)

4. USER requests certificate from CLIENT and uploads it to the server

5. CLIENT uses the bare JID from the peer it is talking to and its
   password to log in.

To prevent a bad client to add many other clients we could require the
password in the first step and/or store permissions if a ressource is
allowed to add others.


Viewer discretion may be advised, but it's never really expected.

More information about the Security mailing list