.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH 11 February 2004
+.ds RH 15 January 2007
.ds CH
.na
.hy 0
.nf
Network Working Group P. Riikonen
Internet-Draft
-draft-riikonen-silc-spec-09.txt XX
-Expires: XXX
+draft-riikonen-silc-spec-09.txt 15 January 2007
+Expires: 15 July 2007
.in 3
<draft-riikonen-silc-spec-09.txt>
.ti 0
-Status of this Memo
+Status of this Draft
-This document is an Internet-Draft and is in full conformance with
-all provisions of Section 10 of RFC 2026. Internet-Drafts are
-working documents of the Internet Engineering Task Force (IETF), its
-areas, and its working groups. Note that other groups may also
-distribute working documents as Internet-Drafts.
+By submitting this Internet-Draft, each author represents that any
+applicable patent or other IPR claims of which he or she is aware
+have been or will be disclosed, and any of which he or she becomes
+aware will be disclosed, in accordance with Section 6 of BCP 79.
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in progress."
+Internet-Drafts are working documents of the Internet Engineering
+Task Force (IETF), its areas, and its working groups. Note that
+other groups may also distribute working documents as Internet-
+Drafts. Internet-Drafts are draft documents valid for a maximum of
+six months and may be updated, replaced, or obsoleted by other
+documents at any time. It is inappropriate to use Internet-Drafts as
+reference material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
+http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
+http://www.ietf.org/shadow.html.
-The distribution of this memo is unlimited.
.ti 0
2.5 Router Connections ........................................ 8
3 SILC Specification ............................................ 9
3.1 Client .................................................... 9
- 3.1.1 Client ID ........................................... 9
- 3.2 Server .................................................... 10
+ 3.1.1 Client ID ........................................... 10
+ 3.2 Server .................................................... 11
3.2.1 Server's Local ID List .............................. 11
3.2.2 Server ID ........................................... 12
3.2.3 SILC Server Ports ................................... 12
3.3 Router .................................................... 13
3.3.1 Router's Local ID List .............................. 13
3.3.2 Router's Global ID List ............................. 14
- 3.3.3 Router's Server ID .................................. 14
+ 3.3.3 Router's Server ID .................................. 15
3.4 Channels .................................................. 15
3.4.1 Channel ID .......................................... 16
- 3.5 Operators ................................................. 16
+ 3.5 Operators ................................................. 17
3.6 SILC Commands ............................................. 17
3.7 SILC Packets .............................................. 17
- 3.8 Packet Encryption ......................................... 17
+ 3.8 Packet Encryption ......................................... 18
3.8.1 Determination of the Source and the Destination ..... 18
3.8.2 Client To Client .................................... 19
3.8.3 Client To Channel ................................... 20
3.8.4 Server To Server .................................... 21
3.9 Key Exchange And Authentication ........................... 21
- 3.9.1 Authentication Payload .............................. 21
- 3.10 Algorithms ............................................... 23
- 3.10.1 Ciphers ............................................ 23
+ 3.9.1 Authentication Payload .............................. 22
+ 3.10 Algorithms ............................................... 24
+ 3.10.1 Ciphers ............................................ 24
3.10.1.1 CBC Mode .................................. 24
- 3.10.1.2 CTR Mode .................................. 24
- 3.10.1.3 Randomized CBC Mode ....................... 26
- 3.10.2 Public Key Algorithms .............................. 26
- 3.10.2.1 Multi-Precision Integers .................. 27
- 3.10.3 Hash Functions ..................................... 27
- 3.10.4 MAC Algorithms ..................................... 27
- 3.10.5 Compression Algorithms ............................. 28
- 3.11 SILC Public Key .......................................... 28
- 3.12 SILC Version Detection ................................... 31
- 3.13 UTF-8 Strings in SILC .................................... 31
- 3.13.1 UTF-8 Identifier Strings ........................... 32
- 3.14 Backup Routers ........................................... 33
- 3.14.1 Switching to Backup Router ......................... 35
- 3.14.2 Resuming Primary Router ............................ 36
-4 SILC Procedures ............................................... 38
- 4.1 Creating Client Connection ................................ 38
- 4.2 Creating Server Connection ................................ 40
- 4.2.1 Announcing Clients, Channels and Servers ............ 40
- 4.3 Joining to a Channel ...................................... 42
- 4.4 Channel Key Generation .................................... 43
- 4.5 Private Message Sending and Reception ..................... 44
- 4.6 Private Message Key Generation ............................ 44
- 4.7 Channel Message Sending and Reception ..................... 45
- 4.8 Session Key Regeneration .................................. 46
- 4.9 Command Sending and Reception ............................. 46
- 4.10 Closing Connection ....................................... 47
- 4.11 Detaching and Resuming a Session ......................... 48
-5 Security Considerations ....................................... 49
-6 References .................................................... 50
-7 Author's Address .............................................. 52
-Appendix A ...................................................... 52
-Appendix B ...................................................... 54
-Appendix C ...................................................... XXX
-Appendix D ...................................................... XXX
-Full Copyright Statement ........................................ XXX
+ 3.10.1.2 CTR Mode .................................. 25
+ 3.10.1.3 Randomized CBC Mode ....................... 27
+ 3.10.2 Public Key Algorithms .............................. 27
+ 3.10.2.1 Multi-Precision Integers .................. 28
+ 3.10.3 Hash Functions ..................................... 28
+ 3.10.4 MAC Algorithms ..................................... 28
+ 3.10.5 Compression Algorithms ............................. 29
+ 3.11 SILC Public Key .......................................... 29
+ 3.12 SILC Version Detection ................................... 32
+ 3.13 UTF-8 Strings in SILC .................................... 33
+ 3.13.1 UTF-8 Identifier Strings ........................... 33
+ 3.14 Backup Routers ........................................... 34
+ 3.14.1 Switching to Backup Router ......................... 36
+ 3.14.2 Resuming Primary Router ............................ 37
+4 SILC Procedures ............................................... 39
+ 4.1 Creating Client Connection ................................ 39
+ 4.2 Creating Server Connection ................................ 41
+ 4.2.1 Announcing Clients, Channels and Servers ............ 42
+ 4.3 Joining to a Channel ...................................... 43
+ 4.4 Channel Key Generation .................................... 44
+ 4.5 Private Message Sending and Reception ..................... 45
+ 4.6 Private Message Key Generation ............................ 46
+ 4.7 Channel Message Sending and Reception ..................... 47
+ 4.8 Session Key Regeneration .................................. 47
+ 4.9 Command Sending and Reception ............................. 48
+ 4.10 Closing Connection ....................................... 49
+ 4.11 Detaching and Resuming a Session ......................... 49
+ 4.12 UDP/IP Connections ...................................... 51
+5 Security Considerations ....................................... 52
+6 References .................................................... 53
+7 Author's Address .............................................. 55
+Appendix A ...................................................... 55
+Appendix B ...................................................... 56
+Appendix C ...................................................... 57
+Appendix D ...................................................... 57
+Full Copyright Statement ........................................ 58
.ti 0
List of Figures
Figure 4: Router Connections
Figure 5: SILC Public Key
Figure 6: Counter Block
+Figure 7: CTR Mode Initialization Vector
.ti 0
in [SILC3] along with connection authentication protocol and should
be read to fully comprehend this document and protocol.
-The SILC protocol has been developed to work on TCP/IP network
-protocol, although it could be made to work on other network protocols
-with only minor changes. However, it is recommended that TCP/IP
-protocol is used under SILC protocol. Typical implementation would
-be made in client-server model.
+The SILC protocol has been developed to work on both TCP/IP and UDP/IP
+network protocols. However, typical implementation would use only TCP/IP
+with SILC protocol. Typical implementation would be made in client-server
+model.
.ti 0
This section describes various SILC protocol concepts that forms the
actual protocol, and in the end, the actual SILC network. The mission
of the protocol is to deliver messages from clients to other clients
-through routers and servers in secure manner. The messages may also
+through servers and routers in secure manner. The messages may also
be delivered from one client to many clients forming a group, also
known as a channel.
A difference between normal server and router server is that routers
knows all global information and keep the global network state up to date.
They also do the actual routing of the messages to the correct receiver
-between other cells. Normal servers knows only local information and
-receive global information only when it is needed. They do not need to
-keep the global network state up to date. This makes the network faster
-and scalable as there are less servers that needs to maintain global
-network state.
+within the cell and between other cells. Normal servers knows only local
+information and receive global information only when it is needed. They do
+not need to keep the global network state up to date. This makes the
+network faster and scalable as there are less servers that needs to
+maintain global network state.
This, on the other hand, leads into a cellular like network, where
routers are in the center of the cell and servers are connected to the
on the other hand may connect to other routers to form the actual SILC
network, as seen in above figure. However, router is also able to act
as normal SILC server; clients may connect to it the same way as to
-normal SILC server. Normal server also cannot have active connections
-to more than one router. Normal server cannot be connected to two
-different cells. Router servers, on the other hand, may have as many
-router to router connections as needed. Other direct routes between
-other routers is also possible in addition of the mandatory ring
-connections. This leads into a hybrid ring-mesh network topology.
+normal SILC server. This, however is not a requirement and if needed
+router servers may be hidden from users by not allowing direct client
+connections. Normal server also cannot have active connections to more
+than one router. Normal server cannot be connected to two different
+cells. Router servers, on the other hand, may have as many router to
+router connections as needed. Other direct routes between other routers
+is also possible in addition of the mandatory ring connections. This
+leads into a hybrid ring-mesh network topology.
There are many issues in this network topology that needs to be careful
about. Issues like routing, the size of the cells, the number of the
are delivered from one router to the other.
+
+
.ti 0
2.4 Channel Communication
Example: Network with three routers. Router 1. uses Router 2. as its
primary router. Router 2. uses Router 3. as its primary router,
- and Router 3. uses Router 1. as its primary router. There may
- be other direct connections between the routers but they must
- not be used as primary routes.
+ and Router 3. uses Router 1. as its primary router. When there
+ are four or more routers in th enetwork, there may be other
+ direct connections between the routers but they must not be used
+ as primary routes.
The above example is applicable to any amount of routers in the network
except for two routers. If there are only two routers in the network both
for two different nicknames. However, this is not expected to happen
nor cause any serious problems if it would occur. Nicknames are usually
logical and it is unlikely to have two distinct logical nicknames
-produce same truncated hash value.
+produce same truncated hash value. Use of MD5 in nickname hash is not
+a security feature.
.ti 0
Router server in SILC network is responsible for keeping the cell together
and routing messages to other servers and to other routers. Router server
-is also a normal server thus clients may connect to it as it would be
-just normal SILC server.
+may also act as normal server when clients may connect to it. This is not
+requirement and router servers may be hidden from clients.
-However, router servers has a lot of important tasks that normal servers
+However, router servers have a lot of important tasks that normal servers
do not have. Router server knows everything and keeps the global state.
They know all clients currently on SILC, all servers and routers and all
channels in SILC. Routers are the only servers in SILC that care about
+
+
.ti 0
3.3.3 Router's Server ID
o Router's Server ID IP address - Indicates the IP address of
the router of the cell where this channel is created. This is
- taken from the router's Server ID. This way SILC router knows
+ taken from the router's Server ID. This way SILC routers know
where this channel resides in the SILC network.
o Router's Server ID port - Indicates the port of the channel on
.in 3
+
.ti 0
3.5 Operators
is available in the SILC Packet Header which is included in all packets
sent in SILC network. The SILC Packet Header is described in [SILC2].
-The header MUST be encrypted with the session key of whom is the next
+The header MUST be encrypted with the session key of who is the next
receiver of the packet along the route. The receiver of the packet, for
example a router along the route, is able to determine the sender and the
destination of the packet by decrypting the SILC Packet Header and
Note that the packet and the packet header may be encrypted with
different keys. For example, packets to channels are encrypted with
the channel key, however, the header is encrypted with the session key
-as described above. However, the header and the packet may be encrypted
-with same key. This is the case, for example, with command packets.
+as described above. Most other packets have both header and packet
+payload encrypted with the same key, such as command packets.
.ti 0
o Client 1 sends encrypted packet to its server. The packet header
is encrypted with the session key shared between the client and
- server, and the private message is encrypted with the private
- message delivery key shared between clients.
+ server, and the private message payload is encrypted with the
+ private message delivery key shared between clients.
o Server determines the destination of the packet and sends the
packet to the router. Header is encrypted with the session key.
REQUIRED to use authentication protocol when connecting. The
authentication may be based on passphrase (pre-shared secret) or public
key based on digital signatures. All passphrases sent in SILC protocol
-MUST be UTF-8 [RFC3629] encoded. The connection authentication protocol
+MUST be UTF-8 [RFC3629] encoded. The connection authentication protocol
is described in detail in [SILC3].
in the payload, the ID associated to the connection and the public key
(or certificate) received in the SKE protocol. After computing the
receiver MUST verify the signature. Also in case of public key
-authentication this payload is encrypted.
+authentication this payload is always encrypted. This payload is
+always sent as part of some other payload.
.ti 0
Algorithm "none" does not perform any encryption process at all and
thus is not recommended to be used. It is recommended that no client
-or server implementation would accept none algorithm except in special
+or server implementation would accept "none" algorithm except in special
debugging mode.
.ti 0
3.10.1.1 CBC Mode
-The "cbc" encryption mode is CBC mode with inter-packet chaining. This
-means that the Initialization Vector (IV) for the next encryption block
-is the previous ciphertext block. The very first IV MUST be random and
-is generated as described in [SILC3].
+The "cbc" encryption mode is the standard cipher-block chaining mode.
+The very first IV is derived from the SILC Key Exchange protocol.
+Subsequent IVs for encryption is the previous ciphertext block. The very
+first IV MUST be random and is generated as described in [SILC3].
.ti 0
decryption operation is not needed since both encryption and decryption
process is simple XOR with the plaintext block and the key stream block.
-The counter block is used to create the key for the CTR mode. When
-SILC specifications refer to Initialization Vector (IV) in general cases,
-in case of CTR mode it refers to the counter block. The format of the
-128 bit counter block is as follows:
+The counter block is used to create the key for the CTR mode. The format
+of the 128 bit counter block is as follows:
.in 5
.nf
| Truncated HASH from SKE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending/Receiving IV from SKE |
-| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Packet Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
protocol. This acts as session identifier and each rekey MUST
produce a new HASH value.
-o Sending/Receiving IV from SKE (8 bytes) - This value is the
- first 8 bytes from the Sending IV or Receiving IV generated in
- the SKE protocol. When this mode is used to encrypt sending
- traffic the Sending IV is used, when used to decrypt receiving
- traffic the Receiving IV is used. This assures that two parties
- of the protocol use different IV for sending traffic. Each rekey
- MUST produce a new value.
-
-o Block Counter (4 bytes) - This is the counter value for the
- counter block and is MSB ordered number starting from one (1)
- value for first block and incrementing for subsequent blocks.
- The same value MUST NOT be used twice. The rekey MUST be
- performed before this counter value wraps.
+o Sending/Receiving IV from SKE (4 bytes) - If the CTR mode is fully
+ stateful this field MUST include the first 4 bytes from the Sending
+ IV or Receiving IV generated in SKE protocol. When this mode is
+ used to encrypt sending traffic the Sending IV is used, when used
+ to decrypt receiving traffic the Receiving IV is used. This assures
+ that two parties of the protocol use different IV for sending
+ traffic. Each rekey MUST produce a new value.
+
+ If the IV Included flag is negotiated in SKE or CTR mode is used
+ where the IV is included in the data payload, this field is the
+ Nonce field from the IV received in the packet, defined below.
+
+o Packet Counter (4 bytes) - This is MSB first ordered monotonically
+ increasing packet counter. It is set value 1 for first packet and
+ increases for subsequent packets. After rekey the counter MUST
+ restart from 1.
+
+ If the IV Included flag is negotiated in SKE or CTR mode is used
+ where the IV is included in the data payload, this field is the
+ Packet Counter field from the IV received in the packet, defined
+ below.
+
+o Block Counter (4 bytes) - This is an MSB first ordered block
+ counter starting from 1 for first block and increasing for
+ subsequent blocks. The counter is always set to value 1 for
+ a new packet.
.in 3
CTR mode MUST NOT be used with "none" MAC. Implementations also MUST
assure that the same counter block is not used to encrypt more than
-one block. Also, the key material used with CTR mode MUST be fresh
-key material. Static keys (pre-shared keys) MUST NOT be used with
-CTR mode. For this reason using CTR mode to encrypt for example
-channel messages or private messages with a pre-shared key is
-inappropriate. For private messages, the Key Agreement could be
-performed to produce fresh key material.
+one block. None of the counters must be allowed to wrap without rekey.
+Also, the key material used with CTR mode MUST be fresh key material.
+Static keys (pre-shared keys) MUST NOT be used with CTR mode. For this
+reason using CTR mode to encrypt for example channel messages or private
+messages with a pre-shared key is inappropriate. For private messages,
+the Key Agreement [SILC2] could be performed to produce fresh key material.
If the IV Included flag was negotiated in SKE, or CTR mode is used to
-protect channel messages where the counter block will be included in the
-Message Payload, implementations SHOULD still use the same counter block
-format as defined above. However, implementations are RECOMMENDED to
-replace the Truncated HASH field with a 32 bit random value for each IV
-(counter block) per encrypted SILC packet. Also note, that in this case
-the decryption process is not stateful and receiver cannot precompute the
-key stream.
+protect channel messages where the IV will be included in the Message
+Payload, the Initialization Vector (IV) to be used is a 64-bit block
+containing randomness and packet counter. Also note, that in this case
+the decryption process is not stateful and receiver cannot precompute
+the key stream. Hence, the Initialization Vector (IV) when CTR mode is
+used is as follows.
+
+.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
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Nonce |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Packet Counter |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 7: CTR Mode Initialization Vector
+
+o Nonce (4 bytes) - This field should be random or otherwise not
+ easily determinable and SHOULD change for each packet.
+
+o Packet Counter (4 bytes) - This is MSB first ordered monotonically
+ increasing packet counter. It is set value 1 for first packet and
+ increases for subsequent packets. After rekey the counter MUST
+ restart from 1.
+
+When decrypting the packet the Counter Block is assembled by concatenating
+the truncated hash, with the received nonce and packet counter, and with
+the block counter. The Counter Block is then used to compute the key
+stream to perform the decryption.
.ti 0
The "rcbc" encryption mode is CBC mode with randomized IV. This means
that each IV for each packet MUST be chosen randomly. When encrypting
-more than one block the normal inter-packet chaining is used, but for
-the first block new random IV is selected in each packet. In this mode
-the IV is appended at the end of the last ciphertext block and thus
-delivered to the recipient. This mode increases the ciphertext size by
-one ciphertext block. Note also that some data payloads in SILC are
-capable of delivering the IV to the recipient. When explicitly
-encrypting these payloads with randomized CBC the IV MUST NOT be appended
-at the end of the ciphertext, but is placed at the specified location
-in the payload. However, Message Payload for example has the IV at
-the location which is equivalent to placing it after the last ciphertext
-block. When using CBC mode with such payloads it is actually equivalent
-to using randomized CBC since the IV is selected in random and included
-in the ciphertext.
+more than one block the normal IV chaining is used, but for the first
+block new random IV is selected in each packet. In this mode the IV
+is appended to the ciphertext. If this mode is used to secure the SILC
+session, the IV Included flag must be negotiated in SILC Key Exchange
+protocol. It may also be used to secure Message Payloads which can
+deliver the IV to the recipient.
.ti 0
.in 3
DSS is described in [Menezes]. The RSA MUST be implemented according
-PKCS #1 [PKCS1]. The mandatory PKCS #1 implementation in SILC MUST be
-compliant to either PKCS #1 version 1.5 or newer with the following
-notes: The signature encoding is always in same format as the encryption
-encoding regardless of the PKCS #1 version. The signature with appendix
-(with hash algorithm OID in the data) MUST NOT be used in the SILC. The
-rationale for this is that there is no binding between the PKCS #1 OIDs
-and the hash algorithms used in the SILC protocol. Hence, the encoding
-is always in PKCS #1 version 1.5 format.
+PKCS #1 [PKCS1]. When using SILC Public Key version 2 the PKCS #1
+implementation MUST be compliant with PKCS #1 version 1.5. The signatures
+are computed with appendix; the hash OID is included in the signature.
+The user may always select the hash algorithm for the signatures. When
+using SILC Public Key version 1 the PKCS #1 implementation MUST be
+compliant with PKCS #1 version 1.5 where signatures are computed without
+appendix; the hash OID is not present in the signature. The hash
+algorithm used is specified separately or the default hash algorithm is
+used, as defined below.
Additional public key algorithms MAY be defined to be used in SILC.
When signatures are computed in SILC the computing of the signature is
-represented as sign(). The signature computing procedure is dependent
-of the public key algorithm, and the public key or certificate encoding.
+denoted as sign(). The signature computing procedure is dependent of
+the public key algorithm, and the public key or certificate encoding.
When using SILC public key the signature is computed as described in
previous paragraph for RSA and DSS keys. If the hash function is not
-specified separately for signing process SHA-1 MUST be used. When using
+specified separately for signing process SHA-1 MUST be used, except with
+SILC public key version 2 and RSA algorithm when the user MAY always
+select the hash algorithm. In this case the hash algorithm is included
+in the signature and can be retrieved during verification. When using
SSH2 public keys the signature is computed as described in [SSH-TRANS].
When using X.509 version 3 certificates the signature is computed as
described in [PKCS7]. When using OpenPGP certificates the signature is
-computed as described in [PGP].
+computed as described in [PGP] and the PGP signature type used is 0x00.
.ti 0
3.10.2.1 Multi-Precision Integers
Multi-Precision (MP) integers in SILC are encoded and decoded as defined
-in PKCS #1 [PKCS1]. MP integers are unsigned, encoded with desired octet
-length. This means that if the octet length is more than the actual
-length of the integer one or more leading zero octets will appear at the
-start of the encoding. The actual length of the integer is the bit size
-of the integer not counting any leading zero bits.
+in PKCS #1 [PKCS1]. MP integers are unsigned, encoded with the exact
+octet length of the integer. No extra leading zero octets may appear.
+The actual length of the integer is the bit size of the integer not
+counting any leading zero bits. The octet length is derived by calculating
+(bit_length + 7) / 8.
.ti 0
The following Hash algorithm are defined in SILC protocol:
.in 6
-sha1 SHA-1, length = 20 (REQUIRED)
-md5 MD5, length = 16 (RECOMMENDED)
+sha1 SHA-1, length = 20 bytes (REQUIRED)
+sha256 SHA-256, length = 32 bytes (RECOMMENDED)
+md5 MD5, length = 16 bytes (RECOMMENDED)
.in 3
The following MAC algorithms are defined in SILC protocol:
.in 6
-hmac-sha1-96 HMAC-SHA1, length = 12 bytes (REQUIRED)
-hmac-md5-96 HMAC-MD5, length = 12 bytes (OPTIONAL)
-hmac-sha1 HMAC-SHA1, length = 20 bytes (OPTIONAL)
-hmac-md5 HMAC-MD5, length = 16 bytes (OPTIONAL)
-none No MAC (OPTIONAL)
+hmac-sha1-96 HMAC-SHA1, length = 12 bytes (REQUIRED)
+hmac-sha256-96 HMAC-SHA256, length = 12 bytes (RECOMMENDED)
+hmac-md5-96 HMAC-MD5, length = 12 bytes (OPTIONAL)
+hmac-sha1 HMAC-SHA1, length = 20 bytes (OPTIONAL)
+hmac-sha256 HMAC-SHA256, length = 32 bytes (OPTIONAL)
+hmac-md5 HMAC-MD5, length = 16 bytes (OPTIONAL)
+none No MAC (OPTIONAL)
.in 3
The "none" MAC is not recommended to be used as the packet is not
The HMAC algorithm is described in [HMAC]. The hash algorithms used
in HMACs, the SHA-1 is described in [RFC3174] and MD5 is described
-in [RFC1321].
+in [RFC1321]. The SHA-256 algorithm and its used with HMAC is described
+in [SHA256].
Additional MAC algorithms MAY be defined to be used in SILC.
the Identifier field, not including this field.
o Identifier (variable length) - Indicates the identifier
- of the public key. This data can be used to identify
- the owner of the key. The identifier is of the following
+ of the public key. This data can be used to identify the
+ owner of the key. The identifier may be of the following
format:
- UN User name
- HN Host name or IP address
- RN Real name
- E EMail address
- O Organization
- C Country
-
+ UN User name
+ HN Host name or IP address
+ RN Real name
+ E EMail address
+ O Organization
+ C Country
+ V Version
Examples of an identifier:
`UN=priikone, HN=poseidon.pspt.fi, E=priikone@poseidon.pspt.fi'
- `UN=sam, HN=dummy.fi, RN=Sammy Sam, O=Company XYZ, C=Finland'
+ `UN=sam, HN=dummy.fi, RN=Sammy Sam, C=Finland, V=2'
At least user name (UN) and host name (HN) MUST be provided as
identifier. The fields are separated by commas (`,'). If
comma is in the identifier string it must be escaped as `\\,',
for example, `O=Company XYZ\\, Inc.'. Other characters that
require escaping are listed in [RFC2253] and are to be escaped
- as defined therein.
+ as defined therein. The Version (V) may only be a decimal digit.
o Public Data (variable length) - Includes the actual
public data of the public key.
field if they are used.
.in 3
+The SILC Public Key is version is 2. If the Version (V) identifier is
+not present the SILC Public Key version is expected to be 1. All new
+implementations SHOULD support version 1 but SHOULD only generate version 2.
+In this case the Version (V) identifier MUST be present.
+
All fields in the public key are in MSB (most significant byte first)
order. All strings in the public key MUST be UTF-8 encoded.
they are defined here for external protocols (protocols that may like
to use SILC Public Key).
+A fingerprint from SILC Public Key is computed from the whole encoded
+public key data block. All fields are included in computation. Compliant
+implementations MUST support computing a 160-bit SHA-1 fingerprint.
+
.ti 0
3.12 SILC Version Detection
Identifier strings are special strings in SILC protocol that require
more careful processing, than the general UTF-8 strings described in the
-previous section. These strings include the nicknames, server names,
-hostnames and some other identifier strings. These strings are prepared
-using the stringprep [RFC3454] standard. The Appendix A defines the
-stringprep profile for SILC identifier strings and conforming
+previous section. These strings include the nicknames, server names,
+hostnames and some other identifier strings. These strings are prepared
+using the stringprep [RFC3454] standard. The Appendix A defines the
+stringprep profile for SILC identifier strings and conforming
implementation MUST use the profile to prepare any identifier string.
The stringprep profile describes how identifier strings are prepared,
backup routers, servers and other routers in the network.
It must be noted that some of the channel messages and private messages
-may be lost during the switch to the backup router. The announcements
+may be lost during the switch to the backup router, unless the message
+flag SILC_MESSAGE_FLAG_ACK is set in the message. The announcements
assure that the state of the network is not lost during the switch.
It is RECOMMENDED that there would be at least one backup router in
If the action is allowed type value 21 is sent back to the server from
the backup router. It is RECOMMENDED that implementations use the
SILC_COMMAND_PING command to detect whether primary router is responsive.
+If the backup router notices that the primary router is unresponsive
+it SHOULD NOT start sending data to server links before the server has
+sent the SILC_PACKET_RESUME_ROUTER with type value 21.
The servers connected to the backup router must then announce their
clients, channels, channel users, channel user modes, channel modes,
SILC_NOTIFY_TYPE_WATCH to the watcher.
-
-
.ti 0
4.2 Creating Server Connection
router's Server ID as Destination when communicating with the router.
+
+
.ti 0
4.2.1 Announcing Clients, Channels and Servers
When client receives the SILC_PACKET_CHANNEL_KEY packet with the
Channel Key Payload it MUST process the key data to create encryption
-and decryption key, and to create the HMAC key that is used to compute
+and decryption key, and to create the MAC key that is used to compute
the MACs of the channel messages. The processing is as follows:
channel_key = raw key data
- HMAC key = hash(raw key data)
+ MAC key = hash(raw key data)
The raw key data is the key data received in the Channel Key Payload.
-The hash() function is the hash function used in the HMAC of the channel.
-Note that the server also MUST save the channel key.
+It is used for both encryption and decryption. The hash() is the hash
+function used with the HMAC of the channel. Note that the server also
+MUST save the channel key.
.ti 0
After both parties have regenerated the session key, both MUST send
SILC_PACKET_REKEY_DONE packet to each other. These packets are still
secured with the old key. After these packets, the subsequent packets
-MUST be protected with the new key.
+MUST be protected with the new key. Note that, in case SKE was performed
+again the SILC_PACKET_SUCCESS is not sent. The SILC_PACKET_REKEY_DONE
+is sent in its stead.
.ti 0
persistent as long as the server is running.
+
+.ti 0
+4.12 UDP/IP Connections
+
+SILC protocol allows the use of UDP/IP instead of TCP/IP. There may be
+many reasons to use UDP, such as video and audio conferencing might
+be more efficient with UDP.
+
+When UDP/IP is used, in the SILC Key Exchange protocol the IV Included
+flag MUST be set and the first 16-bits of the Cookie field in the Key
+Exchange Start Payload MUST include the port that the other end will use
+as the SILC session port. The port is in MSB first order. Both initiator
+and responder will set the port they are going to use and all packets
+after the SKE has been completed with the SILC_PACKET_SUCCESS packet MUST
+be sent to the specified port. Initiator will send them to the port
+responder specified and vice versa. When verifying the cookie for
+modifications the first two bytes are to be ignored in case IV Included
+flag has been set.
+
+The default SILC port or port where the SILC server is listenning for
+incoming packets is used only during initial key exchange protocol. After
+SKE has been completed all packets are sent to the specified ports,
+including connection authentication packets and rekey packets even when
+PFS is used in rekey.
+
+Changing the ports during SILC session is possible only by first detaching
+from the server (with client-server connections) and then performing the
+SILC Key Exchange protocol from the beginning and resuming the detached
+session.
+
+Since the UDP is unreliable transport the SKE packets may not arrive to
+the recipient. Implementation should support retransmission of SKE
+packets by using exponential backoff algorithm. Also other SILC packets
+such as messages may drop en route. With message packets only way to
+assure reliable delivery is to use message acking and retransmit the
+message by using for example exponential backoff algorithm. With SKE
+packets the initial timeout value should be no more than 1000
+milliseconds. With message packets the initial timeout value should be
+around 5000 milliseconds.
+
+
.ti 0
5 Security Considerations
It however must be noted that if the client requires absolute security
by not trusting any of the servers or routers in the SILC Network, it can
-be accomplished by negotiating private keys outside the SILC Network,
-either using SKE or some other key exchange protocol, or to use some
-other external means for distributing the keys. This applies for all
-messages, private messages and channel messages.
+be accomplished by negotiating private secret keys outside the SILC
+Network, either using SKE or some other key exchange protocol, or to use
+some other external means for distributing the keys. This applies for
+all messages, private messages and channel messages.
It is important to note that SILC, like any other security protocol, is
not a foolproof system; the SILC servers and routers could very well be
6 References
[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
- May 2002.
+ January 2007.
[SILC3] Riikonen, P., "SILC Key Exchange and Authentication
- Protocols", Internet Draft, May 2002.
+ Protocols", Internet Draft, January 2007.
-[SILC4] Riikonen, P., "SILC Commands", Internet Draft, May 2002.
+[SILC4] Riikonen, P., "SILC Commands", Internet Draft, January 2007.
[IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
RFC 1459, May 1993.
[RFC3454] Hoffman, P., et al., "Preparation of Internationalized
Strings ("stringprep")", RFC 3454, December 2002.
+[SHA256] Eastlake 3rd, D., et al., "US Secure Hash Algorithms (SHA
+ and HMAC-SHA)", RFC 4634, July 2006.
+
+
.ti 0
7 Author's Address
.nf
Pekka Riikonen
-Snellmaninkatu 34 A 15
-70100 Kuopio
+Helsinki
Finland
EMail: priikone@iki.fi
profile defines the following as required by [RFC3454].
- Intended applicability of the profile: the following identifiers in
- the SILC Protocol; nicknames, usernames, server names, hostnames,
+ the SILC Protocol; nicknames, usernames, server names, hostnames,
service names, algorithm names and other security property names [SILC3],
and SILC Public Key name.
.ti 0
Appendix B
-This appendix defines the stringprep [RFC3454] profile for channel name
-strings in SILC protocol. Compliant implementation MUST use this profile
-to prepare the channel name strings in the SILC protocol. The profile
+This appendix defines the stringprep [RFC3454] profile for channel name
+strings in SILC protocol. Compliant implementation MUST use this profile
+to prepare the channel name strings in the SILC protocol. The profile
defines the following as required by [RFC3454].
- Intended applicability of the profile: channel names.
This appendix defines additional prohibited characters in the identifier
strings as defined in the stringprep profile in Appendix A and Appendix B.
Note that the prohibited character tables listed in the Appendix A and
-Appendix B may include some of the same characters listed in this
+Appendix B may include some of the same characters listed in this
appendix as well.
Symbol characters and other symbol like characters
.ti 0
Full Copyright Statement
-Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-This document and translations of it may be copied and furnished to
-others, and derivative works that comment on or otherwise explain it
-or assist in its implementation may be prepared, copied, published
-and distributed, in whole or in part, without restriction of any
-kind, provided that the above copyright notice and this paragraph are
-included on all such copies and derivative works. However, this
-document itself may not be modified in any way, such as by removing
-the copyright notice or references to the Internet Society or other
-Internet organizations, except as needed for the purpose of
-developing Internet standards in which case the procedures for
-copyrights defined in the Internet Standards process must be
-followed, or as required to translate it into languages other than
-English.
-
-The limited permissions granted above are perpetual and will not be
-revoked by the Internet Society or its successors or assigns.
-
-This document and the information contained herein is provided on an
-"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+Copyright (C) The Internet Society (2007).
+
+This document is subject to the rights, licenses and restrictions
+contained in BCP 78, and except as set forth therein, the authors
+retain all their rights.
+
+This document and the information contained herein are provided on an
+"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
projects / crypto.git / blobdiff