Linking according to specification (aka new PSYC)

Linking to an Identity

The main purpose for a location (usually a user's client) to be on the PSYC network is to get linked to one or several identities (usually a person entity) in order to be able to execute commands or send messages on its behalf. The location application was probably given a UNI, so it needs to resolve that uniform in order to create a circuit to it, then negotiate a link to it, which is done by subscribing to the links channel of the UNI.

The packet has to be _targeted at the UNI and optionally
provide a UNL as _source. This is an example:

It uses the context subscription protocol as defined earlier.
When (after authentication) the link could be established, typically a _notice_context_enter
packet is multicast from the identity to all subscribed locations.
The _source variable must contain the UNI (the identity's
uniform) and the _target variable the UNL (the location's uniform):

Hash based authentication

In order for the identity to check whether the _source of the
_request_link is allowed to link it sends a _request_password
packet to the _source as reply to the _request_link packet.
The reply contains a _nonce variable that is used to do hash-based
authentication as follows as well as a _password variable with the ?queryoperator.

You should proceed by sending a _request_context_enter again with the variable
_method set to the hash function used and _password containing
the hex encoded hash of the nonce and the password, concatenated.

The hash function to use can be chosen from the list in _available_hashes,
which is one of these:

The password field in the reply contains sha1(nonce + password) = sha1('6eaa3554xfippox') = '68fe60d9b3989848c39842bb3038f515bf7979d3'.
The + operator in this case is intended as string concatenation.
Note that you don't need to resend the _nonce.

If the password was correct you will receive a _notice_link as described
earlier. But if the password was wrong a _error_invalid_password packet
is generated as response, which looks similar to this:

Linking a UNI

By requesting a link you request an authoritative controlling type of
connection to the entity, not just entering it. Although this could still
be seen as a special case of entering in the grand scheme of subscription,
it currently isn't. Here's the typical procedure of a client linking to
its user's UNI.

Note that there is no more explicit target sent in the following packets,
they are assumed to be added on client side by the state machine.
If a password for the account is set, you will be queried to supply it:

The _available_hashes are sent at circuit establishment time in the _status_circuitpacket, so you don't have to try something out.

Here's one way to deliver the password:

send:

.
:_password xfippox
:_tag whatever
_request_link
.

You may however want to not transmit the password in clear text over the wire.
In this case you can apply a hashing method to the concatenated list
of _nonce and _password. On reply you must supply the the _method used (any of the strings listed in _available_methods_hash) and the resulting hash in _password, still using the _request_link mc. You should not supply the _nonce again and the server must not make use of any _nonce supplied in the reply.

The password field contains sha1(nonce + password) = sha1('6eaa3554xfippox') = '68fe60d9b3989848c39842bb3038f515bf7979d3'. The + operator in this case is intended as string concatenation. Note that you don't need to resend the _nonce.

Reasoning: By using the challenge from the server contained in the nonce, you are making a unique temporary variant of the password valid only now and only once, so an attacker cannot reuse it later (She can still steal your TCP connection though, if she has access to any intermediate routing device. To protect yourself from that you need encryption like TLS). This part is supposed to become conformant to SASL, by the way.