[Security] XEP-0189 and XEP-0178 Interaction

Johansson Olle E oej at edvina.net
Wed Sep 10 05:11:21 CDT 2008

10 sep 2008 kl. 11.24 skrev Dirk Meyer:

> 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.
Hmm. Need to check that. Someone?

>> 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?

Well, my proposal was late-night security-by-obscurity. Only the
client would know the "pin code" that is the address of the pubsub
node - that would remain open for two minutes or something.

A better solution is propably something we all want :-)


More information about the Security mailing list