Re: About re:claimID

[Martin Schanzenbach]

Hi,

On Sat, 2020-12-05 at 21:52 +0100, Alessio Vanni wrote:
> Hello,
> 
> for a number of reasons I'm looking into ways to authenticate a user
> with a custom service (i.e. not something already existing), so I
> started checking out re:claimID as it seems to be the solution.
> 
> I have two questions about it:
> 
> 1. is there some other documentation aside from what is on the
> website
> and the C header file? The website only talks about interfacing
> re:claimID with the web and that's not what I'm trying to do, so it's
> not really helpful; about the header file, it explains what the API
> does
> but I'm not too sure about how to actually use it.

The gist of the flow is also here:
https://docs.gnunet.org/handbook/gnunet.html#reclaimID-Identity-Provider

Basically:
1. A relying party requests a set of attributes from the user
2. The user decides if he wants to share the attributes (if no,
protocol ends).
3. The user issues a ticket for the relying party for the specific set
of attributes.
4. The user transfers the ticket to the relying part (out of band!).
5. The relying party can retrieve the requested attributes using the
ticket.

One thing to note is that reclaimID by itself is just a means to
*authorize access to identity attributes*.
In other words, it is not directly a means to authenticate.
This is a common misconception.
So, even if another party is able to provide you with a "Ticket", you
MUST verify that this party is actually the issuer of the Ticket.
Similarly, when issuing a Ticket, you must verify that the requesting
party is actually in possession of the respective public key.

You could do this, for example, using public key challenge response
authentication.
When using the OpenID Connect layer, this is implemented within the
OpenID protocol => Implicit authentication of the identities through a
mix of challenge-response and HTTPS domain validation.

If you only use the C API (gnunet_service_reclaim.h) in a custom non-
web use case, you MUST implement your own secure channel.


> 
> 2. if I issue a ticket, which seems to be the way to perform
> authentication, is it readable only by the other party or can anyone
> find it and read what's inside the ticket? What I mean is: I issue a
> ticket for Bob and then send it to him; if Alice intercepts the
> ticket,
> can she read what's inside the ticket? I would assume she wouldn't be
> able to, but I'd rather ask first.

See above. The ticket as issued by the API is not encrypted or
anything. If you need encryption, you need to do it yourself as part of
your "handover" protocol.
Essentially, the transfer of the Ticket to the other party is
considered an "out of band" protocol. If you do not already have a
secure channel (such as TLS with OpenID Connect), you need to establish
one yourself.

What you could do is simply encrypt the ticket for Bob (using ECDHE)
and sign it along with a challenge from Bob using your private key.
This would allow you to make sure that:
1. Bob can verify the ticket issuer is actually who he claims to be
through public-key challenge-response authentication.
2. You can be sure that only Bob can "read" the ticket.

This leaves you with a last problem (that you could also just ignore
depending on the use case): Establishing trust in the requesting party
= Bob.
Why should the user trust Bob with a ticket or provide an
authentication response to him? In OpenID Connect, this is solved by
having the requesting party linked to a HTTPS URL.
In modern crypto messengers, this is often done using a display of
verification codes which must be compared out of band.

Trust in a public key (identity) in GNS/GNUnet/reclaimID/p2p is a hard
issue and not solved by slapping reclaimID onto the problem. Decades of
research have not yielded any meaningful method for establishing trust
in a decentralized fashion so you need some kind of out of band
mechanism.
For example: You could implicitly trust all of your GNS root
delegations configured in gns.conf. Or you could employ the trust model
of crypto messengers (trust on first use + strong verfication through
out of band user interaction).

>  I'm asking this because I can't think
> of any way to notify Bob about my ticket aside from sending the GNS
> record label to him, making it essentially "public" assuming there's
> a
> way to spy on Bob either during transmission or by peeking over his
> shoulders.

When you communicate with Bob, you should do that through a secure
channel. If you are able to issue a Ticket to Bob, then you must be in
possession of his public key. So you should be able to authenticate the
channel or encrypt it for Bob.
"Peeking" over his shoulders (in real life) is still possible, of
course. But I do not see a reason why you would ever actually display
the ticket/label to the user.

The label under which the ticket is stored in GNS by the issuer is not
really "public". It is actually a 256 bit nonce. Due to the properties
of GNS, this makes it a shared secret. So your protocol must make sure
that the Ticket (which contains the nonce as well) is not leaked.

BR
Martin

> 
> Thank you,
> A.V.
>

signature.asc
Description: This is a digitally signed message part