.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH 15 May 2002
+.ds RH 26 November 2002
.ds CH
.na
.hy 0
.nf
Network Working Group P. Riikonen
Internet-Draft
-draft-riikonen-silc-pp-05.txt 15 May 2002
-Expires: 15 November 2002
+draft-riikonen-silc-pp-06.txt 26 November 2002
+Expires: 26 April 2003
.in 3
.ce 2
SILC Packet Protocol
-<draft-riikonen-silc-pp-05.txt>
+<draft-riikonen-silc-pp-06.txt>
.ti 0
Status of this Memo
2.1 SILC Packet ............................................... 4
2.2 SILC Packet Header ........................................ 5
2.3 SILC Packet Types ......................................... 8
- 2.3.1 SILC Packet Payloads ................................ 17
- 2.3.2 Generic payloads .................................... 17
- 2.3.2.1 ID Payload .................................. 17
- 2.3.2.2 Argument Payload ............................ 18
- 2.3.2.3 Channel Payload ............................. 19
- 2.3.2.4 Public Key Payload .......................... 20
- 2.3.3 Disconnect Payload .................................. 20
- 2.3.4 Success Payload ..................................... 21
- 2.3.5 Failure Payload ..................................... 22
- 2.3.6 Reject Payload ...................................... 22
- 2.3.7 Notify Payload ...................................... 23
- 2.3.8 Error Payload ....................................... 31
- 2.3.9 Channel Message Payload ............................. 31
- 2.3.10 Channel Key Payload ................................ 35
- 2.3.11 Private Message Payload ............................ 36
- 2.3.12 Private Message Key Payload ........................ 38
- 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 ..................................... 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.23 Resume Client Payload .............................. 48
- 2.4 SILC ID Types ............................................. 49
- 2.5 Packet Encryption And Decryption .......................... 49
- 2.5.1 Normal Packet Encryption And Decryption ............. 50
- 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.8 Packet Compression ........................................ 53
- 2.9 Packet Sending ............................................ 53
- 2.10 Packet Reception ......................................... 54
- 2.11 Packet Routing ........................................... 54
- 2.12 Packet Broadcasting ...................................... 55
-3 Security Considerations ....................................... 56
-4 References .................................................... 56
-5 Author's Address .............................................. 58
+ 2.3.1 SILC Packet Payloads ................................ 15
+ 2.3.2 Generic payloads .................................... 16
+ 2.3.2.1 ID Payload .................................. 16
+ 2.3.2.2 Argument Payload ............................ 16
+ 2.3.2.3 Channel Payload ............................. 17
+ 2.3.2.4 Public Key Payload .......................... 18
+ 2.3.2.5 Message Payload ............................. 19
+ 2.3.3 Disconnect Payload .................................. 22
+ 2.3.4 Success Payload ..................................... 23
+ 2.3.5 Failure Payload ..................................... 23
+ 2.3.6 Reject Payload ...................................... 24
+ 2.3.7 Notify Payload ...................................... 25
+ 2.3.8 Error Payload ....................................... 32
+ 2.3.9 Channel Message Payload ............................. 33
+ 2.3.10 Channel Key Payload ................................ 34
+ 2.3.11 Private Message Payload ............................ 35
+ 2.3.12 Private Message Key Payload ........................ 36
+ 2.3.13 Command Payload .................................... 38
+ 2.3.14 Command Reply Payload .............................. 39
+ 2.3.15 Connection Auth Request Payload .................... 39
+ 2.3.16 New ID Payload ..................................... 40
+ 2.3.17 New Client Payload ................................. 41
+ 2.3.18 New Server Payload ................................. 42
+ 2.3.19 New Channel Payload ................................ 43
+ 2.3.20 Key Agreement Payload .............................. 43
+ 2.3.21 Resume Router Payload .............................. 44
+ 2.3.22 File Transfer Payload .............................. 45
+ 2.3.23 Resume Client Payload .............................. 46
+ 2.4 SILC ID Types ............................................. 47
+ 2.5 Packet Encryption And Decryption .......................... 48
+ 2.5.1 Normal Packet Encryption And Decryption ............. 48
+ 2.5.2 Channel Message Encryption And Decryption ........... 49
+ 2.5.3 Private Message Encryption And Decryption ........... 50
+ 2.6 Packet MAC Generation ..................................... 50
+ 2.7 Packet Padding Generation ................................. 51
+ 2.8 Packet Compression ........................................ 52
+ 2.9 Packet Sending ............................................ 52
+ 2.10 Packet Reception ......................................... 52
+ 2.11 Packet Routing ........................................... 53
+ 2.12 Packet Broadcasting ...................................... 54
+3 Security Considerations ....................................... 55
+4 References .................................................... 55
+5 Author's Address .............................................. 56
.ti 0
List of Figures
Figure 4: Argument Payload
Figure 5: Channel Payload
Figure 6: Public Key Payload
-Figure 7: Disconnect Payload
-Figure 8: Success Payload
-Figure 9: Failure Payload
-Figure 10: Reject Payload
-Figure 11: Notify Payload
-Figure 12: Error Payload
-Figure 13: Channel Message Payload
+Figure 7: Message Payload
+Figure 8: Disconnect Payload
+Figure 9: Success Payload
+Figure 10: Failure Payload
+Figure 11: Reject Payload
+Figure 12: Notify Payload
+Figure 13: Error Payload
Figure 14: Channel Key Payload
-Figure 15: Private Message Payload
-Figure 16: Private Message Key Payload
-Figure 17: Command Payload
-Figure 18: Connection Auth Request Payload
-Figure 19: New Client Payload
-Figure 20: New Server Payload
-Figure 21: Key Agreement Payload
-Figure 22: Resume Router Payload
-Figure 23: File Transfer Payload
-Figure 24: Resume Client Payload
+Figure 15: Private Message Key Payload
+Figure 16: Command Payload
+Figure 17: Connection Auth Request Payload
+Figure 18: New Client Payload
+Figure 19: New Server Payload
+Figure 20: Key Agreement Payload
+Figure 21: Resume Router Payload
+Figure 22: File Transfer Payload
+Figure 23: Resume Client Payload
.ti 0
All packet payloads can also be compressed to further reduce the size
of the packets.
-The basis of SILC protocol relies in the SILC packets and it is with
-out a doubt the most important part of the protocol. It is also probably
-the most complicated part of the protocol. Packets are used all the
-time in the SILC network to send messages, commands and other information.
All packets in SILC network are always encrypted and their integrity
is assured by computed MACs. The protocol defines several packet types
and packet payloads. Each packet type usually has a specific packet
protocol. The data payload area is always encrypted.
The last part of SILC packet is the packet MAC that assures the
-integrity of the packet. The MAC is always computed from the packet
-before the encryption is applied to the packet. If compression is used
-in the packet the MAC is computed after the compression has been
-applied. The compression, on the other hand, is always applied before
-encryption. See more details in the section 2.6 Packet MAC Generation.
+integrity of the packet. See the section 2.6 Packet MAC Generation
+for more information. If compression is used the compression is
+always applied before encryption.
All fields in all packet payloads are always in MSB (most significant
byte first) order.
packet broadcasting.
+
Compressed 0x08
Marks that the payload of the packet is compressed.
.in 3
-
-
-
o Packet Type (1 byte) - Is the type of the packet. Receiver
uses this field to parse the packet. See section 2.3
SILC Packets for list of defined packet types.
+
+
+
.ti 0
2.3 SILC Packet Types
types.
The below list of the SILC Packet types includes reference to the packet
-payload as well. Packet payloads are the actual packet, that is, the data
-that the packet consists of. Each packet type defines packet payload
-which usually may only be sent with the specific packet type.
+payload as well. Packet payloads are the actual packet data area. Each
+packet type defines packet payload which usually may only be sent with
+the specific packet type.
Most of the packets are packets that must be destined directly to entity
-that is connected to the sender. It is not allowed, for example, for
+that is connected to the sender. It is not allowed, for example, for a
router to send disconnect packet to client that is not directly connected
to the router. However, there are some special packet types that may
-be destined to some entity that the sender has not direct connection
-with. These packets are for example private message packets, channel
-message packets, command packets and some other packets that may be
-broadcasted in the SILC network. If the packet is allowed to be sent to
-indirectly connected entity it is mentioned separately in the packet
-description (unless it is obvious as in private and channel message
-packets). Other packets MUST NOT be sent or accepted, if sent, to
-indirectly connected entities.
+be destined to some entity that the sender does not have direct
+connection with. These packets are for example private message packets,
+channel message packets, command packets and some other packets that may
+be broadcasted in the SILC network. If the packet is allowed to be sent
+to indirectly connected entity it is defined separately in the packet
+description below. Other packets MUST NOT be sent or accepted, if sent,
+to indirectly connected entities.
+
+Some packets MAY be sent as lists by adding the List flag to the Packet
+Header and constructing multiple packet payloads one after the other.
+When this is allowed it is separately defined below. Other packets
+MUST NOT be sent as list and the List flag MUST NOT be set.
+
List of SILC Packet types are defined as follows.
the disconnection is sent inside the packet payload. Client
usually does not send this packet.
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
-
Payload of the packet: See section 2.3.3 Disconnect Payload
This packet is sent upon successful execution of some protocol.
The status of the success is sent in the packet.
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
-
Payload of the packet: See section 2.3.4 Success Payload
This packet is sent upon failure of some protocol. The status
of the failure is sent in the packet.
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
-
Payload of the packet: See section 2.3.5 Failure Payload
This packet MAY be sent upon rejection of some protocol.
The status of the rejection is sent in the packet.
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
-
Payload of the packet: See section 2.3.6 Reject Payload
5 SILC_PACKET_NOTIFY
- This packet is used to send notify message, usually from
- server to client, although it MAY be sent from server to another
- server as well. Client MUST NOT send this packet. Server MAY
- send this packet to channel as well when the packet is
- distributed to all clients on the channel.
+ This packet is used to send notify message. The packet is
+ usually sent between server and client, but also between
+ server and router. Client MUST NOT send this packet. Server
+ MAY send this packet to channel as well when the packet is
+ distributed to all clients on the channel. This packet MAY
+ be sent as list.
Payload of the packet: See section 2.3.7 Notify Payload.
most likely to take action anyway. This packet MAY be sent
to entity that is indirectly connected to the sender.
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
-
Payload of the packet: See section 2.3.8 Error Payload.
includes Channel ID of the channel and the actual message to
the channel. Messages sent to the channel are always protected
by channel specific keys. Channel Keys are distributed by
- SILC_PACKET_CHANNEL_KEY packet.
-
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
+ SILC_PACKET_CHANNEL_KEY packet. This packet MAY be sent to
+ entity that is indirectly connected to the sender.
Payload of the packet: See section 2.3.9 Channel Message
Payload
may send this packet. This packet MAY be sent to entity
that is indirectly connected to the sender.
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
-
Payload of the packet: See section 2.3.10 Channel Key Payload
to another client. By default, private messages are protected
by session keys established by normal key exchange protocol.
However, it is possible to use specific key to protect private
- messages. SILC_PACKET_PRIVATE_MESSAGE_KEY packet is used to
- agree the key with the remote client. Pre-shared key MAY be
- used as well if both of the client knows it, however, it needs
- to be agreed outside SILC. See more of this in [SILC1].
-
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
+ messages. See [SILC1] for private message key generation.
+ This packet MAY be sent to entity that is indirectly connected
+ to the sender.
Payload of the packet: See section 2.3.11 Private Message
Payload
10 SILC_PACKET_PRIVATE_MESSAGE_KEY
- This packet is used to agree about a key to be used to protect
- the private messages between two clients. If this is not sent
- the normal session key is used to protect the private messages
- inside SILC network. Agreeing to use specific key to protect
- private messages adds security, as no server between the two
- clients will be able to decrypt the private message. However,
- servers inside SILC network are considered to be trusted, thus
- using normal session key to protect private messages does not
- degrade security. Whether to agree to use specific keys by
- default or to use normal session keys by default, is
- implementation specific issue. See more of this in [SILC1].
-
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
+ 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.
Payload of the packet: See section 2.3.12 Private Message
Key Payload
This packet MAY be sent to entity that is indirectly connected
to the sender.
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
-
Payload of the packet: See section 2.3.13 Command Payload
MAY be sent to entity that is indirectly connected to the
sender.
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
-
Payload of the packet: See section 2.3.14 Command Reply
Payload and section 2.3.13 Command
Payload
This packet is used to start SILC Key Exchange Protocol,
described in detail in [SILC3].
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
-
Payload of the packet: Payload of this packet is described
in the section SILC Key Exchange
Protocol and its sub sections in
This packet is used as part of the SILC Key Exchange Protocol.
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
-
Payload of the packet: Payload of this packet is described
in the section SILC Key Exchange
Protocol and its sub sections in
This packet is used as part of the SILC Key Exchange Protocol.
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
-
Payload of the packet: Payload of this packet is described
in the section SILC Key Exchange
Protocol and its sub sections in
16 SILC_PACKET_CONNECTION_AUTH_REQUEST
- This packet is used to request the authentication method to
+ This packet is used to request an authentication method to
be used in the SILC Connection Authentication Protocol. If
initiator of the protocol does not know the mandatory
authentication method this packet MAY be used to determine it.
-
- The party receiving this payload MUST respond with the same
+ The party receiving this payload SHOULD respond with the same
packet including the mandatory authentication method.
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
-
Payload of the packet: See section 2.3.15 Connection Auth
Request Payload
the connecting party. The protocol is described in detail in
[SILC3].
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
-
Payload of the packet: Payload of this packet is described
in the section SILC Authentication
Protocol and it sub sections in [SILC].
18 SILC_PACKET_NEW_ID
- This packet is used to distribute new ID's from server to
- router and from router to all routers in the SILC network.
+ This packet is used to distribute new IDs from server to
+ router and from router to all other routers in SILC network.
This is used when for example new client is registered to
- SILC network. The newly created ID's of these operations are
+ SILC network. The newly created IDs of these operations are
distributed by this packet. Only server may send this packet,
however, client MUST be able to receive this packet. This
packet MAY be sent to entity that is indirectly connected
- to the sender.
+ to the sender. This packet MAY be sent as list.
Payload of the packet: See section 2.3.16 New ID Payload
authentication protocols has been completed. Client sends
various information about itself in this packet.
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
-
Payload of the packet: See section 2.3.17 New Client Payload
Server ID and other information in this packet. The client
MUST NOT send or receive this packet.
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
-
Payload of the packet: See section 2.3.18 New Server Payload
notify other routers about the created channel. Router sends
this packet to its primary route. Client MUST NOT send this
packet. This packet MAY be sent to entity that is indirectly
- connected to the sender.
+ connected to the sender. This packet MAY be sent as list.
Payload of the packet: See section 2.3.19 New Channel Payload
[SILC1] for more information. This packet does not have
a payload.
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
-
23 SILC_PACKET_REKEY_DONE
This packet is used to indicate that re-key is performed and
- new keys must be used hereafter.
-
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
+ new keys must be used hereafter. This packet does not have a
+ payload.
24 SILC_PACKET_HEARTBEAT
This packet is used by clients, servers and routers to keep the
- connection alive. It is recommended that all servers implement
+ connection alive. It is RECOMMENDED that all servers implement
keepalive actions and perform it to both direction in a link.
This packet does not have a payload.
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
-
25 SILC_PACKET_KEY_AGREEMENT
example as private message key. The server and router MUST NOT
send this packet.
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
-
Payload of the packet: See section 2.3.20 Key Agreement Payload
-
-
26 SILC_PACKET_RESUME_ROUTER
This packet is used during backup router protocol when the
network that the sender wishes to perform an file transfer
protocol. The packet is also used to actually tunnel the
file transfer protocol stream. The file transfer protocol
- stream is always protected with the SILC packet.
-
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
+ stream is always protected with the SILC binary packet protocol.
Payload of the packet: See section 2.3.22 File Transfer Payload
this packet to a server. Routers also use this packet to notify
other routers in the network that the detached client has resumed.
- This packet MUST NOT be sent as list and the List flag MUST
- NOT be set.
-
Payload of the packet: See section 2.3.23 Resume Client Payload
be sent with specific packet type which is defined in the description
of the payload.
-There are a lot of other payloads in the SILC as well. However, they
-are not common in the sense that they could be sent at any time.
-These payloads are not described in this section. These are payloads
-such as SILC Key Exchange payloads and so on. These are described
-in [SILC1], [SILC3] and [SILC4].
+There are many other payloads in SILC as well. However, they are not
+common in the sense that they could be sent at any time. These payloads
+are not described in this section. These are payloads such as SILC
+Key Exchange payloads and so on. These are described in [SILC1],
+[SILC3] and [SILC4].
.ti 0
This section describes generic payloads that are not associated to any
specific packet type. They can be used for example inside some other
-packet payloads.
+packet payload.
.ti 0
2.3.2.1 ID Payload
This payload can be used to send an ID. ID's are variable in length
-thus this payload provides a way to send variable length ID's.
+thus this payload provides a way to send variable length ID.
The following diagram represents the ID Payload.
-
-
-
-
-
.in 5
.nf
1 2 3
o ID Length (2 bytes) - Length of the ID Data area not
including the length of any other fields in the payload.
-o ID Data (variable length) - The actual ID data.
+o ID Data (variable length) - The actual ID data. The encoding
+ of the ID data is defined in section 2.4 SILC ID Types.
.in 3
2.3.2.2 Argument Payload
Argument Payload is used to set arguments for any packet payload that
-needs and supports arguments, such as commands. Number of arguments
+need and support arguments, such as commands. Number of arguments
associated with a packet MUST be indicated by the packet payload which
-needs the arguments. Argument Payloads MUST always reside right after
+need the arguments. Argument Payloads MUST always reside right after
the packet payload needing the arguments. Incorrect amount of argument
payloads MUST cause rejection of the packet.
.in 6
-o Payload Length (2 bytes) - Length of the argument payload data
- area not including the length of any other fields in the
+o Payload Length (2 bytes) - Length of the Argument Data
+ field not including the length of any other field in the
payload.
o Argument Type (1 byte) - Indicates the type of the argument.
- Every argument may have a specific type that MUST be defined
+ Every argument can have a specific type that MUST be defined
by the packet payload needing the argument. For example
- every command specify a number for each argument that maybe
+ every command specify a number for each argument that may be
associated with the command. By using this number the receiver
of the packet knows what type of argument this is. If there is
- no specific argument type this field is set to zero (0).
+ no specific argument type this field is set to zero (0) value.
o Argument Data (variable length) - Argument data.
.in 3
.ti 0
2.3.2.3 Channel Payload
-Generic Channel Payload may be used to send information about channel,
+Generic Channel Payload may be used to send information about a channel,
its name, the Channel ID and a mode.
The following diagram represents the Channel Payload.
+
.in 5
.nf
1 2 3
o Channel ID (variable length) - The Channel ID.
o Mode Mask (4 bytes) - A mode. This can be the mode of the
- channel but it can also be the mode of the client on the
+ channel but it can also be the mode of a client on the
channel. The contents of this field is dependent of the
usage of this payload. The usage is defined separately
when this payload is used. This is a 32 bit MSB first value.
.ti 0
2.3.2.4 Public Key Payload
-Generic Public Key Payload may be used to send different types of
+Generic Public Key Payload may be used to send different type of
public keys and certificates.
The following diagram represents the Public Key Payload.
-
-
-
-
.in 5
.nf
1 2 3
| Public Key Length | Public Key Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
-~ Public Key of the party (or certificate) ~
+~ Public Key (or certificate) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.in 3
the packet. See the [SILC3] for defined public key types.
o Public Key (or certificate) (variable length) - The
- public key or certificate.
+ public key or certificate data.
+.in 3
+
+
+.ti 0
+2.3.2.5 Message Payload
+
+Generic Message Payload can be used to send messages in SILC. It
+is used to send channel messages and private messages.
+
+The following diagram represents the Message Payload.
+
+(*) indicates that the field is not encrypted.
+
+.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
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Message Flags | Message Length |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Message Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Padding Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Padding ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Initial Vector * ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ MAC * ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 7: Message Payload
+
+
+.in 6
+o Message Flags (2 bytes) - Includes the Message Flags of the
+ message. The flags can indicate a reason or a purpose for
+ the message. The following Message Flags are defined:
+
+ 0x0000 SILC_MESSAGE_FLAG_NONE
+
+ No specific flags set.
+
+ 0x0001 SILC_MESSAGE_FLAG_AUTOREPLY
+
+ This message is an automatic reply to an earlier
+ received message.
+
+ 0x0002 SILC_MESSAGE_FLAG_NOREPLY
+
+ There should not be reply messages to this
+ message.
+
+ 0x0004 SILC_MESSAGE_FLAG_ACTION
+
+ The sender is performing an action and the message
+ is the indication of the action.
+
+ 0x0008 SILC_MESSAGE_FLAG_NOTICE
+
+ The message is for example an informational notice
+ type message.
+
+ 0x0010 SILC_MESSAGE_FLAG_REQUEST
+
+ This is a generic request flag to send request
+ messages. A separate document should define any
+ payloads associated to this flag.
+
+ 0x0020 SILC_MESSAGE_FLAG_SIGNED
+
+ This flag indicates that the message is signed
+ with sender's private key and thus can be verified
+ by the receiver using the sender's public key. A
+ separate document should define the detailed procedure
+ of the signing process and any associated payloads
+ for this flag.
+
+ 0x0040 SILC_MESSAGE_FLAG_REPLY
+
+ This is a generic reply flag to send a reply to
+ previously received request. A separate document
+ should define any payloads associated to this flag.
+
+ 0x0080 SILC_MESSAGE_FLAG_DATA
+
+ This is a generic data flag, indicating that the
+ message includes some data which can be interpreted
+ in a specific way. Using this flag any kind of data
+ can be delivered inside message payload. A separate
+ document should define how this flag is interpreted
+ and define any associated payloads.
+
+ 0x0100 SILC_MESSAGE_FLAG_UTF8
+
+ This flag indicates that the message is UTF-8 encoded
+ textual message. When sending text messages in SILC
+ this flag SHOULD be used. When this flag is used the
+ text sent as message MUST be UTF-8 encoded.
+
+ 0x0200 - 0x0800 RESERVED
+
+ Reserved for future flags.
+
+ 0x1000 - 0x8000 PRIVATE RANGE
+
+ Private range for free use.
+
+o Message Length (2 bytes) - Indicates the length of the
+ Message Data field in the payload, not including any
+ other field.
+
+o Message Data (variable length) - The actual message data.
+
+o Padding Length (2 bytes) - Indicates the length of the
+ Padding field in the payload, not including any other
+ field.
+
+o Padding (variable length) - If this payload is used as
+ channel messages, the padding MUST be applied because
+ this payload is encrypted separately from other parts
+ of the packet. If this payload is used as private
+ messages, the padding is present only when the payload
+ is encrypted with private message key. If encrypted
+ with session keys this field MUST NOT be present and the
+ 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.
+ The IV SHOULD be random data for each channel message.
+
+ When encrypting private messages with session keys this
+ field MUST NOT be present. For private messages this
+ field is present only when encrypting with a static
+ private message key (pre-shared key). If randomly
+ generated key material is used this field MUST NOT be
+ present. Also, If Key Agreement (SKE) was used to
+ negotiate fresh key material for private message key
+ this field MUST NOT be present. See the section 4.6
+ in [SILC1] for more information about IVs when
+ encrypting private messages.
+
+ This field includes the initial 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,
+ is not included in padding calculation and its length
+ equals to cipher's block size. This field is authenticated
+ by the message MAC.
+
+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
+ 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 encrypted.
.in 3
.ti 0
2.3.3 Disconnect Payload
-Disconnect payload is sent upon disconnection. The payload is simple;
-reason of disconnection is sent to the disconnected party.
+Disconnect payload is sent upon disconnection. Reason of the
+disconnection is sent to the disconnected party in the payload.
The payload may only be sent with SILC_PACKET_DISCONNECT packet. It
MUST NOT be sent in any other packet type. The following diagram
.in 3
.ce
-Figure 7: Disconnect Payload
+Figure 8: Disconnect Payload
.in 6
o Status (1 byte) - Indicates the Status Type, defined in [SILC3]
o Disconnect Message (variable length) - Human readable UTF-8
encoded string indicating reason of the disconnection. This
- MAY be omitted.
+ field MAY be omitted.
.in 3
Success payload is sent when some protocol execution is successfully
completed. The payload is simple; indication of the success is sent.
-This may be any data, including binary or human readable data.
+This may be any data, including binary or human readable data, and
+it is protocol dependent.
.in 5
.nf
.in 3
.ce
-Figure 8: Success Payload
+Figure 9: Success Payload
.in 6
some protocol is sent in the payload.
+
+
+
+
+
.in 5
.nf
1 2 3
.in 3
.ce
-Figure 9: Failure Payload
+Figure 10: Failure Payload
.in 6
This payload is sent when some protocol is rejected to be executed.
Other operations MAY send this as well that was rejected. The
indication of the rejection is sent in the payload. The indication
-may be binary or human readable data.
+may be binary or human readable data and is protocol dependent.
.in 5
.in 3
.ce
-Figure 10: Reject Payload
+Figure 11: Reject Payload
.in 6
.in 3
+
+
.ti 0
2.3.7 Notify Payload
Notify payload is used to send notify messages. The payload is usually
-sent from server to client, however, server MAY send it to another
-server as well. This payload MAY also be sent to a channel. Client
-MUST NOT send this payload. The receiver of this payload MAY ignore
-the contents of the payload, however, notify message SHOULD be audited.
+sent from server to client and from server to router. It is also used
+by routers to notify other routers in the network. This payload MAY also
+be sent to a channel. Client MUST NOT send this payload. If client
+receives this payload it MAY ignore the contents of the payload, however,
+notify message SHOULD be audited. Servers and routers MUST process
+notify packets.
The payload may only be sent with SILC_PACKET_NOTIFY packet. It MUST
not be sent in any other packet type. The following diagram represents
-
.in 5
.nf
1 2 3
.in 3
.ce
-Figure 11: Notify Payload
+Figure 12: Notify Payload
.in 6
o Payload Length (2 bytes) - Length of the entire Notify Payload
including any associated Argument Payloads.
-o Argument Nums (2 bytes) - Indicates the number of Argument
+o Argument Nums (1 byte) - Indicates the number of Argument
Payloads associated to this payload. Notify types may define
arguments to be send along the notify message.
.in 3
The following list of currently defined notify types. The format for
notify arguments is same as in SILC commands described in [SILC4].
-Note that all ID's sent in arguments are sent inside ID Payload. Also
+Note that all IDs sent in arguments are sent inside ID Payload. Also
note that all passphrases that may be sent inside arguments MUST be
-UTF-8 [RFC2279] encoded.
-
+UTF-8 [RFC2279] encoded. Also note that all public keys or certificates
+sent inside arguments are actually Public Key Payloads.
.in 6
Max Arguments: 1
Arguments: (1) <message>
- The <message> is implementation specific free text string.
+ The <message> is implementation specific free UTF-8 text string.
Receiver MAY ignore this message.
Max Arguments: 5
Arguments: (1) <Channel ID> (2) <channel name>
- (3) [<sender Client ID>] (4) [<adding client>]
- (5) [<removing client>]
+ (3) [<sender Client ID>] (4) [<add | del>]
+ (5) [<invite list>]
The <Channel ID> is the channel. The <channel name> is the name
of the channel and is provided because the client which receives
this notify packet may not have a way to resolve the name of the
channel from the <Channel ID>. The <sender Client ID> is the
- Client ID which invited the client to the channel. The <adding
- client> and the <removing client> indicates the added or removed
- client from the channel's invite list. The format of the <adding
- client> and the <removing client> is defined in the [SILC4] with
- SILC_COMMAND_INVITE command.
-
- The <adding client> and <removing client> MUST NOT be sent when
- the packet is destined to a client.
+ Client ID which invited the client to the channel. The <add | del>
+ is an argument of size of 1 byte where 0x00 means adding a client
+ to invite list, and 0x01 means deleting a client from invite list.
+ The <invite list>, if present, indicates the information to be
+ added to or removed from the invite list. The <invite list>
+ format is defined in [SILC4] with SILC_COMMAND_INVITE command.
+ When this notify is destined to a client the <add | del> and
+ <invite list> MUST NOT be sent.
2 SILC_NOTIFY_TYPE_JOIN
Sent when client has joined to a channel. The server MUST
- distribute this type only to the local clients on the channel
- and then send it to its primary router. The router or server
- receiving the packet distributes this type to the local clients
- on the channel and broadcast it to the network.
+ distribute this type to the local clients on the channel and then
+ send it to its primary router. The router or server receiving the
+ packet distributes this type to the local clients on the channel
+ and broadcast it to the network.
Max Arguments: 2
Arguments: (1) [<Client ID>] (2) <Channel ID>
3 SILC_NOTIFY_TYPE_LEAVE
Sent when client has left a channel. The server must distribute
- this type only to the local clients on the channel and then send
- it to its primary router. The router or server receiving the
+ this type to the local clients on the channel and then send it
+ to its primary router. The router or server receiving the
packet distributes this type to the local clients on the channel
and broadcast it to the network.
4 SILC_NOTIFY_TYPE_SIGNOFF
Sent when client signoff from SILC network. The server MUST
- distribute this type only to the local clients on the channel and
- then send it to its primary router. The router or server receiving
+ distribute this type to the local clients on the channel and then
+ send it to its primary router. The router or server receiving
the packet distributes this type to the local clients on the
channel and broadcast it to the network.
5 SILC_NOTIFY_TYPE_TOPIC_SET
Sent when topic is set/changed on a channel. This type must be
- sent only to the clients which is joined on the channel which
+ sent only to the clients which are joined on the channel which
topic was set or changed.
Max Arguments: 2
usually is Client ID but it can be Server ID and Channel ID as well.
-
-
6 SILC_NOTIFY_TYPE_NICK_CHANGE
Sent when client changes nick on a channel. The server MUST
the nickname. The <New Client ID> is the new ID generated by
the change of the nickname. The <nickname> is the new nickname.
Note that it is possible to send this notify even if the nickname
- has not changed, but client ID has changed.
+ has not changed, but client ID was changed.
7 SILC_NOTIFY_TYPE_CMODE_CHANGE
Sent when channel mode has changed. This type MUST be sent only
- to the clients which is joined on the channel which mode was
+ to the clients which are joined on the channel which mode was
changed.
Max Arguments: 6
server in the network.
-
-
8 SILC_NOTIFY_TYPE_CUMODE_CHANGE
Sent when user mode on channel has changed. This type MUST be
- sent only to the clients which is joined on the channel where
+ sent only to the clients which are joined on the channel where
the target client is on.
Max Arguments: 4
Arguments: (1) <ID Payload> (2) <mode mask>
- (3) <Target Client ID> (3) [<founder pubkey>]
+ (3) <Target Client ID> (4) [<founder pubkey>]
The <ID Payload> is the ID (usually Client ID but it can be
Server ID as well when the router is enforcing user's mode
Max Arguments: 1
Arguments: (1) <motd>
- The <motd> is the Message of the Day.
+ The <motd> is the Message of the Day. This notify MAY be
+ ignored.
10 SILC_NOTIFY_TYPE_CHANNEL_CHANGE
Arguments: (1) <Server ID> (n) [<Client ID>] [...]
The <Server ID> is the server's ID. The rest of the arguments
- are the Client ID's of the client's which are coming from this
+ are the Client IDs of the clients which are coming from this
server and are thus quitting the SILC network also. If the
maximum number of arguments are reached another
SILC_NOTIFY_TYPE_SERVER_SIGNOFF notify packet MUST be sent.
Sent when a client has been kicked from a channel. This is
sent also to the client which was kicked from the channel.
The client which was kicked from the channel MUST be removed
- from the channel. This notify type is always destined to the
- channel. The router or server receiving the packet distributes
- this type to the local clients on the channel and broadcast it
- to the network.
+ from the channel. The client MUST also be removed from channel's
+ invite list if it is explicitly added in the list. This notify
+ type is always destined to the channel. The router or server
+ receiving the packet distributes this type to the local clients
+ on the channel and broadcast it to the network.
Max Arguments: 3
Arguments: (1) <Client ID> (2) [<comment>]
This notify type is destined directly to the client which was
killed and to channel if the client is on any channel. The router
or server receiving the packet distributes this type to the local
- clients on the channel and broadcast it to the network.
+ clients on the channel and broadcast it to the network. The client
+ MUST also be removed from joined channels invite list if it is
+ explicitly added in the lists.
Max Arguments: 3
Arguments: (1) <Client ID> (2) [<comment>]
sent only between routers as broadcast packet.
Max Arguments: 3
- Arguments: (1) <Channel ID> (2) [<adding client>]
- (3) [<removing client>]
+ Arguments: (1) <Channel ID> (2) [<add | del>]
+ (3) [<ban list>]
- The <Channel ID> is the channel which ban list was changed. The
- <adding client> is used to indicate that a ban was added and the
- <removing client> is used to indicate that a ban was removed from
- the ban list. The format of the <adding client> and the
- <removing client> is defined in the [SILC4] with SILC_COMMAND_BAN
- command.
+ The <Channel ID> is the channel which ban list was changed.
+ The <add | del> is an argument of size of 1 byte where 0x00 means
+ adding a client to ban list, and 0x01 means deleting a client
+ from ban list. The <ban list> indicates the information to be
+ added to or removed from the ban list. The <ban list> format
+ format is defined in [SILC4] with SILC_COMMAND_BAN command.
16 SILC_NOTIFY_TYPE_ERROR
Sent when an error occurs during processing some SILC procedure.
This is not used when error occurs during command processing, see
- [SILC3] for more information about commands and command replies.
+ [SILC4] for more information about commands and command replies.
This type is sent directly to the sender of the packet whose packet
caused the error. See [SILC1] for definition when this type
can be sent.
Max Arguments: 256
Arguments: (1) <Status Type> (n) [...]
- The <Status Type> is the error type defined in [SILC3]. Note that
+ The <Status Type> is the error type defined in [SILC4]. Note that
same types are also used with command replies to indicate the
status of a command. Both commands and this notify type share
same status types. Rest of the arguments are status type
dependent and are specified with those status types that can be
- sent currently inside this notify type in [SILC3]. The <Status
- Type> is of size of 1 byte.
+ sent currently inside this notify type in [SILC4]. The <Status
+ Type> is size of 1 byte.
17 SILC_NOTIFY_TYPE_WATCH
watched is same the notify SHOULD NOT be sent.
-
-
.ti 0
2.3.8 Error Payload
-Error payload is sent upon error. Error may occur in various
-conditions when server sends this packet. Client MUST NOT send this
-payload but MUST be able to accept it. However, client MAY
-totally ignore the contents of the packet as server is going to
+Error payload is sent upon error in protocol. Error may occur in
+various conditions when server sends this packet. Client MUST NOT
+send this payload but MUST be able to accept it. However, client
+MAY totally ignore the contents of the packet as server is going to
take action on the error anyway. However, it is recommended
that the client takes error packet seriously.
.in 3
.ce
-Figure 12: Error Payload
+Figure 13: Error Payload
.in 6
o Error Message (variable length) - Human readable error
- message.
+ message as UTF-8 string.
.in 3
.ti 0
2.3.9 Channel Message Payload
-Channel messages are the most common messages sent in the SILC.
-Channel Message Payload is used to send message to channels. These
-messages can only be sent if client has joined to some channel.
-Even though this packet is the most common in SILC it is still
-special packet. Some special handling on sending and reception
-of channel message is required.
+Channel Message Payload is used to send message to channels, a group
+of users. These messages can only be sent if client has joined to
+some channel. Even though this packet is very common in SILC it
+is still special packet. Some special handling on sending and
+reception of channel message is required.
Padding MUST be applied into this payload since the payload is
encrypted separately from other parts of the packet with the
channel specific key. Hence the requirement of the padding.
-The padding SHOULD be random data. The packet MUST be made
-multiple by eight (8) or by the block size of the cipher, which
-ever is larger.
+The packet MUST be made multiple by eight (8) or by the block
+size of the cipher, which ever is larger.
The SILC header in this packet is encrypted with the session key
of the next receiver of the packet. Nothing else is encrypted
the source ID from the header which tells the client which sent
the message.
-The payload may only be sent with SILC_PACKET_CHANNEL_MESSAGE packet.
-It MUST NOT be sent in any other packet type. The following diagram
-represents the Channel Message Payload.
-
-(*) indicates that the field is not encrypted.
-
-
-.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
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Message Flags | Message Length |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| |
-~ Message Data ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Padding Length | |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
-| |
-~ Padding ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| |
-~ MAC ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| |
-~ Initial Vector * ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-.in 3
-
-.ce
-Figure 13: Channel Message Payload
-
-
-.in 6
-o Message Flags (2 bytes) - Includes the Message Flags of
- the channel messages. The flags can indicate a reason or
- purpose for the channel message. Note that the Private
- Message Payload use these same Message Flags for the same
- purpose. The following Message Flags are defined:
-
- 0x0000 SILC_MESSAGE_FLAG_NONE
-
- No specific flags set.
-
- 0x0001 SILC_MESSAGE_FLAG_AUTOREPLY
-
- This message is an automatic reply to an earlier
- received message.
-
- 0x0002 SILC_MESSAGE_FLAG_NOREPLY
-
- There should not be reply messages to this
- message.
-
- 0x0004 SILC_MESSAGE_FLAG_ACTION
-
- The sender is performing an action and the message
- is the indication of the action.
-
- 0x0008 SILC_MESSAGE_FLAG_NOTICE
-
- The message is for example an informational notice
- type message.
-
- 0x0010 SILC_MESSAGE_FLAG_REQUEST
-
- This is a generic request flag to send request
- messages. A separate document should define any
- payloads associated to this flag.
-
- 0x0020 SILC_MESSAGE_FLAG_SIGNED
-
- This flag indicates that the message is signed
- with sender's private key and thus can be verified
- by the receiver using the sender's public key. A
- separate document should define the detailed procedure
- of the signing process and any associated payloads
- of this flag.
-
- 0x0040 SILC_MESSAGE_FLAG_REPLY
-
- This is a generic reply flag to send a reply to
- previously received request. A separate document
- should define any payloads associated to this flag.
-
- 0x0080 SILC_MESSAGE_FLAG_DATA
-
- This is a generic data flag, indicating that the
- message includes some data which can be interpreted
- in a specific way. Using this flag any kind of data
- can be delivered inside message payload. A separate
- document should define how this flag is interpreted
- and define any associated payloads.
-
- 0x0100 SILC_MESSAGE_FLAG_UTF8
-
- This flag indicates that the message is UTF-8 encoded
- textual message. When sending text messages this
- flag SHOULD be used. When this flag is used the text
- sent as message MUST be UTF-8 encoded.
-
- 0x0200 - 0x0800 RESERVED
-
- Reserved for future flags
-
- 0x1000 - 0x8000 PRIVATE RANGE
-
- Private range for free use.
-
-o Message Length (2 bytes) - Indicates the length of the
- Message Data field in the payload, not including any
- other field.
-
-o Message Data (variable length) - The actual message to
- the channel.
-
-o Padding Length (2 bytes) - Indicates the length of the
- Padding field in the payload, not including any other
- field.
-
-o Padding (variable length) - The padding that MUST be
- applied because this payload is encrypted separately from
- other parts of the packet.
-
-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. This
- protects the integrity of the plaintext channel message.
- The receiver can verify from the MAC whether the message
- decrypted correctly. Also, if more than one private key
- has been set for the channel, the receiver can verify which
- of the keys decrypted the message correctly. Note that,
- this field is encrypted and MUST be added to the padding
- calculation.
-
-o Initial Vector (variable length) - The initial vector
- that has been used in packet encryption. It needs to be
- used in the packet decryption as well. What this field
- includes is implementation issue. However, it is
- RECOMMENDED that it would be random data, or perhaps
- a timestamp. It is NOT RECOMMENDED to use zero (0) as an
- initial vector. This field is not encrypted. This field
- is not included into the padding calculation. Length
- of this field equals the cipher's block size. This field
- is, however authenticated.
-.in 3
+This packet use generic Message Payload as Channel Message Payload.
+See section 2.3.2.5 for generic Message Payload.
.ti 0
are not encrypted using channel keys, they are encrypted using
normal session keys between two routers. Inside a cell, all
channel traffic is encrypted with the specified channel key.
-Channel key should expire periodically, say, in one hour, in
+Channel key SHOULD expire periodically, say, in one hour, in
which case new channel key is created and distributed.
The payload may only be sent with SILC_PACKET_CHANNEL_KEY packet.
2.3.11 Private Message Payload
Private Message Payload is used to send private message between
-two clients (or users for that matter). The messages are sent only
-to the specified user and no other user inside SILC network is
-able to see the message. The message is protected by the session
-key established by the SILC Key Exchange Protocol. However,
-it is also possible to agree to use a private key to protect
-just the private messages. See section 2.3.11 Private Message
-Key Payload for detailed description of how to agree to use
-specific key.
+two clients. The messages are sent only to the specified user
+and no other user inside SILC network is able to see the message.
+
+The message can be protected by the session key established by the
+SILC Key Exchange Protocol. However, it is also possible to agree
+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.
If normal session key is used to protect the message, every server
between the sender client and the receiving client MUST decrypt the
packet. Section Client To Client in [SILC1] gives example of this
scheme as well.
-The payload may only be sent with SILC_PACKET_PRIVATE_MESSAGE
-packet. It MUST NOT be sent in any other packet type. The following
-diagram represents the Private Message 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
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Message Flags | Message Data Length |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| |
-~ Message Data ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| |
-~ Padding ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-.in 3
-
-.ce
-Figure 15: Private Message Payload
-
-
-.in 6
-o Message Flags (2 bytes) - This field includes the Message
- Flags of the private message. They can indicate a different
- reason or purpose for the private message. See the section
- 2.3.9 Channel Message Payload for defined flags. Note that
- the Channel Message Payload use the same flags for the
- same purpose.
-
-o Message Data Length (2 bytes) - Indicates the length of the
- Message Data field, not includes any other field.
-
-o Message Data (variable length) - The actual message to
- the client. Rest of the packet is reserved for the message
- data.
-
-o Padding (variable length) - This field is present only
- when the private message payload is encrypted with private
- message key. In this case the padding is applied to make
- the payload multiple by eight (8), or by the block size of
- the cipher, which ever is larger. When encrypted with
- normal session keys, this field MUST NOT be included.
-.in 3
+This packet use generic Message Payload as Private Message Payload.
+See section 2.3.2.5 for generic Message Payload.
.ti 0
2.3.12 Private Message Key Payload
-This payload is optional and can be used to send private message
+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 wants to receive private message key. Note that there
+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.
+Agreement payload directly peer to peer, see section 2.3.20.
This payload may only be sent by client to another client. Server
MUST NOT send this payload at any time. After sending this payload
diagram represents the Private Message Key Payload.
+
+
+
+
.in 5
.nf
1 2 3
~ Cipher Name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| HMAC Name Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ HMAC Name ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.in 3
.ce
-Figure 16: Private Message Key Payload
-
+Figure 15: Private Message Key Payload
in the private message encryption. If this field does not
exist then the default cipher of the SILC protocol is used.
See the [SILC1] for defined ciphers.
-.in 3
+o HMAC Name Length (2 bytes) - Indicates the length of the
+ HMAC Name field in the payload, not including any other
+ field.
+
+o HMAC Name (variable length) - Name of the HMAC to use
+ in the private message MAC computation. If this field does
+ not exist then the default HMAC of the SILC protocol is used.
+ See the [SILC1] for defined HMACs.
+.in 3
.ti 0
.in 3
.ce
-Figure 17: Command Payload
+Figure 16: Command Payload
.in 6
-
.ti 0
2.3.14 Command Reply Payload
Command Reply Payload is used to send replies to the commands. The
Command Reply Payload is identical to the Command Payload thus see
-the upper section for the Command Payload specification.
+the 2.3.13 section for the payload specification.
The entity which sends the reply packet MUST set the Command Identifier
field in the reply packet's Command Payload to the value it received
server already knows this information this payload is not necessary
to be sent.
-Server receiving this request MUST reply with same payload sending
+Server receiving this request SHOULD reply with same payload sending
the mandatory authentication method. Algorithms that may be required
to be used by the authentication method are the ones already
established by the SILC Key Exchange protocol. See section Key
.in 3
.ce
-Figure 18: Connection Auth Request Payload
+Figure 17: Connection Auth Request Payload
.in 6
distributes information to other routers about the client in the SILC
network this payload is used.
-Also, when server connects to router, router uses this payload to inform
+Also, when server connects to router, router use this payload to inform
other routers about new server in the SILC network. However, every
server (or router) creates their own ID's thus the ID distributed by
this payload is not created by the distributor in this case. Servers
However, this payload MUST NOT be used to send information about new
channels. New channels are always distributed by sending the dedicated
-SILC_PACKET_NEW_CHANNEL packet.
+SILC_PACKET_NEW_CHANNEL packet. Client MUST NOT send this payload.
+Both client and server (and router) MAY receive this payload.
-Thus, this payload is very important and used every time when some
-new entity is registered to the SILC network. Client MUST NOT send this
-payload. Both client and server (and router) MAY receive this payload.
-
-The packet uses generic ID Payload as New ID Payload. See section
+The packet use generic ID Payload as New ID Payload. See section
2.3.2.1 for generic ID Payload.
2.3.17 New Client Payload
When client is connected to the server, keys has been exchanged and
-connection has been authenticated client MUST register itself to the
+connection has been authenticated, client MUST register itself to the
server. Client's first packet after key exchange and authentication
protocols must be SILC_PACKET_NEW_CLIENT. This payload tells server all
the relevant information about the connected user. Server creates a new
This payload sends username and real name of the user on the remote host
which is connected to the SILC server with SILC client. The server
creates the client ID according the information sent in this payload.
-The nickname of the user becomes the username sent in this payload.
-However, client should call NICK command after sending this payload to
-set the real nickname of the user which is then used to create new
-client ID.
+The nickname of the user becomes the nickname sent in this payload.
The payload may only be sent with SILC_PACKET_NEW_CLIENT packet. It
MUST NOT be sent in any other packet type. The following diagram
.in 3
.ce
-Figure 19: New Client Payload
+Figure 18: New Client Payload
.in 6
.in 3
.ce
-Figure 20: New Server Payload
+Figure 19: New Server Payload
.in 6
in this case server acts as router. Normal server send JOIN command
to the router (after it has received JOIN command from client) which
then processes the command and creates the channel. Client MUST NOT
-send this packet. Server may send this packet to a router when it is
+send this packet. Server MAY send this packet to a router when it is
announcing its existing channels to the router after it has connected
to the router.
-The packet uses generic Channel Payload as New Channel Payload. See
+The packet use generic Channel Payload as New Channel Payload. See
section 2.3.2.3 for generic Channel Payload. The Mode Mask field in the
Channel Payload is the mode of the channel.
.in 3
.ce
-Figure 21: Key Agreement Payload
+Figure 20: Key Agreement Payload
.in 6
processed as the [SILC3] describes. If the key material is used as
channel private key then the Sending Encryption Key, as defined in
[SILC3] is used as the channel private key. Other key material must
-be discarded. The [SILC1] defines the way to use the key material if
-it is intended to be used as private message keys. Any other use for
-the key material is undefined.
+be discarded. The [SILC1] in section 4.6 defines the way to use the
+key material if it is intended to be used as private message keys.
+Any other use for the key material is undefined.
.ti 0
2.3.21 Resume Router Payload
-The payload may only be sent with SILC_PACKET_RESUME_ROUTER packet. It
-MUST NOT be sent in any other packet type. The Following diagram
-represents the Resume Router Payload.
+See the [SILC1] for Resume Router protocol where this payload is
+used. The payload may only be sent with SILC_PACKET_RESUME_ROUTER
+packet. It MUST NOT be sent in any other packet type. The following
+diagram represents the Resume Router Payload.
.in 21
.in 3
.ce
-Figure 22: Resume Router Payload
+Figure 21: Resume Router Payload
.in 6
be sent in any other packet type. The following diagram represents the
File Transfer Payload.
+
+
+
+
+
+
.in 5
.nf
1 2 3
.in 3
.ce
-Figure 23: File Transfer Payload
+Figure 22: File Transfer Payload
.in 6
protocol. The following file transfer protocols has been
defined:
- 1 SSH File Transfer Protocol (SFTP) (mandatory)
+ 1 Secure File Transfer Protocol (SFTP) (mandatory)
If zero (0) value or any unsupported file transfer protocol
type is found in this field the packet must be discarded.
connection to the client is lost but the client remains as valid
client in the network. The client is able to resume the session back
by sending this packet and including the old Client ID, and an
-Authentication Payload [SILC1] which the server uses to verify with
+Authentication Payload [SILC1] which the server use to verify with
the detached client's public key. This also implies that the
mandatory authentication method is public key authentication.
.in 3
.ce
-Figure 24: Resume Client Payload
+Figure 23: Resume Client Payload
.in 6
.ti 0
2.4 SILC ID Types
-ID's are extensively used in the SILC network to associate different
-entities. The following ID's has been defined to be used in the SILC
-network.
+ID's are used in the SILC network to associate different entities.
+The following ID's has been defined to be used in the SILC network.
.in 6
0 No ID
- When ever specific ID cannot be used this is used.
+ This is used when other ID type is available at the time.
1 Server ID
.ti 0
2.5 Packet Encryption And Decryption
-SILC packets are encrypted almost entirely. Only small part of SILC
-header is not encrypted as described in section 5.2 SILC Packet Header.
-The SILC Packet header is the first part of a packet to be encrypted
-and it is always encrypted with the key of the next receiver of the
-packet. The data payload area of the packet is always entirely
-encrypted and it is usually encrypted with the next receiver's key.
-However, there are some special packet types and packet payloads
-that require special encryption process. These special cases are
-described in the next sections. First is described the normal packet
-encryption process.
+SILC packets are encrypted almost entirely. Only the MAC at the end
+of the packet is never encrypted. The SILC Packet header is the first
+part of a packet to be encrypted and it is always encrypted with the
+key of the next receiver of the packet. The data payload area of the
+packet is always entirely encrypted and it is usually encrypted with
+the next receiver's key. However, there are some special packet types
+and packet payloads that require special encryption process. These
+special cases are described in the next sections. First is described
+the normal packet encryption process.
.ti 0
Normal SILC packets are encrypted with the session key of the next
receiver of the packet. The entire SILC Packet header and the packet
-data payload is is also encrypted with the same key. Padding of the
-packet is also encrypted always with the session key, also in special
-cases. Computed MAC of the packet must not be encrypted.
+data payload is is encrypted with the same key. Padding of the packet
+is also encrypted always with the session key, also in special cases.
+Computed MAC of the packet MUST NOT be encrypted.
Decryption process in these cases are straightforward. The receiver
of the packet MUST first decrypt the SILC Packet header, or some parts
With out a doubt, this sort of decryption processing causes some
overhead to packet decryption, but never the less, is required.
+The MAC of the packet is also verified at this point. The MAC is
+computed from the ciphertext of the packet so it can be verified
+at this stage. The length of the packet need to be known to be able
+to verify the MAC from the ciphertext so the first 16 bytes need to
+be decrypted to determine the packet length. However, the MAC MUST
+be verified from the entire ciphertext.
+
.ti 0
2.5.2 Channel Message Encryption And Decryption
at all; it MUST NOT be re-encrypted with the session key.
Receiver of a channel message, who ever that is, is REQUIRED to decrypt
-the SILC Packet header to be able to even recognize the packet to be as
+the SILC Packet header to be able to recognize the packet to be as
channel message. This is same procedure as for normal SILC packets.
As the receiver founds the packet to be channel message, rest of the
packet processing is special. Rest of the SILC Packet header is
and padding is protected by the session key and the data area is not
touched.
-The true receiver of the private message, client, that is, is able
-to decrypt the private message as it shares the key with the sender
-of the message.
+The true receiver of the private message is able to decrypt the private
+message as it shares the key with the sender of the message.
.ti 0
Data integrity of a packet is protected by including a message
authentication code (MAC) at the end of the packet. The MAC is computed
from shared secret MAC key, that is established by the SILC Key Exchange
-protocol, from packet sequence number, and from the original contents
-of the packet. The MAC is always computed before the packet is
-encrypted, although after it is compressed if compression is used.
+protocol, from packet sequence number, and from the encrypted packet
+data. The MAC is always computed after packet is encrypted. This is
+so called Encrypt-Then-MAC order; packet is first encrypted, then MAC
+is computed from the encrypted data.
The MAC is computed from entire packet. Every bit of data in the packet,
including SILC Packet Header is used in the MAC computing. This way
the entire packet becomes authenticated.
-If the packet is special packet MAC is computed from the entire packet
-but part of the packet may be encrypted before the MAC is computed.
-This is case, for example, with channel messages where the message data
-is encrypted with key that server may not now. In this case the MAC
-has been computed from the encrypted data.
-
Hence, packet's MAC generation is as follows:
- mac = MAC(key, sequence number | SILC packet)
+ mac = MAC(key, sequence number | Encrypted SILC packet)
The MAC key is negotiated during the SKE protocol. The sequence number
is a 32 bit MSB first value starting from zero for first packet and
increasing for subsequent packets, finally wrapping after 2^32 packets.
-The value is never reset, not even after rekey has been performed. Note
-that the sequence number is incremented only when MAC is computed for a
-packet. If packet is not encrypted and MAC is not computed then the
-sequence number is not incremented. Hence, the sequence number is zero
-for first encrypted packet.
+The value is never reset, not even after rekey has been performed.
+However, rekey MUST be performed before the sequence number wraps
+and repeats from zero. Note that the sequence number is incremented only
+when MAC is computed for a packet. If packet is not encrypted and MAC is
+not computed then the sequence number is not incremented. Hence, the
+sequence number is zero for the very first encrypted packet.
See [SILC1] for defined and allowed MAC algorithms.
2.7 Packet Padding Generation
Padding is needed in the packet because the packet is encrypted. It
-MUST always be multiple by eight (8) or multiple by the block size
+always MUST be multiple by eight (8) or multiple by the block size
of the cipher, which ever is larger. The padding is always encrypted.
For normal packets the padding is added after the SILC Packet Header
may be calculated as follows:
.in 6
-padding length = 16 - (packet_length mod block_size)
+padding_length = 16 - (packet_length mod block_size)
+if (padding_length < 8)
+ padding_length += block_size
.in 3
The `block_size' is the block size of the cipher. The maximum padding
-length is 128 bytes, and minimum is 1 byte. The above algorithm calculates
-the padding to the next block size, and always returns the padding
-length between 1 - 16 bytes. However, implementations may add padding
-up to 128 bytes. For example packets that include a passphrase or a
-password for authentication purposes SHOULD pad the packet up to the
-maximum padding length.
+length is 128 bytes, and minimum is 8 bytes. For example, packets that
+include a passphrase or a password for authentication purposes SHOULD
+pad the packet up to the maximum padding length. The maximum padding
+is calculated as follows:
+
+.in 6
+padding_length = 128 - (packet_length mod block_size)
+.in 3
For special packets the padding calculation is different as special
packets may be encrypted differently. In these cases the encrypted
length.
The padding MUST be random data, preferably, generated by
-cryptographically strong random number generator.
+cryptographically strong random number generator for each packet
+separately.
.ti 0
If the sender wants to compress the packet it MUST apply the
compression now. Sender MUST also compute the padding as described
-in above sections. Then sender MUST compute the MAC of the packet.
-
-Then sender MUST encrypt the packet as has been described in above
-sections according whether the packet is normal packet or special
+in above sections. Then sender MUST encrypt the packet as has been
+described in above sections according whether the packet is normal
+packet or special packet. Then sender MUST compute the MAC of the
packet. The computed MAC MUST NOT be encrypted.
EMail: priikone@iki.fi
-This Internet-Draft expires 15 November 2002
+This Internet-Draft expires 26 April 2003
projects / silc.git / blobdiff