From 4c062a8c8d0c125ecaca3525de5870f088a0302d Mon Sep 17 00:00:00 2001 From: Pekka Riikonen Date: Tue, 14 May 2002 07:19:59 +0000 Subject: [PATCH] updates. --- doc/draft-riikonen-presence-attrs-00.nroff | 2 +- doc/draft-riikonen-silc-commands-03.nroff | 8 +- ...raft-riikonen-silc-flags-payloads-00.nroff | 36 ++-- doc/draft-riikonen-silc-ke-auth-05.nroff | 33 ++-- doc/draft-riikonen-silc-pp-05.nroff | 154 ++++++++---------- doc/draft-riikonen-silc-spec-05.nroff | 130 +++++++-------- 6 files changed, 171 insertions(+), 192 deletions(-) diff --git a/doc/draft-riikonen-presence-attrs-00.nroff b/doc/draft-riikonen-presence-attrs-00.nroff index 22d439ca..c97c1994 100644 --- a/doc/draft-riikonen-presence-attrs-00.nroff +++ b/doc/draft-riikonen-presence-attrs-00.nroff @@ -417,7 +417,7 @@ x ATTRIBUTE_SERVER_DIGITAL_SIGNATURE 6 Author's Address Pekka Riikonen -Snellmanninkatu 34 A 15 +Snellmaninkatu 34 A 15 70100 Kuopio Finland diff --git a/doc/draft-riikonen-silc-commands-03.nroff b/doc/draft-riikonen-silc-commands-03.nroff index 89ec6b11..7a071b27 100644 --- a/doc/draft-riikonen-silc-commands-03.nroff +++ b/doc/draft-riikonen-silc-commands-03.nroff @@ -308,7 +308,7 @@ List of all defined commands in SILC follows. The server also returns client's user mode, idle time, and the fingerprint of the client's public key. The is the binary hash digest of the public key. The fingerprint MUST NOT - be sent if the server has not verified the proof of posession of + be sent if the server has not verified the proof of possession of the corresponding private key. Server can do this during the SILC Key Exchange protocol. The is SHA1 digest. @@ -1182,7 +1182,7 @@ List of all defined commands in SILC follows. of a channel. Modes may be masked together by ORing them thus having several modes set. The is the ID of the target channel. The client changing channel mode MUST be on - the same channel and poses sufficient privileges to be able to + the same channel and posses sufficient privileges to be able to change the mode. When the mode is changed SILC_NOTIFY_TYPE_CMODE_CHANGE notify @@ -1431,7 +1431,7 @@ List of all defined commands in SILC follows. The is the ID of the target channel. The is OR'ed mask of modes. The is the target client. The client changing channel user modes MUST be on the same channel - as the target client and poses sufficient privileges to be able to + as the target client and posses sufficient privileges to be able to change the mode. When the mode is changed SILC_NOTIFY_TYPE_CUMODE_CHANGE notify @@ -2373,7 +2373,7 @@ security of this protocol. .nf Pekka Riikonen -Snellmanninkatu 34 A 15 +Snellmaninkatu 34 A 15 70100 Kuopio Finland diff --git a/doc/draft-riikonen-silc-flags-payloads-00.nroff b/doc/draft-riikonen-silc-flags-payloads-00.nroff index a827ccfc..fb9d84b6 100644 --- a/doc/draft-riikonen-silc-flags-payloads-00.nroff +++ b/doc/draft-riikonen-silc-flags-payloads-00.nroff @@ -8,7 +8,7 @@ .ds RF FORMFEED[Page %] .ds CF .ds LH Internet Draft -.ds RH XXX +.ds RH 15 May 2002 .ds CH .na .hy 0 @@ -16,12 +16,12 @@ .nf Network Working Group P. Riikonen Internet-Draft -draft-riikonen-flags-payloads-00.txt XXX -Expires: XXX +draft-riikonen-flags-payloads-00.txt 15 May 2002 +Expires: 15 November 2002 .in 3 -.ce 3 +.ce 2 SILC Message Flag Payloads @@ -71,17 +71,17 @@ payloads. Table of Contents .nf -1 Introduction .................................................. x - 1.1 Requirements Terminology .................................. x -2 SILC Message Flags ............................................ x -3 SILC Message Flag Payloads .................................... x - 3.1 SILC_MESSAGE_FLAG_REQUEST ................................. x - 3.2 SILC_MESSAGE_FLAG_REPLY ................................... x - 3.3 SILC_MESSAGE_FLAG_SIGNED .................................. x - 3.4 SILC_MESSAGE_FLAG_DATA .................................... x -4 Security Considerations ....................................... x -5 References .................................................... x -6 Author's Address .............................................. x +1 Introduction .................................................. 2 + 1.1 Requirements Terminology .................................. 2 +2 SILC Message Flags ............................................ 2 +3 SILC Message Flag Payloads .................................... 3 + 3.1 SILC_MESSAGE_FLAG_REQUEST ................................. 3 + 3.2 SILC_MESSAGE_FLAG_REPLY ................................... 3 + 3.3 SILC_MESSAGE_FLAG_SIGNED .................................. 4 + 3.4 SILC_MESSAGE_FLAG_DATA .................................... 4 +4 Security Considerations ....................................... 5 +5 References .................................................... 5 +6 Author's Address .............................................. 6 .ti 0 @@ -140,7 +140,7 @@ bits, so there is a limited number of flags available. For this reason a flag that defines some generic way of sending any kind of data as a message, and that it can be easily interpreted at the receiver's end is important. For this reason the flag SILC_MESSAGE_FLAG_DATA was added to -the protocol which can represent any data. This memo desribes how this +the protocol which can represent any data. This memo describe how this flag is used and how the associated payload is constructed and processed. This memo also describes payloads for all the other flags that can have associated payloads. @@ -295,10 +295,10 @@ support S/MIME may be desired in some implementations. 6 Author's Address Pekka Riikonen -Snellmanninkatu 34 A 15 +Snellmaninkatu 34 A 15 70100 Kuopio Finland EMail: priikone@iki.fi -This Internet-Draft expires XXX +This Internet-Draft expires 15 November 2002 diff --git a/doc/draft-riikonen-silc-ke-auth-05.nroff b/doc/draft-riikonen-silc-ke-auth-05.nroff index 247e99d5..6b768a3d 100644 --- a/doc/draft-riikonen-silc-ke-auth-05.nroff +++ b/doc/draft-riikonen-silc-ke-auth-05.nroff @@ -8,7 +8,7 @@ .ds RF FORMFEED[Page %] .ds CF .ds LH Internet-Draft -.ds RH XXX +.ds RH 15 May 2002 .ds CH .na .hy 0 @@ -16,8 +16,8 @@ .nf Network Working Group P. Riikonen Internet-Draft -draft-riikonen-silc-ke-auth-05.txt XXX -Expires: XXX +draft-riikonen-silc-ke-auth-05.txt 15 May 2002 +Expires: 15 November 2002 .in 3 @@ -81,7 +81,7 @@ Table of Contents 2.1.2 Key Exchange Payload ................................ 8 2.2 Key Exchange Procedure .................................... 10 2.3 Processing the Key Material ............................... 12 - 2.4 SILC Key Exchange Groups .................................. 13 + 2.4 SILC Key Exchange Groups .................................. 14 2.4.1 diffie-hellman-group1 ............................... 14 2.4.2 diffie-hellman-group2 ............................... 14 2.5 Key Exchange Status Types ................................. 15 @@ -89,10 +89,10 @@ Table of Contents 3.1 Connection Auth Payload ................................... 18 3.2 Connection Authentication Types ........................... 19 3.2.1 Passphrase Authentication ........................... 19 - 3.2.2 Public Key Authentication ........................... 19 + 3.2.2 Public Key Authentication ........................... 20 3.3 Connection Authentication Status Types .................... 20 -4 Security Considerations ....................................... 20 -5 References .................................................... 20 +4 Security Considerations ....................................... 21 +5 References .................................................... 21 6 Author's Address .............................................. 22 @@ -121,7 +121,7 @@ and the OAKLEY Key Determination protocol. The SILC Connection Authentication protocol provides user level authentication used when creating connections in SILC network. The protocol is transparent to the authentication data which means that it -can be used to authenticate the user with, for example, pass phrase +can be used to authenticate the user with, for example, passphrase (pre-shared- secret) or public key (and certificate). The basis of secure SILC session requires strong and secure key exchange @@ -223,7 +223,7 @@ returned to the original sender by the responder. Following diagram represents the Key Exchange Start Payload. The lists mentioned below are always comma (`,') separated and the list MUST NOT -include spaces (` '). +include white spaces (` '). .in 5 @@ -410,7 +410,7 @@ flag may be omitted. However, if the connection authentication protocol for the connecting entity is not based on public key authentication (it is based on passphrase) then the Mutual Authentication flag SHOULD be enabled. This way the connecting entity has to provide proof of -posession of the private key for the public key it will provide in +possession of the private key for the public key it will provide in SILC Key Exchange protocol. When performing re-key with PFS selected this is the only payload that @@ -728,6 +728,9 @@ This group was taken from the OAKLEY specification. The length of this group is 1536 bits. This is OPTIONAL group. The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }. + + + Its decimal value is .in 6 @@ -984,6 +987,7 @@ possible to approximate the length of the password from the encrypted packet. + .ti 0 3.2.2 Public Key Authentication @@ -1026,8 +1030,6 @@ SILC_AUTH_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet. The length of status is 32 bits (4 bytes). The following status types are defined: - - 0 SILC_AUTH_OK Protocol was executed successfully. @@ -1038,6 +1040,8 @@ are defined: Authentication failed. + + .ti 0 4 Security Considerations @@ -1048,6 +1052,7 @@ symmetric and asymmetric keys must be followed in order to maintain the security of this protocol. + .ti 0 5 References @@ -1121,10 +1126,10 @@ security of this protocol. .nf Pekka Riikonen -Snellmanninkatu 34 A 15 +Snellmaninkatu 34 A 15 70100 Kuopio Finland EMail: priikone@iki.fi -This Internet-Draft expires XXX +This Internet-Draft expires 15 November 2002 diff --git a/doc/draft-riikonen-silc-pp-05.nroff b/doc/draft-riikonen-silc-pp-05.nroff index f3445fd0..63db37b6 100644 --- a/doc/draft-riikonen-silc-pp-05.nroff +++ b/doc/draft-riikonen-silc-pp-05.nroff @@ -8,7 +8,7 @@ .ds RF FORMFEED[Page %] .ds CF .ds LH Internet Draft -.ds RH XXX +.ds RH 15 May 2002 .ds CH .na .hy 0 @@ -16,8 +16,8 @@ .nf Network Working Group P. Riikonen Internet-Draft -draft-riikonen-silc-pp-05.txt XXX -Expires: XXX +draft-riikonen-silc-pp-05.txt 15 May 2002 +Expires: 15 November 2002 .in 3 @@ -75,49 +75,49 @@ Table of Contents 2 SILC Packet Protocol .......................................... 4 2.1 SILC Packet ............................................... 4 2.2 SILC Packet Header ........................................ 5 - 2.3 SILC Packet Types ......................................... 7 - 2.3.1 SILC Packet Payloads ................................ 16 - 2.3.2 Generic payloads .................................... 16 + 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 ............................. 18 - 2.3.2.4 Public Key Payload .......................... 19 + 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 ..................................... 21 + 2.3.5 Failure Payload ..................................... 22 2.3.6 Reject Payload ...................................... 22 - 2.3.7 Notify Payload ...................................... 22 - 2.3.8 Error Payload ....................................... 28 - 2.3.9 Channel Message Payload ............................. 29 - 2.3.10 Channel Key Payload ................................ 32 - 2.3.11 Private Message Payload ............................ 34 - 2.3.12 Private Message Key Payload ........................ 35 - 2.3.13 Command Payload .................................... 37 - 2.3.14 Command Reply Payload .............................. 38 - 2.3.15 Connection Auth Request Payload .................... 38 - 2.3.16 New ID Payload ..................................... 39 - 2.3.17 New Client Payload ................................. 40 - 2.3.18 New Server Payload ................................. 41 - 2.3.19 New Channel Payload ................................ 42 - 2.3.20 Key Agreement Payload .............................. 43 - 2.3.21 Resume Router Payload .............................. 44 - 2.3.22 File Transfer Payload .............................. 44 - 2.3.23 Resume Client Payload .............................. XXXXXX - 2.4 SILC ID Types ............................................. 46 - 2.5 Packet Encryption And Decryption .......................... 46 - 2.5.1 Normal Packet Encryption And Decryption ............. 46 - 2.5.2 Channel Message Encryption And Decryption ........... 47 - 2.5.3 Private Message Encryption And Decryption ........... 48 - 2.6 Packet MAC Generation ..................................... 48 - 2.7 Packet Padding Generation ................................. 49 - 2.8 Packet Compression ........................................ 50 - 2.9 Packet Sending ............................................ 50 - 2.10 Packet Reception ......................................... 51 - 2.11 Packet Routing ........................................... 51 - 2.12 Packet Broadcasting ...................................... 52 -3 Security Considerations ....................................... 53 -4 References .................................................... 53 -5 Author's Address .............................................. 54 + 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 .ti 0 List of Figures @@ -160,7 +160,7 @@ the contents of the packets. The protocol provides secure binary packet protocol that assures that the contents of the packets are secured and authenticated. The packet protocol is designed to be compact to avoid unnecessary overhead as much as possible. This makes the SILC suitable -also in environment of low bandwith requirements such as mobile networks. +also in environment of low bandwidth requirements such as mobile networks. All packet payloads can also be compressed to further reduce the size of the packets. @@ -335,7 +335,7 @@ o Flags (1 byte) - Indicates flags to be used in packet Marks that the payload of the packet is compressed. The sender of the packet marks this flag when it compresses the payload, and any server or router - en route to the receipient MUST NOT unset this flag. + en route to the recipient MUST NOT unset this flag. See section 2.8 Packet Compression for description of packet compressing. @@ -472,6 +472,7 @@ List of SILC Packet types are defined as follows. Payload of the packet: See section 2.3.7 Notify Payload. + 6 SILC_PACKET_ERROR This packet is sent when an error occurs. Server MAY @@ -761,6 +762,8 @@ List of SILC Packet types are defined as follows. 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 @@ -812,8 +815,6 @@ List of SILC Packet types are defined as follows. not be defined by this document. - - 255 SILC_PACKET_MAX This type is reserved for future extensions and currently it @@ -858,6 +859,11 @@ thus this payload provides a way to send variable length ID's. The following diagram represents the ID Payload. + + + + + .in 5 .nf 1 2 3 @@ -896,12 +902,6 @@ needs 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. - - - - - - The following diagram represents the Argument Payload. .in 5 @@ -946,17 +946,6 @@ its name, the Channel ID and a mode. The following diagram represents the Channel Payload. - - - - - - - - - - - .in 5 .nf 1 2 3 @@ -1227,6 +1216,8 @@ 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. + + .in 6 0 SILC_NOTIFY_TYPE_NONE @@ -1323,6 +1314,8 @@ UTF-8 [RFC2279] encoded. 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 @@ -1369,6 +1362,8 @@ UTF-8 [RFC2279] encoded. server in the network. + + 8 SILC_NOTIFY_TYPE_CUMODE_CHANGE Sent when user mode on channel has changed. This type MUST be @@ -1415,6 +1410,8 @@ UTF-8 [RFC2279] encoded. Channel ID> is the new one that MUST replace the old one. + + 11 SILC_NOTIFY_TYPE_SERVER_SIGNOFF Sent when server quits SILC network. Those clients from this @@ -1552,13 +1549,15 @@ message types. Router server which receives SILC_NOTIFY_TYPE_SIGNOFF, SILC_NOTIFY_TYPE_SERVER_SIGNOFF, SILC_NOTIFY_TYPE_KILLED, SILC_NOTIFY_TYPE_NICK_CHANGE and SILC_NOTIFY_TYPE_UMODE_CHANGE -MUST chech whether someone in the local cell is watching the nickname +MUST check whether someone in the local cell is watching the nickname the client has, and send the SILC_NOTIFY_TYPE_WATCH notify to the watcher, unless the client in case has the SILC_UMODE_REJECT_WATCHING user mode set. If the watcher client and the client that was watched is same the notify SHOULD NOT be sent. + + .ti 0 2.3.8 Error Payload @@ -1884,12 +1883,6 @@ 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 @@ -2145,6 +2138,8 @@ o Authentication Method (2 bytes) - Indicates the authentication .in 3 + + .ti 0 2.3.16 New ID Payload @@ -2204,17 +2199,6 @@ MUST NOT be sent in any other packet type. The following diagram represents the New Client Payload. - - - - - - - - - - - .in 5 .nf 1 2 3 @@ -2268,8 +2252,6 @@ represents the New Server Payload. - - .in 5 .nf 1 2 3 @@ -2506,7 +2488,7 @@ mandatory authentication method is public key authentication. Server or router that receives this from the client also sends this, without the Authentication Payload, to routers in the network so that they know the detached client has resumed. Refer to the [SILC1] for -detailed description how the detaching and resuming prodecure is +detailed description how the detaching and resuming procedure is performed. The payload may only be sent with SILC_PACKET_RESUME CLIENT packet. It @@ -2848,7 +2830,7 @@ routed to the primary route (default route). However, there are some issues when routing channel messages to group of users. Routers are responsible of routing the channel message to other routers, local servers and local clients as well. Routers MUST -send the channel message to only one router in the network, preferrably +send the channel message to only one router in the network, preferably to the shortest route to reach the channel users. The message can be routed into either upstream or downstream. After the message is sent to a router in the network it MUST NOT be sent to any other router in @@ -2996,10 +2978,10 @@ security of this protocol. .nf Pekka Riikonen -Snellmanninkatu 34 A 15 +Snellmaninkatu 34 A 15 70100 Kuopio Finland EMail: priikone@iki.fi -This Internet-Draft expires XXX +This Internet-Draft expires 15 November 2002 diff --git a/doc/draft-riikonen-silc-spec-05.nroff b/doc/draft-riikonen-silc-spec-05.nroff index 417a73ae..e14cd826 100644 --- a/doc/draft-riikonen-silc-spec-05.nroff +++ b/doc/draft-riikonen-silc-spec-05.nroff @@ -8,7 +8,7 @@ .ds RF FORMFEED[Page %] .ds CF .ds LH Internet Draft -.ds RH XXX +.ds RH 15 May 2002 .ds CH .na .hy 0 @@ -16,8 +16,8 @@ .nf Network Working Group P. Riikonen Internet-Draft -draft-riikonen-silc-spec-05.txt XXX -Expires: XXX +draft-riikonen-silc-spec-05.txt 15 May 2002 +Expires: 15 November 2002 .in 3 @@ -86,49 +86,49 @@ Table of Contents 3.2.2 Server ID ........................................... 11 3.2.3 SILC Server Ports ................................... 12 3.3 Router .................................................... 12 - 3.3.1 Router's Local ID List .............................. 12 + 3.3.1 Router's Local ID List .............................. 13 3.3.2 Router's Global ID List ............................. 13 3.3.3 Router's Server ID .................................. 14 3.4 Channels .................................................. 14 - 3.4.1 Channel ID .......................................... 16 + 3.4.1 Channel ID .......................................... 15 3.5 Operators ................................................. 16 3.6 SILC Commands ............................................. 16 3.7 SILC Packets .............................................. 17 3.8 Packet Encryption ......................................... 17 - 3.8.1 Determination of the Source and the Destination ..... 17 + 3.8.1 Determination of the Source and the Destination ..... 18 3.8.2 Client To Client .................................... 18 - 3.8.3 Client To Channel ................................... 19 + 3.8.3 Client To Channel ................................... 20 3.8.4 Server To Server .................................... 20 3.9 Key Exchange And Authentication ........................... 20 - 3.9.1 Authentication Payload .............................. 20 - 3.10 Algorithms ............................................... 22 - 3.10.1 Ciphers ............................................ 22 - 3.10.2 Public Key Algorithms .............................. 23 + 3.9.1 Authentication Payload .............................. 21 + 3.10 Algorithms ............................................... 23 + 3.10.1 Ciphers ............................................ 23 + 3.10.2 Public Key Algorithms .............................. 24 3.10.3 Hash Functions ..................................... 24 - 3.10.4 MAC Algorithms ..................................... 24 + 3.10.4 MAC Algorithms ..................................... 25 3.10.5 Compression Algorithms ............................. 25 - 3.11 SILC Public Key .......................................... 25 - 3.12 SILC Version Detection ................................... 27 + 3.11 SILC Public Key .......................................... 26 + 3.12 SILC Version Detection ................................... 28 3.13 Backup Routers ........................................... 28 - 3.13.1 Switching to Backup Router ......................... 29 - 3.13.2 Resuming Primary Router ............................ 30 - 3.13.3 Discussion on Backup Router Scheme ................. 32 -4 SILC Procedures ............................................... 33 - 4.1 Creating Client Connection ................................ 33 - 4.2 Creating Server Connection ................................ 34 - 4.2.1 Announcing Clients, Channels and Servers ............ 35 - 4.3 Joining to a Channel ...................................... 36 - 4.4 Channel Key Generation .................................... 37 - 4.5 Private Message Sending and Reception ..................... 38 - 4.6 Private Message Key Generation ............................ 38 - 4.7 Channel Message Sending and Reception ..................... 39 - 4.8 Session Key Regeneration .................................. 39 - 4.9 Command Sending and Reception ............................. 40 - 4.10 Closing Connection ....................................... 41 - 4.11 Detaching and Resuming a Session ......................... XXXXX -5 Security Considerations ....................................... 41 -6 References .................................................... 42 -7 Author's Address .............................................. 44 + 3.13.1 Switching to Backup Router ......................... 30 + 3.13.2 Resuming Primary Router ............................ 31 + 3.13.3 Discussion on Backup Router Scheme ................. 33 +4 SILC Procedures ............................................... 34 + 4.1 Creating Client Connection ................................ 34 + 4.2 Creating Server Connection ................................ 35 + 4.2.1 Announcing Clients, Channels and Servers ............ 36 + 4.3 Joining to a Channel ...................................... 37 + 4.4 Channel Key Generation .................................... 38 + 4.5 Private Message Sending and Reception ..................... 39 + 4.6 Private Message Key Generation ............................ 39 + 4.7 Channel Message Sending and Reception ..................... 40 + 4.8 Session Key Regeneration .................................. 40 + 4.9 Command Sending and Reception ............................. 41 + 4.10 Closing Connection ....................................... 42 + 4.11 Detaching and Resuming a Session ......................... 42 +5 Security Considerations ....................................... 44 +6 References .................................................... 45 +7 Author's Address .............................................. 47 @@ -152,7 +152,7 @@ network channel. SILC is IRC [IRC] like protocol, however, it is not equivalent to IRC and does not support IRC. Some of the SILC's features are not found in IRC but in traditional Instant Message (IM) protocols. SILC combines features from both of these chat protocol -styles, and SILC can be implemeneted as either IRC-like system or +styles, and SILC can be implemented as either IRC-like system or IM-like system. Strong cryptographic methods are used to protect SILC packets inside @@ -166,7 +166,7 @@ described in [SILC2] and should be read to fully comprehend this document and protocol. [SILC2] also describes the packet encryption and decryption in detail. The SILC Packet Protocol provides secured and authenticated packets, and the protocol is designed to be compact. -This makes SILC also suitable in environment of low bandwith +This makes SILC also suitable in environment of low bandwidth requirements such as mobile networks. All packet payloads in SILC can be also compressed. @@ -225,11 +225,6 @@ This, on the other hand, leads to cellular like network, where routers are in the center of the cell and servers are connected to the router. - - - - - The following diagram represents SILC network topology. .in 8 @@ -328,6 +323,9 @@ router routes the message to its primary route. The following diagram represents message sending between cells. + + + .in 16 .nf 1 --- S1 S4 --- 5 S2 --- 1 @@ -387,12 +385,6 @@ router in the network. Unless there is only two routers in the network must not routers use each other as their primary routes. The router connections in the network must form a ring. - - - - - - Example with three routers in the network: @@ -1528,7 +1520,7 @@ the first backup router as their primary route. Also, if any other router in the network is using the cell's primary router as its own primary router, it must also have passive connection to the cell's backup router. It too is prepared to switch to use the -backup router as its new primary router as soon as the orignal primary +backup router as its new primary router as soon as the original primary router becomes unresponsive. All of the parties of this protocol knows which one is the backup router @@ -1568,7 +1560,7 @@ replace the old connection to the primary router with first configured backup router. The backup router usually needs to do local modifications to its database in order to update all the information needed to maintain working routes. The backup router must understand that clients that -were orignated from the primary router are now originated from some of +were originated from the primary router are now originated from some of the existing server connections and must update them accordingly. It must also remove those clients that were owned by the primary router since those connections were lost when the primary router became @@ -1597,7 +1589,7 @@ normal manner defined later in this specification. 3.13.2 Resuming Primary Router Usually the primary router is unresponsive only a short period of time -and it is intended that the original router of the cell will reassume +and it is intended that the original router of the cell will resume its position as primary router when it comes back online. The backup router that is now acting as primary router of the cell must constantly try to connect to the original primary router of the cell. It is @@ -1703,7 +1695,7 @@ is defined in [SILC2]. 3.13.3 Discussion on Backup Router Scheme It is clear that this backup router support is not able to handle all -possible situations arrising in unreliable network environment. This +possible situations arising in unreliable network environment. This scheme for example does not handle situation when the router actually does not go offline but the network link goes down temporarily. It would require some intelligence to figure out when it is best time to switch @@ -2006,7 +1998,7 @@ If the sender has received earlier a private message from the receiver it should have cached the Client ID from the SILC Packet Header. If server receives a private message packet which includes invalid -destionation Client ID the server MUST send SILC_NOTIFY_TYPE_ERROR +destination Client ID the server MUST send SILC_NOTIFY_TYPE_ERROR notify to the client with error status indicating that such Client ID does not exist. @@ -2057,11 +2049,11 @@ distribute the message to all clients on the channel by sending the channel message destined explicitly to a client on the channel. If server receives a channel message packet which includes invalid -destionation Channel ID the server MUST send SILC_NOTIFY_TYPE_ERROR +destination Channel ID the server MUST send SILC_NOTIFY_TYPE_ERROR notify to the sender with error status indicating that such Channel ID does not exist. -See the [SILC2] for description of channel messege routing for router +See the [SILC2] for description of channel message routing for router servers, and channel message encryption and decryption process. @@ -2266,9 +2258,9 @@ on the security and the integrity of the servers and administrators that are running the service. It is recommended that some form of registration is required by the server and router administrator prior acceptance to the SILC Network. Even though, the SILC protocol is secure in a network -of mutual distrust between clients, servers, routers and adminstrators +of mutual distrust between clients, servers, routers and administrators of the servers, the client should be able to trust the servers they are -using if they whish to do so. +using if they wish to do so. 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 @@ -2278,20 +2270,20 @@ 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 full proof system and cannot secure from insecure environment; the -SILC servers and routers could very well be compromised. However, to -provide acceptable level of security and usability for end user the -protocol use many times session keys or other keys generated by the -servers to secure the messages. This is intentional design feature to -allow ease of use for end user. This way the network is still usable, -and remains encrypted even if the external means of distributing the -keys is not working. The implementation, however, may like to not -follow this design feature, and always negotiate the keys outside SILC -network. This is acceptable solution and many times recommended. The -implementation still must be able to work with the server generated keys. +not full proof system; the SILC servers and routers could very well be +compromised. However, to provide acceptable level of security and +usability for end user the protocol use many times session keys or other +keys generated by the servers to secure the messages. This is +intentional design feature to allow ease of use for end user. This way +the network is still usable, and remains encrypted even if the external +means of distributing the keys is not working. The implementation, +however, may like to not follow this design feature, and always negotiate +the keys outside SILC network. This is acceptable solution and many times +recommended. The implementation still must be able to work with the +server generated keys. If this is unacceptable for the client or end user, the private keys -negotiatied outside the SILC Network should always be used. In the end +negotiated outside the SILC Network should always be used. In the end it is always implementor's choice whether to negotiate private keys by default or whether to use the keys generated by the servers. @@ -2377,10 +2369,10 @@ should have a forum to discuss the cell management issues. .nf Pekka Riikonen -Snellmanninkatu 34 A 15 +Snellmaninkatu 34 A 15 70100 Kuopio Finland EMail: priikone@iki.fi -This Internet-Draft expires XXX +This Internet-Draft expires 15 November 2002 -- 2.24.0