ARM4FS Identity Provider Integration - Revision history

Cpunkt at 21:55, 31 October 2006

2006-10-31T21:55:07Z

← Older revision		Revision as of 21:55, 31 October 2006
Line 12:		Line 12:

	[http://www.informatik.hu-berlin.de/~ccarsten/Identity_Provider_Interaction_Schema.fig Identity_Provider_Interaction_Schema.fig]		[http://www.informatik.hu-berlin.de/~ccarsten/Identity_Provider_Interaction_Schema.fig Identity_Provider_Interaction_Schema.fig]


	# The user sends his authentication information along with a new public key PK1 to an identity provider. The identity provider must know either by convention or by negotiation about the set of ID features required by the system. The secret key that corresponds to PK1 will be termed SK1.		# The user sends his authentication information along with a new public key PK1 to an identity provider. The identity provider must know either by convention or by negotiation about the set of ID features required by the system. The secret key that corresponds to PK1 will be termed SK1.

Cpunkt at 12:37, 31 October 2006

2006-10-31T12:37:04Z

← Older revision		Revision as of 12:37, 31 October 2006
Line 11:		Line 11:
	[[Image:Identity Provider Interaction Schema.png]]		[[Image:Identity Provider Interaction Schema.png]]

			[http://www.informatik.hu-berlin.de/~ccarsten/Identity_Provider_Interaction_Schema.fig Identity_Provider_Interaction_Schema.fig]
	[[Media:Identity Provider Interaction Schema.fig]]

	~~Step 1:~~ The user sends his authentication information along with a new public key		# The user sends his authentication information along with a new public key PK1 to an identity provider. The identity provider must know either by convention or by negotiation about the set of ID features required by the system. The secret key that corresponds to PK1 will be termed SK1.
			# After verifying the user's authentication information the identity provider hashes the previously defined set of ID features and issues an x.509 certificate containing this hash, the features used for hashing and the key PK1. This certificate is signed with the identity providers secret key IPSK. We'll call the corresponding public key IPPK. The hash certificate is sent back to the user.
	PK1 to an identity provider. The identity provider must know either by
			# The user takes the hashed ID certificate and sends it to a third instance, termed the identity anonymizer. We need this instance, because the hashed ID, in conjunction with knowledge about the set of ID features allows a potential attacker to check known user identities against hash values. The user also sends a signature on this certificate using key SK1. A second public key PK2 is generated by the user and transmitted to the identity anonymizer. We could also use PK1 again, but this could possibly allow an attacker to identify the user.
	convention or by negotiation about the set of ID features required by the
			# After verifying the hashed certificate and checking the user's signature against PK1 the identity anonymizer issues a new x.509 certificate containing a unique but random user ID along with key PK2. This certificate is sent back to the user.
	system. The secret key that corresponds to PK1 will be termed SK1.
			# The user sends this certificate to the ARP, which checks the identity anonymizer's signature and uses public key PK2 for securing the connection. We do not need a signature with SK2 on the certificate, because the user proves his knowledge of it by being able to decrypt messages from the ARP.

	Step 2: After verifying the user's authentication information the identity provider
	hashes the previously defined set of ID features and issues an x.509
	certificate containing this hash, the features used for hashing and the
	key PK1. This certificate is signed with the identity providers secret
	key IPSK. We'll call the corresponding public key IPPK. The hash certificate
	is sent back to the user.

	Step 3: The user takes the hashed ID certificate and sends it to a third instance,
	termed the identity anonymizer. We need this instance, because the hashed
	ID, in conjunction with knowledge about the set of ID features allows a
	potential attacker to check known user identities against hash values. The
	user also sends a signature on this certificate using key SK1. A second
	public key PK2 is generated by the user and transmitted to the identity
	anonymizer. We could also use PK1 again, but this could possibly allow an
	attacker to identify the user.

	Step 4: After verifying the hashed certificate and checking the user's signature
	against PK1 the identity anonymizer issues a new x.509 certificate containing
	a unique but random user ID along with key PK2. This certificate is sent back
	to the user.

	Step 5: The user sends this certificate to the ARP, which checks the identity
	anonymizer's signature and uses public key PK2 for securing the connection.
	We do not need a signature with SK2 on the certificate, because the user
	proves his knowledge of it by being able to decrypt messages from the ARP.

Cpunkt: /* Proposal */

2006-10-31T12:00:31Z

Proposal

← Older revision		Revision as of 12:00, 31 October 2006
Line 10:		Line 10:

	[[Image:Identity Provider Interaction Schema.png]]		[[Image:Identity Provider Interaction Schema.png]]

			[[Media:Identity Provider Interaction Schema.fig]]

	Step 1: The user sends his authentication information along with a new public key		Step 1: The user sends his authentication information along with a new public key

Cpunkt at 11:56, 31 October 2006

2006-10-31T11:56:17Z

← Older revision		Revision as of 11:56, 31 October 2006
Line 8:		Line 8:

	== Proposal ==		== Proposal ==

			[[Image:Identity Provider Interaction Schema.png]]

	Step 1: The user sends his authentication information along with a new public key		Step 1: The user sends his authentication information along with a new public key

Cpunkt at 11:54, 31 October 2006

2006-10-31T11:54:17Z

New page

[[Category:ARM4SNS]] [[Category:ARM4FS]]

== Problem ==

Anonymous Reputation Provider (ARP) needs proof of identity in order to prohibit
sybil attacks. On the other hand, user identities should not be stored on the ARP,
because in case of, e.g. a raid this would compromise the users' anonymity.

== Proposal ==

Step 1: The user sends his authentication information along with a new public key
PK1 to an identity provider. The identity provider must know either by
convention or by negotiation about the set of ID features required by the
system. The secret key that corresponds to PK1 will be termed SK1.

Step 2: After verifying the user's authentication information the identity provider
hashes the previously defined set of ID features and issues an x.509
certificate containing this hash, the features used for hashing and the
key PK1. This certificate is signed with the identity providers secret
key IPSK. We'll call the corresponding public key IPPK. The hash certificate
is sent back to the user.

Step 3: The user takes the hashed ID certificate and sends it to a third instance,
termed the identity anonymizer. We need this instance, because the hashed
ID, in conjunction with knowledge about the set of ID features allows a
potential attacker to check known user identities against hash values. The
user also sends a signature on this certificate using key SK1. A second
public key PK2 is generated by the user and transmitted to the identity
anonymizer. We could also use PK1 again, but this could possibly allow an
attacker to identify the user.

Step 4: After verifying the hashed certificate and checking the user's signature
against PK1 the identity anonymizer issues a new x.509 certificate containing
a unique but random user ID along with key PK2. This certificate is sent back
to the user.

Step 5: The user sends this certificate to the ARP, which checks the identity
anonymizer's signature and uses public key PK2 for securing the connection.
We do not need a signature with SK2 on the certificate, because the user
proves his knowledge of it by being able to decrypt messages from the ARP.