LID-FAQ-Security

From lid.netmesh.org

Jump to: navigation, search

Questions about LID security

Contents

Who may request the public key?

In the request to retrieve the public key, by an HTTP GET request to the LID URL with parameters meta=gpg%20--export%20--armor (LID 1.0) or lid-meta=gpg%20--export%20--armor (LID 2.0), e.g. http://netmesh.info/jernst?meta=gpg%20--export%20--armor: There is no mention of access control, so I assume this means this request can be made anonymously, by anyone?

That's the intention, otherwise a certain set of users and/or activities cannot be authenticated under certain circumstances.

However, we don't see a reason why a LID implementation could not be more restrictive, such as by only responding to those incoming requests for the public key which it has reasons to believe it has triggered itself. The actual policies can be left to the LID URL owner and the software the owner choose to run: if, for example, the policy has been set too restrictively, and a public key cannot be obtained by a site that has a legitimate reason for asking for it, that site most likely will not process the LID URL's owner's request any further, thereby hurting nobody other than the LID URL owner themselves who set the too-restrictive policy.

This ability to set different policies, on a per LID URL basis, and based on the particular convenience-paranoia tradeoff. Putting this decision into the hands of the user (or a service provider that is trusted by the user by virtue of having been selected by that user) is an important feature of LID(tm).

Can public keys be cached?

In the response [to a public key request], is there a notion of a validity period in the public key block? Would recipients of this info be able to cache it?

We expect public keys to be fairly stable over some period of time, like most GPG keys.

The LID 2.0 Mechanics Profile allows clients to obtain the necessary information.

How does LID encourage or prevent identity correlation?

If I use LID, don't I leave the same URL all over the web, and everybody can track my every move all over the web?

If you use only a single LID URL, that is indeed true. However, users are encouraged to compartmentalize their identity by using several LID URLs. See also Identity correlation.

Do LID pseudonyms have different public keys?

When there is LID pseudonym delegation occuring, are requests to retrieve a public key delegated as well, or does each server maintain its own potentially distinct public key?

There must be one different key per LID URL, otherwise correlating the pseudonyms is trivially simple, and there would be no point of having different LID pseudonyms in the first place.

How can a DDoS attack be prevented given that LID-enabled sites perform callbacks?

It appears web servers themselves make GET requests to a URL of the client's choosing, when authenticating the client. LID resources may "call back" to the originating server, e.g. by obtaining the public key from the originating server. A malicious client may present a URL with a valid syntax but that is not their actual host server, e.g. http://www.whitehouse.gov or http://internal-server, appears to be similar to this FTP "PORT" problem: in a DDoS attack suddenly dozens or hundreds of LID(tm)-aware servers are all sending requests for /XXX?meta=gpg%20-export%20--armor to an unsuspecting web server. How is this dealt with in LID(tm)?

The site generally should perform this algorithm:

  • is the incoming URL already known as a user of this site?
  • if already known, validate request against public key from cache (see above) instead of obtaining the public key anew from the LID
  • if cache is considered out-of-date, perform the key request

Note that unlike in some of the ftp scenarios mentioned above, any information obtained by the site never gets passed back to the attacker.

The site may also require any new user to pass a series of tests (e.g. picture reading) in order to prevent spots from signing up. Such a policy is up to the individual site; a wide range of possible policies are compatible with LID.

Can abandoned LID URLs be maliciously reclaimed?

There does not appear to be any mention of uniqueness in time or validation to prevent reuse of URLs, or a means of revocation notification. If Alice has an account on example.net and thus has LID URL http://example.net/alice, and provides this info to her friend Bob, Bob may place the URL http://example.net/alice into Bob's server's access control configuration to allow Alice to see private info of Bob's. Later Alice decides to move to another service provider, her account on example.net lapses, and Carol signs up at example.net under the pseudonym "alice". Later Carol accesses Bob's server, using http://example.net/alice. Bob's server contacts example.net, and validates that the requestor does indeed have that URL. Unfortunately that URL is not that of the original Alice.

Alice will delete her private key from her account when she leaves. Thus, Carol will be unable to sign requests with the same key and Bob can deny authorization. Unfortunately, this will also cause Alice to not be recognized by Bob once her key expires. But I guess that problem is in no way unique to LID.

We may come up with some sort of key "transition" protocol some day ... as an extension of the LID 2.0 Mechanics Profile, perhaps.

Retrieved from "http://lid.netmesh.org/wiki/LID-FAQ-Security"
Personal tools