2.1 SILC Commands Syntax ...................................... 4
2.2 SILC Command Argument Idioms .............................. 4
2.3 SILC Commands List ........................................ 5
- 2.4 SILC Command Status Payload ............................... 42
-3 SILC Status Types ............................................. 43
-4 Security Considerations ....................................... 50
-5 References .................................................... 50
-6 Author's Address .............................................. 51
-Appendix A ...................................................... 51
-Full Copyright Statement ........................................ 53
+ 2.4 SILC Command Status Payload ............................... 43
+3 SILC Status Types ............................................. 44
+4 Security Considerations ....................................... 51
+5 References .................................................... 51
+6 Author's Address .............................................. 52
+Appendix A ...................................................... 52
+Full Copyright Statement ........................................ 54
.ti 0
2.3.3 Disconnect Payload .................................. 23
2.3.4 Success Payload ..................................... 23
2.3.5 Failure Payload ..................................... 24
- 2.3.6 Reject Payload ...................................... 24
+ 2.3.6 Reject Payload ...................................... 25
2.3.7 Notify Payload ...................................... 25
2.3.8 Error Payload ....................................... 34
- 2.3.9 Channel Message Payload ............................. 34
+ 2.3.9 Channel Message Payload ............................. 35
2.3.10 Channel Key Payload ................................ 35
2.3.11 Private Message Payload ............................ 37
2.3.12 Private Message Key Payload ........................ 37
2.3.13 Command Payload .................................... 39
2.3.14 Command Reply Payload .............................. 40
2.3.15 Connection Auth Request Payload .................... 40
- 2.3.16 New ID Payload ..................................... 41
+ 2.3.16 New ID Payload ..................................... 42
2.3.17 New Client Payload ................................. 42
2.3.18 New Server Payload ................................. 43
2.3.19 New Channel Payload ................................ 44
2.3.20 Key Agreement Payload .............................. 45
2.3.21 Resume Router Payload .............................. 46
- 2.3.22 File Transfer Payload .............................. 46
+ 2.3.22 File Transfer Payload .............................. 47
2.3.23 Resume Client Payload .............................. 48
2.4 SILC ID Types ............................................. 49
2.5 Packet Encryption And Decryption .......................... 49
2.5.2 Channel Message Encryption And Decryption ........... 50
2.5.3 Private Message Encryption And Decryption ........... 51
2.6 Packet MAC Generation ..................................... 52
- 2.7 Packet Padding Generation ................................. 52
+ 2.7 Packet Padding Generation ................................. 53
2.8 Packet Compression ........................................ 53
- 2.9 Packet Sending ............................................ 53
+ 2.9 Packet Sending ............................................ 54
2.10 Packet Reception ......................................... 54
2.11 Packet Routing ........................................... 54
- 2.12 Packet Broadcasting ...................................... 55
+ 2.12 Packet Broadcasting ...................................... 56
3 Security Considerations ....................................... 56
4 References .................................................... 56
5 Author's Address .............................................. 58
10 SILC_PACKET_PRIVATE_MESSAGE_KEY
- This packet can be used to agree about a key to be used to
- protect private messages between two clients. This packet
- is sent inside the SILC network and protected with session
- keys. There are other means of agreeing to use private message
- keys as well, than sending this packet which may not be
- desirable on all situations. See the [SILC1] for private
- message key generation. This packet MAY be sent to entity
- that is indirectly connected to the sender.
+ This packet is OPTIONAL and sender of the packet can indicate
+ that a private message key should be used in private message
+ communication. The actual key material is not sent in this
+ packet but must be either static or pre-shared key. The
+ receiver of the packet is considered to be the responder
+ when processing the static or pre-shared key material as
+ defined in [SILC1] and [SILC3] for private message keys.
+ This packet MAY be sent to entity that is indirectly connected
+ to the sender.
Payload of the packet: See section 2.3.12 Private Message
Key Payload
Payload
-
13 SILC_PACKET_KEY_EXCHANGE
This packet is used to start SILC Key Exchange Protocol,
+
.ti 0
2.3.2.4 Channel Payload
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
-~ Initial Vector * ~
+~ Initialization Vector * ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
Padding Length field includes a zero (0) value. The
padding SHOULD be random data.
-o Initial Vector (variable length) - This field MUST be
- present when this payload is used as channel messages.
+o Initialization Vector (variable length) - This field MUST
+ be present when this payload is used as channel messages.
The IV SHOULD be random data for each channel message.
When encrypting private messages with session keys this
in [SILC1] for more information about IVs when
encrypting private messages.
- This field includes the initial vector used in message
+ This field includes the initialization vector used in message
encryption. It need to be used in the packet decryption
as well. Contents of this field depends on the encryption
algorithm and encryption mode. This field is not encrypted,
o MAC (variable length) - The MAC computed from the
Message Flags, Message Length, Message Data, Padding Length,
- Padding and Initial Vector fields in that order. The MAC
- is computed after the payload is encrypted. This is so
- called Encrypt-Then-MAC order; first encrypt, then compute
- MAC from ciphertext. The MAC protects the integrity of
- the Message Payload. Also, when used as channel messages
+ Padding and Initialization Vector fields in that order.
+ The MAC is computed after the payload is encrypted. This
+ is so called Encrypt-Then-MAC order; first encrypt, then
+ compute MAC from ciphertext. The MAC protects the integrity
+ of the Message Payload. Also, when used as channel messages
it is possible to have multiple private channel keys set,
and receiver can use the MAC to verify which of the keys
must be used in decryption. This field is not present
that was watched is same the notify SHOULD NOT be sent.
-
-
-
.ti 0
2.3.8 Error Payload
-
-
-
-
.in 5
.nf
1 2 3
to use a private key to protect just the private messages. It is
for example possible to perform Key Agreement between two clients.
See section 2.3.20 Key Agreement Payload how to perform key
-agreement. See also section 2.3.12 Private Message Key Payload
-for another way of using private keys with private messages. See
-[SILC1] section 4.6 for detailed description for private message
-key generation procedure.
+agreement. It is also possible to use static or pre-shared keys
+to protect private messages. See the 2.3.12 Private Message Key
+Payload and [SILC1] section 4.6 for detailed description for private
+message key generation.
If normal session key is used to protect the message, every server
between the sender client and the receiving client MUST decrypt the
.ti 0
2.3.12 Private Message Key Payload
-This payload is OPTIONAL and can be used to send private message
-key between two clients in the network. The packet is secured with
-normal session keys. By default private messages are encrypted
-with session keys, and with this payload it is possible to set
-private key for private message encryption between two clients.
-
-The receiver of this payload SHOULD verify for example from user
-whether user want to receive private message key. Note that there
-are other, more secure ways of exchanging private message keys in
-the SILC network. Instead of sending this payload it is possible to
-negotiate the private message key with SKE protocol using the Key
-Agreement payload directly peer to peer, see section 2.3.20.
+This payload is OPTIONAL and can be used to indicate that a static
+or pre-shared key should be used in the private message communication
+to protect the messages. The actual key material has to be sent
+outside the SILC network, or it has to be a static or pre-shared key.
+The sender of this packet is considered to be the initiator and the
+received the responder when processing the raw key material as
+described in the section 4.6 in [SILC1] and in the section 2.3 in
+[SILC3].
+
+Note that it is also possible to use static or pre-shared keys in
+client implementations without sending this packet. Clients may
+naturally agree to use a key without sending any kind of indication
+to each other. The key may be for example a long-living static key
+that the clients has agreed to use at all times. Note that it is
+also possible to agree to use private message key by performing
+a Key Agreement. See the section 2.3.20 Key Agreement Payload.
This payload may only be sent by client to another client. Server
-MUST NOT send this payload. After sending this payload the sender of
-private messages must set the Private Message Key flag into SILC Packet
-Header.
+MUST NOT send this payload. After sending this payload and setting the
+key into use this payload the sender of private messages MUST set the
+Private Message Key flag into the SILC Packet Header.
The payload may only be sent with SILC_PACKET_PRIVATE_MESSAGE_KEY
packet. It MUST NOT be sent in any other packet type. The following
diagram represents the Private Message Key Payload.
-
-
.in 5
.nf
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Private Message Key Length | |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
-| |
-~ Private Message Key ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cipher Name Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
.in 6
-o Private Message Key Length (2 bytes) - Indicates the length
- of the Private Message Key field in the payload, not including
- any other field.
-
-o Private Message Key (variable length) - The actual private
- message key material.
-
o Cipher Name Length (2 bytes) - Indicates the length of the
Cipher Name field in the payload, not including any other
field.
diagram represents the Connection Auth Request Payload.
-
-
.in 5
.nf
1 2 3
-
-
-
-
.in 5
.nf
1 2 3
.in 3
+
+
.ti 0
2.3.22 File Transfer Payload
1 Introduction .................................................. 3
1.1 Requirements Terminology .................................. 4
2 SILC Concepts ................................................. 4
- 2.1 SILC Network Topology ..................................... 4
+ 2.1 SILC Network Topology ..................................... 5
2.2 Communication Inside a Cell ............................... 6
2.3 Communication in the Network .............................. 7
2.4 Channel Communication ..................................... 7
3.3.1 Router's Local ID List .............................. 13
3.3.2 Router's Global ID List ............................. 14
3.3.3 Router's Server ID .................................. 14
- 3.4 Channels .................................................. 14
+ 3.4 Channels .................................................. 15
3.4.1 Channel ID .......................................... 16
3.5 Operators ................................................. 16
3.6 SILC Commands ............................................. 17
3.10.3 Hash Functions ..................................... 27
3.10.4 MAC Algorithms ..................................... 27
3.10.5 Compression Algorithms ............................. 28
- 3.11 SILC Public Key .......................................... 29
+ 3.11 SILC Public Key .......................................... 28
3.12 SILC Version Detection ................................... 31
- 3.13 UTF-8 Strings in SILC .................................... XXXX
- 3.13.1 UTF-8 Identifier Strings ........................... XXXX
- 3.14 Backup Routers ........................................... 31
- 3.14.1 Switching to Backup Router ......................... 33
- 3.14.2 Resuming Primary Router ............................ 34
-4 SILC Procedures ............................................... 36
- 4.1 Creating Client Connection ................................ 37
- 4.2 Creating Server Connection ................................ 38
- 4.2.1 Announcing Clients, Channels and Servers ............ 39
- 4.3 Joining to a Channel ...................................... 40
- 4.4 Channel Key Generation .................................... 41
- 4.5 Private Message Sending and Reception ..................... 42
- 4.6 Private Message Key Generation ............................ 42
- 4.7 Channel Message Sending and Reception ..................... 43
- 4.8 Session Key Regeneration .................................. 44
- 4.9 Command Sending and Reception ............................. 44
- 4.10 Closing Connection ....................................... 45
- 4.11 Detaching and Resuming a Session ......................... 46
-5 Security Considerations ....................................... 47
-6 References .................................................... 48
-7 Author's Address .............................................. 50
-Appendix A ...................................................... XXXX
-Appendix B ...................................................... XXXX
-Full Copyright Statement ........................................ XXXX
+ 3.13 UTF-8 Strings in SILC .................................... 31
+ 3.13.1 UTF-8 Identifier Strings ........................... 32
+ 3.14 Backup Routers ........................................... 33
+ 3.14.1 Switching to Backup Router ......................... 35
+ 3.14.2 Resuming Primary Router ............................ 36
+4 SILC Procedures ............................................... 38
+ 4.1 Creating Client Connection ................................ 38
+ 4.2 Creating Server Connection ................................ 40
+ 4.2.1 Announcing Clients, Channels and Servers ............ 40
+ 4.3 Joining to a Channel ...................................... 42
+ 4.4 Channel Key Generation .................................... 43
+ 4.5 Private Message Sending and Reception ..................... 44
+ 4.6 Private Message Key Generation ............................ 44
+ 4.7 Channel Message Sending and Reception ..................... 45
+ 4.8 Session Key Regeneration .................................. 46
+ 4.9 Command Sending and Reception ............................. 46
+ 4.10 Closing Connection ....................................... 47
+ 4.11 Detaching and Resuming a Session ......................... 48
+5 Security Considerations ....................................... 49
+6 References .................................................... 50
+7 Author's Address .............................................. 52
+Appendix A ...................................................... 52
+Appendix B ...................................................... 54
+Full Copyright Statement ........................................ 54
.ti 0
List of Figures
clear.
+
.ti 0
2.1 SILC Network Topology
o Receiving key
o Public key
-
channel list - All channels in server
o Channel name
o Channel ID
.in 3
-
.ti 0
3.2.2 Server ID
as they could have been set up by untrusted party.
-
.ti 0
3.3 Router
section 3.2.2 Server ID.
+
+
.ti 0
3.4 Channels
.in 3
-
.ti 0
3.10.4 MAC Algorithms
section's definitions.
-
-
.ti 0
4.1 Creating Client Connection
SILC_NOTIFY_TYPE_WATCH to the watcher.
+
+
.ti 0
4.2 Creating Server Connection
4.6 Private Message Key Generation
Private message MAY be protected with a key generated by the client.
-The key may be generated and sent to the other client by sending packet
-SILC_PACKET_PRIVATE_MESSAGE_KEY which travels through the network
-and is secured by session keys. After that the private message key
-is used in the private message communication between those clients.
-The key sent inside the payload SHOULD be randomly generated. This
-packet MUST NOT be used to send pre-shared keys.
-
-Another choice is to entirely use keys that are not sent through
-the SILC network at all. This significantly adds security. This key
-could be a pre-shared key that is known by both of the clients. Both
-agree about using the key and start sending packets that indicate
-that the private message is secured using private message key. In
-case of pre-shared keys (static keys) the IV used in encryption SHOULD
-be chosen randomly.
-
-It is also possible to negotiate fresh key material by performing
-Key Agreement. The SILC_PACKET_KEY_AGREEMENT packet MAY be used to
-negotiate the fresh key material. In this case the resulting key
-material is used to secure the private messages. Also, the IV used
-in encryption is used as defined in [SILC3], unless otherwise stated
-by the encryption mode used. By performing Key Agreement the clients
-may negotiate the cipher and HMAC to be used in the private message
-encryption and to negotiate additional security parameters.
+One way to generate private message key is to use static or pre-shared
+keys in the client implementation. Client that wants to indicate other
+client on the network that a private message key should be set, the
+client MAY send SILC_PACKET_PRIVATE_MESSAGE_KEY packet to indicate this.
+The actual key material has to be transferred outside the SILC network,
+or it has to be pre-shared key. The client receiving this packet knows
+that the sender wishes to use private message key in private message
+communication. In case of static or pre-shared keys the IV used in
+the encryption SHOULD be chosen randomly. Sending the
+SILC_PACKET_PRIVATE_MESSAGE_KEY is not mandatory, and clients may
+naturally agree to use a key without sending the packet.
+
+Another choice to use private message keys is to negotiate fresh key
+material by performing the Key Agreement. The SILC_PACKET_KEY_AGREEMENT
+packet MAY be used to negotiate the fresh key material. In this case
+the resulting key material is used to secure the private messages.
+Also, the IV used in encryption is used as defined in [SILC3], unless
+otherwise stated by the encryption mode used. By performing Key
+Agreement the clients can also negotiate the cipher and HMAC to be used
+in the private message encryption and to negotiate additional security
+parameters. The actual Key Agreement [SILC2] is performed by executing
+the SILC Key Exchange protocol [SILC3], peer to peer. Because of NAT
+devices in the network, it might be impossible to perform the Key
+Agreement. In this case using static or pre-shared key and sending the
+SILC_PACKET_PRIVATE_MESSAGE_KEY to indicate the use of a private message
+key is a working alternative.
If the key is pre-shared key or other key material not generated by
Key Agreement, then the key material SHOULD be processed as defined
-in [SILC3]. The hash function to be used SHOULD be SHA1. In the
-processing, however, the HASH, as defined in [SILC3] MUST be ignored.
-After processing the key material it is employed as defined in [SILC3].
-In this case also, implementations SHOULD use the SILC protocol's
-mandatory cipher and HMAC in private message encryption.
+in [SILC3]. In the processing, however, the HASH, as defined in [SILC3]
+MUST be ignored. After processing the key material it is employed as
+defined in [SILC3]. If the SILC_PACKET_PRIVATE_MESSAGE_KEY was sent,
+then it defines the cipher and HMAC to be used. The hash algorithm to be
+used in the key material processing is the one that HMAC algorithm is
+defined to use. If the SILC_PACKET_PRIVATE_MESSAGE_KEY was not sent at
+all, then the hash algorithm to be used SHOULD be SHA1. In this case
+also, implementations SHOULD use the SILC protocol's mandatory cipher
+and HMAC in private message encryption.
.ti 0
the network has the SILC_UMODE_REJECT_WATCHING user mode set.
-
-
.ti 0
4.11 Detaching and Resuming a Session
this profile.
+.ti 0
Appendix B
This appendix defines additional prohibited characters in the identifier
projects / silc.git / commitdiff