.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH 15 May 2002
+.ds RH XXX
.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-05.txt XXX
+Expires: XXX
.in 3
2.3.2.2 Argument Payload ............................ 18
2.3.2.3 Channel Payload ............................. 19
2.3.2.4 Public Key Payload .......................... 20
+ 2.3.2.5 Message Payload ............................. 20
2.3.3 Disconnect Payload .................................. 20
2.3.4 Success Payload ..................................... 21
2.3.5 Failure Payload ..................................... 22
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
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 compsession is
+always applied before encryption.
All fields in all packet payloads are always in MSB (most significant
byte first) order.
.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
+ area 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
-
-
.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
.in 3
+.ti 0
+2.3.2.5 Message Payload
+
+Generic Message Payload can be used to send message 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 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
+ 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 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 is not 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.
+
+ 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 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
.in 3
.ce
-Figure 7: Disconnect Payload
+Figure 8: Disconnect Payload
.in 6
o Status (1 byte) - Indicates the Status Type, defined in [SILC3]
.in 3
.ce
-Figure 8: Success Payload
+Figure 9: Success Payload
.in 6
.in 3
.ce
-Figure 9: Failure Payload
+Figure 10: Failure Payload
.in 6
.in 3
.ce
-Figure 10: Reject Payload
+Figure 11: Reject Payload
.in 6
.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
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 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 in 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 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
.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
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
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
~ 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
.in 3
.ce
-Figure 18: Connection Auth Request Payload
+Figure 17: Connection Auth Request Payload
.in 6
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.
.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
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
.in 3
.ce
-Figure 22: Resume Router Payload
+Figure 21: Resume Router Payload
.in 6
.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.
.in 3
.ce
-Figure 24: Resume Client Payload
+Figure 23: Resume Client Payload
.in 6
.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
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.
-However, rekey SHOULD be performed before the sequence number 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 first encrypted packet.
+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.
projects / crypto.git / blobdiff