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 :-)
/O
