Every packet sent from client to server, with exception of packets for
channels, are encrypted with this session key.
-Channels has their own key that are shared by every client on the channel.
+Channels has a channel key that are shared by every client on the channel.
However, the channel keys are cell specific thus one cell does not know
the channel key of the other cell, even if that key is for same channel.
Channel key is also known by the routers and all servers that has clients
message delivery key with each other and that is used in
the message encryption.
-o Client 1. sends encrypted packet to its server. The packet is
- encrypted with the private message delivery key shared between
- clients.
+o Client 1. sends encrypted packet to its server. The packet header
+ is encrypted with the session key shared between the client and
+ server, and the private message is encrypted with the private
+ message delivery key shared between clients.
o Server determines the destination of the packet and sends the
packet to the router.
3.9.1 Authentication Payload
Authentication payload is used separately from the SKE and the Connection
-Authentication protocol. It is used during the session to authenticate
+Authentication protocol. It can be used during the session to authenticate
with the remote. For example, the client can authenticate itself to the
server to become server operator. In this case, Authentication Payload is
used.
.in 6
o Payload Length (2 bytes) - Length of the entire payload.
-o Authentication Method (2) - The method of the authentication.
- The authentication methods are defined in [SILC2] in the
- Connection Auth Request Payload. The NONE authentication
- method SHOULD NOT be used.
+o Authentication Method (2 bytes) - The method of the
+ authentication. The authentication methods are defined
+ in [SILC2] in the Connection Auth Request Payload. The NONE
+ authentication method SHOULD NOT be used.
o Public Data Length (2 bytes) - Indicates the length of
the Public Data field.
the signature process, described subsequently.
o Authentication Data Length (2 bytes) - Indicates the
- length of the Authentication Data field.
+ length of the Authentication Data field. If zero (0)
+ value is found in this field the payload MUST be
+ discarded.
o Authentication Data (variable length) - Authentication
method dependent authentication data.
cryptography function selected in the SKE protocol. The public key
is SILC style public key unless certificates are used. The ID is the
entity's ID (Client or Server ID) which is authenticating itself. The
-ID is raw ID data. The random bytes are non-zero random bytes of
-length between 128 and 4096 bytes, and will be included into the
-Public Data field as is.
+ID encoding is described in [SILC2]. The random bytes are non-zero
+random bytes of length between 128 and 4096 bytes, and will be included
+into the Public Data field as is.
The receiver will compute the signature using the random data received
in the payload, the ID associated to the connection and the public key
(or certificate) received in the SKE protocol. After computing the
-receiver MUST verify the signature. In this case also, the entire
-payload is encrypted.
+receiver MUST verify the signature. In case of public key authentication
+this payload is also encrypted.
.ti 0
Protocol version MAY provide both major and minor version. Currently
implementations MUST set the protocol version and accept at least the
protocol version as SILC-1.1-<software version>. If new protocol version
-causes in compatibilities with older version the the <minor> versio number
+causes incompatibilities with older version the <minor> version number
MUST be incremented. The <major> is incremented if new protocol version
is fully incompatible.
authentication.
When server receives the SILC_PACKET_RESUME_CLIENT packet it MUST
-verify that the Client ID is valid client and that it has the
-SILC_UMODE_DETACHED mode set. It then MUST verify the Authentication
-Payload with the detached client's public key. If it does not have
-the public key it MUST retrieve it by sending SILC_COMMAND_GETKEY
-command to the server that has the public key from the original
-client connection. The server MUST NOT use the public key received
-in the SKE protocol for this connection. If the signature is valid
-the server MUST unset the SILC_UMODE_DETACHED flag, and send the
-SILC_PACKET_RESUME_CLIENT packet to its primary router. The routers
-MUST broadcast the packet and unset the SILC_UMODE_DETACHED flag
-when the packet is received. If the server is router server it also
-MUST send the SILC_PACKET_RESUME_CLIENT packet to the original server
-whom owned the detached client.
+do the following: Server checks that the Client ID is valid client
+and that it has the SILC_UMODE_DETACHED mode set. Then it verifies
+the Authentication Payload with the detached client's public key.
+If it does not have the public key it retrieves it by sending
+SILC_COMMAND_GETKEY command to the server that has the public key from
+the original client connection. The server MUST NOT use the public
+key received in the SKE protocol for this connection. If the
+signature is valid the server unsets the SILC_UMODE_DETACHED flag,
+and sends the SILC_PACKET_RESUME_CLIENT packet to its primary router.
+The routers MUST broadcast the packet and unset the SILC_UMODE_DETACHED
+flag when the packet is received. If the server is router server it
+also MUST send the SILC_PACKET_RESUME_CLIENT packet to the original
+server whom owned the detached client.
The servers and routers that receives the SILC_PACKET_RESUME_CLIENT
packet MUST know whether the packet already has been received for
same server that it originally came from. They must update their
caches according this. The server that now owns the client session
MUST check whether the Client ID of the resumed client is based
-on the server's Server ID. If it is not it MUST create new Client
+on the server's Server ID. If it is not it creates a new Client
ID and send SILC_NOTIFY_TYPE_NICK_CHANGE to the network. It MUST
also send the channel keys of all channels that the client is
joined to the client since it does not have them. Whether the
to the network and may start sending packets and messages.
It is also possible that the server does not know about the channels
-that the client has joined. In this case it MUST join client internally
+that the client has joined. In this case it join the client internally
to the channels, generate new channel keys and distribute the keys
to the channels as described in section 4.4.
projects / silc.git / blobdiff