[Authentication] Spec review (part 1)

[Michael Leupold]

Hi Eckhart,

sorry for taking a while to review your ideas. Life has been busy for
me during the last two weeks.

2010/9/9 Eckhart Wörner <ewoerner at kde.org>:
> 1) I talked to the D-Bus people and we agreed on that there's no use for
> encryption on D-Bus at all. As soon as you've the possibility to eavesdrop the
> D-Bus communication, you're also able to do a man-in-the-middle attack.
> My proposal here is to get rid of encryption completely. This makes
> implementation of client libraries much easier.

I've thought about it again. I'm not sure a man-in-the-middle attack
is actually possible. Of course our applications don't carry
certificates or similar to authenticate to each other, but talking
over D-Bus at least the service can check who the client is using its
pid. As I understand it a possible attacker who successfully manages
to convince the client that he's the real service would afterwards
still have to convince the service that he's the actual client. This
can be avoided using ACLs (the same the service would implement to
only allow trusted applications to access its secrets).

The other direction might be simpler to attack unless the client uses
the service's pid to check if it's really the service. We should
probably think about whether this should be implemented as well.

In my eyes this mostly leaves the question whether the transport can
be secured using some other means (eg. disabling eavesdropping). I
don't think it is. Reading up on transports used by D-Bus, I don't see
any guarantees as to whether the transport used can be listened to. It
even says (in the section TCP Sockets):
"The tcp transport provides TCP/IP based connections between clients
located on the same or different hosts.
Using tcp transport without any additional secure authentification
mechanismus over a network is unsecure."

I think session encryption provides additional security and thus don't
want to get rid of it.

> 2) On the other hand, encryption introduces a lot of ugliness. Secrets are put
> on the bus as byte arrays, at the moment it isn't even specified how
> (decrypted) byte arrays translate to strings afterwards. Getting rid of
> encryption allows to use the D-Bus type system. Two possibilities:
> a) secrets are D-Bus variants ("v")
> b) overloading for several common types (like "s", "ay" and "a{ss}")

I agree that this is a bit of a mess and an oversight on my part. I
think we should specify how those secrets are encoded. I see two ways:

1. Add an extra property to detail how the secret of an item is
encoded. Possible values and encodings have to be specified.

2. Specify that the decrypted secret IS a D-Bus variant.

> 3) Since the spec says that items can be locked / unlocked individually, a
> "Locked" property for the collection makes no sense.

We talked about this and I'm actually not really sure about what this
means either.

@Stef: Was this supposed to mean that all items in the collection are
unlocked or that the collection itself is ready for change (adding
items/changing properties)? How did you implement it?

> 4) There's an artificial separation between items that don't need a Prompt and
> items that do so. I suggest to change this so that as soon as a call *might*
> take some time, a prompt is returned.

Prompt are meant for calls that block because they require user
interaction. The spec was crafted so that for each call this might be
the case for, a prompt can be returned. Do you think there are others
where this might make sense?

> 5) Unlocking of the secret storage might take some time without ever creating
> a prompt (e.g. hardware needed takes some time to initialize, etc). I suggest
> to rename Prompt to Job.

I don't think renaming it is worth it, even if it might make sense
semantically. After all there's already software out there which uses
the spec.

Regards,
Michael