From 4b8b073ff0762ef7bc9ff64dfa1fefbc4d38bd2c Mon Sep 17 00:00:00 2001 From: Pekka Riikonen Date: Mon, 16 Jun 2003 18:19:23 +0000 Subject: [PATCH] updates. --- doc/draft-riikonen-silc-commands-05.nroff | 275 ++++++++++++--------- doc/draft-riikonen-silc-pp-07.nroff | 277 ++++++++++++---------- 2 files changed, 315 insertions(+), 237 deletions(-) diff --git a/doc/draft-riikonen-silc-commands-05.nroff b/doc/draft-riikonen-silc-commands-05.nroff index 47850f33..c3a68d32 100644 --- a/doc/draft-riikonen-silc-commands-05.nroff +++ b/doc/draft-riikonen-silc-commands-05.nroff @@ -8,7 +8,7 @@ .ds RF FORMFEED[Page %] .ds CF .ds LH Internet Draft -.ds RH XXX +.ds RH 20 June 2003 .ds CH .na .hy 0 @@ -16,8 +16,8 @@ .nf Network Working Group P. Riikonen Internet-Draft -draft-riikonen-silc-commands-05.txt XXX -Expires: XXX +draft-riikonen-silc-commands-05.txt 20 June 2003 +Expires: 20 December 2003 .in 3 @@ -28,24 +28,24 @@ SILC Commands .ti 0 Status of this Memo -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. +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. -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 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 +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt -The list of Internet-Draft Shadow Directories can be accessed at -http://www.ietf.org/shadow.html +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html -The distribution of this memo is unlimited. +The distribution of this memo is unlimited. .ti 0 @@ -82,6 +82,7 @@ Table of Contents 5 References .................................................... 49 6 Author's Address .............................................. 51 Appendix A ...................................................... 51 +Full Copyright Statement ........................................ 53 .ti 0 @@ -105,7 +106,7 @@ command reply messages. .ti 0 1.1 Requirements Terminology -The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, +The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. @@ -124,7 +125,7 @@ The number of maximum arguments are defined with each command separately. The Command Argument Payload is described in [SILC2]. Every command defines specific number for each argument. Currently, -they are defined in ascending order; first argument has number one +they are defined in ascending order; first argument has number one (1), second has number two (2) and so on. This number is set into the Argument Type field in the Command Argument Payload. This makes it possible to send the arguments in free order as the number MUST be @@ -138,14 +139,14 @@ before the actual argument. .in 6 Example: Arguments: (1) (2) .in 3 - + Every command replies with Status Payload. This payload tells the sender of the command whether the command was completed successfully or whether there was an error. If error occurred the payload includes the -error type. In the next section the Status Payload is not described -as it is common to all commands and has been described here. Commands -MAY reply with other arguments as well. These arguments are command +error type. In the next section the Status Payload is not described +as it is common to all commands and has been described here. Commands +MAY reply with other arguments as well. These arguments are command specific and are described in the next section. Example command: @@ -182,7 +183,7 @@ only the first and third arguments are mandatory. The numbers in the parentheses have the same meaning as in the upper command sending specification. -Every command reply with , it is mandatory +Every command reply with , it is mandatory argument for all command replies and for this reason it is not described in the command reply descriptions. @@ -252,7 +253,7 @@ List of all defined commands in SILC follows. down by defining the server name of the nickname. The is 32 bit MSB first order integer. - It is also possible to search the user by Client ID. If the + It is also possible to search the user by Client ID. If the is provided server MUST use it as the search value instead of the . One of the arguments MUST be given. It is also possible to define multiple Client ID's to search @@ -261,7 +262,7 @@ List of all defined commands in SILC follows. To prevent miss-use of this command wildcards in the nickname or in the server name are not permitted. It is not allowed - to request all users on some server. The WHOIS requests MUST + to request all users on some server. The WHOIS requests MUST be based on explicit nickname request. The WHOIS request MUST be always sent to the router by server @@ -280,10 +281,10 @@ List of all defined commands in SILC follows. Reply messages to the command: Max Arguments: 11 - Arguments: (1) (2) - (3) [@] (4) - (5) (6) [] + Arguments: (1) (2) + (3) [@] (4) + (5) (6) [] (7) [] (8) [] (9) [] (10) @@ -296,7 +297,7 @@ List of all defined commands in SILC follows. STATUS_LIST_END in the last reply to indicate the end of the list. If there are only one reply the status is set to normal STATUS_OK. If multiple Client IDs was requested then each found - and unfound client must cause successful or error reply, + and unfound client MUST cause successful or error reply, respectively. The command replies include the Client ID of the nickname, @@ -346,16 +347,16 @@ List of all defined commands in SILC follows. Arguments: (1) [@] (2) [] Whowas. This command is used to query history information about - specific user. The user may be requested by their nickname and + specific user. The user may be requested by their nickname and server name. The query may find multiple matching users as there are no unique nicknames in the SILC. The option may be given to narrow down the number of accepted results. If this is not defined there are no limit of accepted results. The query - may also be narrowed down by defining the server name of the + may also be narrowed down by defining the server name of the nickname. The is 32 bit MSB first order integer. To prevent miss-use of this command wildcards in the nickname - or in the server name are not permitted. The WHOWAS requests MUST + or in the server name are not permitted. The WHOWAS requests MUST be based on specific nickname request. The WHOWAS request MUST be always sent to the router by server @@ -371,8 +372,8 @@ List of all defined commands in SILC follows. This command may reply with several command reply messages to form a list of results. In this case the status payload will include - STATUS_LIST_START status in the first reply and STATUS_LIST_END in - the last reply to indicate the end of the list. If there are only + STATUS_LIST_START status in the first reply and STATUS_LIST_END in + the last reply to indicate the end of the list. If there are only one reply the status is set to normal STATUS_OK. The command replies with nickname and user name and host name. @@ -408,7 +409,7 @@ List of all defined commands in SILC follows. It is also possible to search the entity by its ID. If the is provided server must use it as the search value - instead of the entity's name. One of the arguments must be given. + instead of the entity's name. One of the arguments MUST be given. It is also possible to define multiple ID Payloads to search multiple entities sending only one IDENTIFY command. In this case the ID Payloads are appended as normal arguments. The type of the @@ -435,8 +436,8 @@ List of all defined commands in SILC follows. This command may reply with several command reply messages to form a list of results. In this case the status payload will include - STATUS_LIST_START status in the first reply and STATUS_LIST_END in - the last reply to indicate the end of the list. If there are only + STATUS_LIST_START status in the first reply and STATUS_LIST_END in + the last reply to indicate the end of the list. If there are only one reply the status is set to normal STATUS_OK. If multiple Client IDs was requested then each found and unfound client must cause successful or error reply, respectively. @@ -477,14 +478,14 @@ List of all defined commands in SILC follows. Arguments: (1) Set/change nickname. This command is used to set nickname for - user. Nickname MUST NOT include any whitespaces (` '), - non-printable characters, commas (`,'), '@', '!' or any wildcard + user. Nickname MUST NOT include any whitespaces (` '), + non-printable characters, commas (`,'), '@', '!' or any wildcard characters. When nickname is changed new Client ID is generated. Server MUST distribute SILC_NOTIFY_TYPE_NICK_CHANGE to local clients on the channels (if any) the client is joined on. Then it MUST send - SILC_NOTIFY_TYPE_NICK_CHANGE notify to its primary route to + SILC_NOTIFY_TYPE_NICK_CHANGE notify to its primary route to notify about nickname and Client ID change. Reply messages to the command: @@ -532,8 +533,8 @@ List of all defined commands in SILC follows. This command may reply with several command reply messages to form a list of results. In this case the status payload will include - STATUS_LIST_START status in the first reply and STATUS_LIST_END in - the last reply to indicate the end of the list. If there are only + STATUS_LIST_START status in the first reply and STATUS_LIST_END in + the last reply to indicate the end of the list. If there are only one reply the status is set to normal STATUS_OK. This command replies with Channel ID, name and the topic of the @@ -571,7 +572,7 @@ List of all defined commands in SILC follows. Reply messages to the command: Max Arguments: 2 - Arguments: (1) (2) + Arguments: (1) (2) (3) [] The command may reply with the topic of the channel if it is @@ -711,10 +712,10 @@ List of all defined commands in SILC follows. SILC_NOTIFY_TYPE_KILLED to all channels the client has joined. The packet MUST NOT be sent to the killed client on the channels. Then, the router MUST send the same notify type to its primary - router. Finally, the router MUST send the same notify type - directly to the client which was killed. The killed client MUST - also be removed from the invite lists of joined channels if it - is explicitly added in the invite lists. + router. Finally, the router MUST send the same notify type + destined directly to the client which was killed. The killed + client MUST also be removed from the invite lists of joined + channels if it is explicitly added in the invite lists. Normal client killing by authentication: @@ -758,7 +759,7 @@ List of all defined commands in SILC follows. the requested server. If the is specified the server information if fetched - by the provided Server ID. One of the arguments must always be + by the provided Server ID. One of the arguments MUST always be present. Reply messages to the command: @@ -799,7 +800,7 @@ List of all defined commands in SILC follows. Arguments: (1) (2) (3) [] - This command replies with the Server ID of the server and + This command replies with the Server ID of the server and optional statistics structure which includes 32 bit MSB first ordered integer values to represent various statistical information. The structure is as follows: @@ -907,10 +908,11 @@ List of all defined commands in SILC follows. 14 SILC_COMMAND_JOIN - Max Arguments: 6 - Arguments: (1) (2) - (3) [] (4) [] - (5) [] (6) [] + Max Arguments: 7 + Arguments: (1) (2) + (3) [] (4) [] + (5) [] (6) [] + (7) [] Join to channel/create new channel. This command is used to join to a channel. If the channel does not exist the channel is @@ -937,7 +939,7 @@ List of all defined commands in SILC follows. The is Authentication Payload providing the authentication for gaining founder privileges on the channel when joining the channel. The client may provide this if it - knows that it is the founder of the channel and that the + knows that it is the founder of the channel and that the SILC_CMODE_FOUNDER_AUTH mode is set on the channel. The server MUST verify whether the client is able to gain the founder privileges the same way as the client had given the @@ -946,6 +948,21 @@ List of all defined commands in SILC follows. privileges could not be gained. The hash function used with the MUST be sha1. + If the is present and the channel mode + SILC_CMODE_CHANNEL_AUTH is set the server MUST verify the + with channel public key(s). If public key that + can verify does not exist on the channel public + key list the client MUST NOT be allowed to join the channel. + Because more than one public key may be set on channel the + Authentication Payload's Public Data field + MUST include an indication of the public key to be used. The + first 20 bytes of the Public Data field MUST be SHA-1 digest of + the public key that must be used in verification. Rest of the + Public Data field are set as defined in [SILC1]. This way server + can determine from the digest whether that public key exist on the + channel and then use that key in verification. The hash function + used with MUST be sha1. + The server MUST check whether the user is allowed to join to the requested channel. Various modes set to the channel affect the ability of the user to join the channel. These conditions @@ -957,8 +974,10 @@ List of all defined commands in SILC follows. o The Client ID/nickname/username/host name/public key MUST NOT match any active bans. - o The correct passphrase MUST be provided if passphrase - is set to the channel. + o The correct passphrase MUST be provided if passphrase + is set to the channel, and/or digital signature verification + with channel public key MUST be successful if public keys + has been set to the channel. o The user count limit, if set, MUST NOT be reached. @@ -970,7 +989,7 @@ List of all defined commands in SILC follows. Reply messages to the command: Max Arguments: 15 - Arguments: (1) (2) + Arguments: (1) (2) (3) (4) (5) (6) (7) [] (8) [] @@ -983,9 +1002,9 @@ List of all defined commands in SILC follows. client, channel ID of the channel and topic of the channel if it exists. The is the Client ID which was joined to the channel. It also replies with the channel mode mask - which tells all the modes set on the channel. If the - channel is created the mode mask is zero (0). If ban mask - and/or invite list is set they are sent as well. + which tells all the modes set on the channel. If the channel + is created the mode mask is zero (0) and is 0x01. + If ban mask and/or invite list is set they are sent as well. The , and are the clients currently on the channel and their modes on the @@ -1223,11 +1242,12 @@ List of all defined commands in SILC follows. 17 SILC_COMMAND_CMODE - Max Arguments: 8 + Max Arguments: 10 Arguments: (1) (2) [] (3) [] (4) [] (5) [] (6) [] (7) [] (8) [] + (9) [] (10) [] This command is used by client to set or change channel flags on a channel. Channel has several modes that set various properties @@ -1256,12 +1276,9 @@ List of all defined commands in SILC follows. with indication that the channel is private. Also, client on private channel will no be detected to be on the channel as the channel is not shown in the client's - currently joined channel list. Channel founder and + currently joined channel list. Channel founder and channel operator MAY set/unset this mode. - Typical implementation would use [+|-]p on user interface - to set/unset this mode. - 0x00000002 SILC_CMODE_SECRET @@ -1271,9 +1288,6 @@ List of all defined commands in SILC follows. Channel founder and channel operator MAY set/unset this mode. - Typical implementation would use [+|-]s on user interface - to set/unset this mode. - 0x00000004 SILC_CMODE_PRIVKEY @@ -1302,9 +1316,6 @@ List of all defined commands in SILC follows. key to all clients on the channel which will be used thereafter. - Typical implementation would use [+|-]k on user interface - to set/unset this mode. - 0x00000008 SILC_CMODE_INVITE @@ -1312,9 +1323,6 @@ List of all defined commands in SILC follows. channel only if it is invited to the channel. Channel founder and channel operator MAY set/unset this mode. - Typical implementation would use [+|-]i on user interface - to set/unset this mode. - 0x00000010 SILC_CMODE_TOPIC @@ -1324,9 +1332,6 @@ List of all defined commands in SILC follows. is set. Channel founder and channel operator MAY set/ unset this mode. - Typical implementation would use [+|-]t on user interface - to set/unset this mode. - 0x00000020 SILC_CMODE_ULIMIT @@ -1336,9 +1341,6 @@ List of all defined commands in SILC follows. unset the limit. The argument is the number of limited users. - Typical implementation would use [+|-]l on user interface - to set/unset this mode. - 0x00000040 SILC_CMODE_PASSPHRASE @@ -1350,22 +1352,16 @@ List of all defined commands in SILC follows. the passphrase. The argument is the set passphrase. - Typical implementation would use [+|-]a on user interface - to set/unset this mode. - 0x00000080 SILC_CMODE_CIPHER Sets specific cipher to be used to protect channel traffic. The argument is the requested cipher. When set or unset the server must re-generate new - channel key. Only channel founder MAY set the cipher of + channel key. Only channel founder MAY set the cipher of the channel. When unset the new key is generated using default cipher for the channel. - Typical implementation would use [+|-]c on user interface - to set/unset this mode. - 0x00000100 SILC_CMODE_HMAC @@ -1373,14 +1369,11 @@ List of all defined commands in SILC follows. channel message. The argument is the requested hmac. Only channel founder may set the hmac of the channel. - Typical implementation would use [+|-]h on user interface - to set/unset this mode. - 0x00000200 SILC_CMODE_FOUNDER_AUTH Channel founder may set this mode to be able to regain - channel founder rights even if the client leaves the + channel founder rights even if the client leaves the channel. The is the Authentication Payload consisting of the public key authentication method and the digital signature for that method. The passphrase or NONE @@ -1419,9 +1412,6 @@ List of all defined commands in SILC follows. many channels a user can own and how long they remain persistent. - Typical implementation would use [+|-]f on user interface - to set/unset this mode. - 0x00000400 SILC_CMODE_SILENCE_USERS @@ -1443,6 +1433,29 @@ List of all defined commands in SILC follows. mode is set. Only channel founder may set/unset this mode. + 0x00001000 SILC_CMODE_CHANNEL_AUTH + + When this mode is set the channel has one or more public keys + or certificates set, and ability to join the channel requires + a client to provide digital signature that can be successfully + verified with one of the channel public keys. This mode is + equivalent to the SILC_MODE_PASSPHRASE except that digital + signatures are used to gain access to the channel. Both + modes MAY be set at the same time. Channel founder may set + and unset this mode. + + To add one public key to channel this mode is set and the + argument includes 0x00 value, and the is the public key. To remove one public key from + channel public key list the includes 0x01 value + and is the public key to be removed. To + remove all public keys at once this mode is unset. An + implementation MAY limit the number of public keys that can + be set on the channel. This mode MUST NOT be set if is not present when the mode is set for the first + time. + + To make the mode system work, client MUST keep the channel mode mask locally so that the mode setting and unsetting would work without problems. The client receives the initial channel mode @@ -1611,7 +1624,7 @@ List of all defined commands in SILC follows. 19 SILC_COMMAND_KICK Max Arguments: 3 - Arguments: (1) (2) + Arguments: (1) (2) (3) [] This command is used by channel operators to remove a client from @@ -1647,7 +1660,6 @@ List of all defined commands in SILC follows. - 20 SILC_COMMAND_BAN Max Arguments: 3 @@ -1849,7 +1861,7 @@ List of all defined commands in SILC follows. Arguments: (1) This command is used by client to leave a channel the client is - joined to. + joined to. When leaving channel the server MUST send the notify type SILC_NOTIFY_TYPE_LEAVE to its primary router and to the channel. @@ -1882,13 +1894,13 @@ List of all defined commands in SILC follows. Arguments: (1) [] (2) [] This command is used to list user names currently on the requested - channel; either the argument or the . + channel; either the argument or the . One of these arguments must be present. The server MUST resolve the joined clients and reply with a lists of users on the channel and with list of user modes on the channel. If the requested channel is a private or secret channel, this - command MUST NOT send the list of users, except if the sender is + command MUST NOT send the list of users, except if the sender is on the channel, or the sender is a server. Otherwise, error is returned to the sender. @@ -1901,10 +1913,10 @@ List of all defined commands in SILC follows. This command replies with the Channel ID of the requested channel Client ID list of the users on the channel and list of their modes. - The Client ID list has Client ID's of all users in the list. The + The Client ID list has Client ID's of all users in the list. The is formed by adding Client ID's one after another. The is formed by adding client's user modes on - the channel one after another (4 bytes (32 bits) each). The of length of 4 bytes (32 bits), tells the number of entries in the lists. Both lists MUST have equal number of entries. @@ -2003,7 +2015,6 @@ List of all defined commands in SILC follows. - 28 - 199 Currently undefined commands. @@ -2015,7 +2026,7 @@ List of all defined commands in SILC follows. in this document. - 255 SILC_COMMAND_MAX + 255 SILC_COMMAND_MAX Reserved command. This must not be sent. .in 3 @@ -2068,7 +2079,7 @@ o If there is single error, then Status field includes ignored (and set to zero value). o If there will be multiple successful command replies - then Status field includes SILC_STATUS_LIST_START, + then Status field includes SILC_STATUS_LIST_START, SILC_STATUS_LIST_ITEM or SILC_STATUS_LIST_END value, and Error field is set to SILC_STATUS_OK. @@ -2221,7 +2232,7 @@ List of all defined status types: 24 SILC_STATUS_ERR_NICKNAME_IN_USE - "Nickname already exists". Nickname created could not be + "Nickname already exists". Nickname created could not be registered because number of same nicknames were already set to maximum. This is not expected to happen in real life but is possible to occur. @@ -2269,7 +2280,7 @@ List of all defined status types: 33 SILC_STATUS_ERR_BAD_PASSWORD - "Cannot join channel. Incorrect password". Password provided for + "Cannot join channel. Incorrect password". Password provided for channel were not accepted. 34 SILC_STATUS_ERR_CHANNEL_IS_FULL @@ -2299,12 +2310,12 @@ List of all defined status types: 39 SILC_STATUS_ERR_NO_CHANNEL_PRIV - "Permission denied. You are not channel operator". Command may + "Permission denied. You are not channel operator". Command may be executed only by channel operator. 40 SILC_STATUS_ERR_NO_CHANNEL_FOPRIV - "Permission denied. You are not channel founder". Command may + "Permission denied. You are not channel founder". Command may be executed only by channel operator. 41 SILC_STATUS_ERR_NO_SERVER_PRIV @@ -2329,7 +2340,7 @@ List of all defined status types: 45 SILC_STATUS_ERR_AUTH_FAILED - "Authentication failed". The authentication data sent as + "Authentication failed". The authentication data sent as argument were wrong and thus authentication failed. 46 SILC_STATUS_ERR_UNKOWN_ALGORITHM @@ -2407,7 +2418,7 @@ security of this protocol. [SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft, May 2002. -[SILC3] Riikonen, P., "SILC Key Exchange and Authentication +[SILC3] Riikonen, P., "SILC Key Exchange and Authentication Protocols", Internet Draft, May 2002. [IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol", @@ -2425,7 +2436,7 @@ security of this protocol. [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000. -[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", +[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet Draft. [PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440, @@ -2434,7 +2445,7 @@ security of this protocol. [SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693, September 1999. -[PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key +[PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile", RFC 2459, January 1999. @@ -2481,16 +2492,14 @@ Finland EMail: priikone@iki.fi -This Internet-Draft expires XXX - .ti 0 Appendix A This appendix defines the usage of the argument in -the SILC_COMMAND_WHOIS command. The attributes are defined in [ATTRS], +the SILC_COMMAND_WHOIS command. The attributes are defined in [ATTRS], and may be used to request additional information about the user. Since -the information that may be requested using the attributes is something +the information that may be requested using the attributes is something that server cannot deliver to the sender, it is possible to send the WHOIS command directly to the destination client whom will then provide the requested attributes. This requires the servers to relay the WHOIS @@ -2547,3 +2556,33 @@ reply en route to the original sender MAY also cache the information. The client which receives the command reply to the WHOIS command SHOULD verify the ATTRIBUTE_USER_DIGITAL_SIGNATURE and the ATTRIBUTE_SERVER_DIGITAL_SIGNATURE if they are provided. + + +.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. diff --git a/doc/draft-riikonen-silc-pp-07.nroff b/doc/draft-riikonen-silc-pp-07.nroff index 11a2b678..2bf4a71a 100644 --- a/doc/draft-riikonen-silc-pp-07.nroff +++ b/doc/draft-riikonen-silc-pp-07.nroff @@ -8,7 +8,7 @@ .ds RF FORMFEED[Page %] .ds CF .ds LH Internet Draft -.ds RH XXX +.ds RH 20 June 2003 .ds CH .na .hy 0 @@ -16,8 +16,8 @@ .nf Network Working Group P. Riikonen Internet-Draft -draft-riikonen-silc-pp-07.txt XXX -Expires: XXX +draft-riikonen-silc-pp-07.txt 20 June 2003 +Expires: 20 December 2003 .in 3 @@ -28,24 +28,24 @@ SILC Packet Protocol .ti 0 Status of this Memo -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. +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. -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 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 +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt -The list of Internet-Draft Shadow Directories can be accessed at -http://www.ietf.org/shadow.html +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html -The distribution of this memo is unlimited. +The distribution of this memo is unlimited. .ti 0 @@ -104,22 +104,23 @@ Table of Contents 2.3.20 Key Agreement Payload .............................. 43 2.3.21 Resume Router Payload .............................. 44 2.3.22 File Transfer Payload .............................. 45 - 2.3.23 Resume Client Payload .............................. 46 - 2.4 SILC ID Types ............................................. 47 - 2.5 Packet Encryption And Decryption .......................... 48 - 2.5.1 Normal Packet Encryption And Decryption ............. 48 - 2.5.2 Channel Message Encryption And Decryption ........... 49 - 2.5.3 Private Message Encryption And Decryption ........... 50 - 2.6 Packet MAC Generation ..................................... 50 - 2.7 Packet Padding Generation ................................. 51 - 2.8 Packet Compression ........................................ 52 - 2.9 Packet Sending ............................................ 52 - 2.10 Packet Reception ......................................... 52 - 2.11 Packet Routing ........................................... 53 - 2.12 Packet Broadcasting ...................................... 54 -3 Security Considerations ....................................... 55 -4 References .................................................... 55 -5 Author's Address .............................................. 56 + 2.3.23 Resume Client Payload .............................. 47 + 2.4 SILC ID Types ............................................. 48 + 2.5 Packet Encryption And Decryption .......................... 49 + 2.5.1 Normal Packet Encryption And Decryption ............. 49 + 2.5.2 Channel Message Encryption And Decryption ........... 50 + 2.5.3 Private Message Encryption And Decryption ........... 51 + 2.6 Packet MAC Generation ..................................... 51 + 2.7 Packet Padding Generation ................................. 52 + 2.8 Packet Compression ........................................ 53 + 2.9 Packet Sending ............................................ 53 + 2.10 Packet Reception ......................................... 53 + 2.11 Packet Routing ........................................... 54 + 2.12 Packet Broadcasting ...................................... 55 +3 Security Considerations ....................................... 56 +4 References .................................................... 56 +5 Author's Address .............................................. 57 +6 Full Copyright Statement ...................................... 57 .ti 0 List of Figures @@ -178,7 +179,7 @@ packet. .ti 0 1.1 Requirements Terminology -The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, +The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. @@ -191,7 +192,7 @@ interpreted as described in [RFC2119]. SILC packets deliver messages from sender to receiver securely by encrypting important fields of the packet. The packet consists of -default SILC Packet Header, Padding, Packet Payload data, and, packet +default SILC Packet Header, Padding, Packet Payload data, and, packet MAC. The following diagram illustrates typical SILC packet. @@ -200,8 +201,8 @@ The following diagram illustrates typical SILC packet. .in 5 .nf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| n bytes | 1 - n bytes | n bytes | n bytes -| SILC Header | Padding | Data Payload | MAC +| n bytes | 1 - n bytes | n bytes | n bytes +| SILC Header | Padding | Data Payload | MAC - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .in 3 @@ -303,7 +304,7 @@ o Flags (1 byte) - Indicates flags to be used in packet List 0x02 - + Indicates that the packet consists of list of packet payloads indicated by the Packet Type field. The payloads are added one after the other. Note that @@ -318,11 +319,11 @@ o Flags (1 byte) - Indicates flags to be used in packet Marks the packet to be broadcasted. Client cannot send broadcast packet and normal server cannot send broadcast packet. Only router server may send broadcast - packet. The router receiving of packet with this flag + packet. The router receiving of packet with this flag set MUST send (broadcast) the packet to its primary route. If router has several router connections the packet may be sent only to the primary route. See - section 2.12 Packet Broadcasting for description of + section 2.12 Packet Broadcasting for description of packet broadcasting. @@ -338,7 +339,7 @@ o Flags (1 byte) - Indicates flags to be used in packet .in 3 -o Packet Type (1 byte) - Is the type of the packet. Receiver +o Packet Type (1 byte) - Is the type of the packet. Receiver uses this field to parse the packet. See section 2.3 SILC Packets for list of defined packet types. @@ -415,7 +416,7 @@ List of SILC Packet types are defined as follows. .in 1 0 SILC_PACKET_NONE - This type is reserved and it is never sent. + This type is reserved and it is never sent. 1 SILC_PACKET_DISCONNECT @@ -456,7 +457,7 @@ List of SILC Packet types are defined as follows. This packet is used to send notify message. The packet is usually sent between server and client, but also between server and router. Client MUST NOT send this packet. Server - MAY send this packet to channel as well when the packet is + MAY send this packet to channel as well when the packet is distributed to all clients on the channel. This packet MAY be sent as list. @@ -484,7 +485,7 @@ List of SILC Packet types are defined as follows. SILC_PACKET_CHANNEL_KEY packet. This packet MAY be sent to entity that is indirectly connected to the sender. - Payload of the packet: See section 2.3.9 Channel Message + Payload of the packet: See section 2.3.9 Channel Message Payload @@ -546,7 +547,7 @@ List of SILC Packet types are defined as follows. MAY be sent to entity that is indirectly connected to the sender. - Payload of the packet: See section 2.3.14 Command Reply + Payload of the packet: See section 2.3.14 Command Reply Payload and section 2.3.13 Command Payload @@ -555,7 +556,7 @@ List of SILC Packet types are defined as follows. 13 SILC_PACKET_KEY_EXCHANGE - This packet is used to start SILC Key Exchange Protocol, + This packet is used to start SILC Key Exchange Protocol, described in detail in [SILC3]. Payload of the packet: Payload of this packet is described @@ -587,8 +588,8 @@ List of SILC Packet types are defined as follows. 16 SILC_PACKET_CONNECTION_AUTH_REQUEST This packet is used to request an authentication method to - be used in the SILC Connection Authentication Protocol. If - initiator of the protocol does not know the mandatory + be used in the SILC Connection Authentication Protocol. If + initiator of the protocol does not know the mandatory authentication method this packet MAY be used to determine it. The party receiving this payload SHOULD respond with the same packet including the mandatory authentication method. @@ -627,8 +628,8 @@ List of SILC Packet types are defined as follows. 19 SILC_PACKET_NEW_CLIENT - This packet is used by client to register itself to the - SILC network. This is sent after key exchange and + This packet is used by client to register itself to the + SILC network. This is sent after key exchange and authentication protocols has been completed. Client sends various information about itself in this packet. @@ -638,7 +639,7 @@ List of SILC Packet types are defined as follows. 20 SILC_PACKET_NEW_SERVER This packet is used by server to register itself to the - SILC network. This is sent after key exchange and + SILC network. This is sent after key exchange and authentication protocols has been completed. Server sends this to the router it connected to, or, if router was connecting, to the connected router. Server sends its @@ -674,7 +675,7 @@ List of SILC Packet types are defined as follows. new keys must be used hereafter. This packet does not have a payload. - + 24 SILC_PACKET_HEARTBEAT This packet is used by clients, servers and routers to keep the @@ -685,7 +686,7 @@ List of SILC Packet types are defined as follows. 25 SILC_PACKET_KEY_AGREEMENT - This packet is used by clients to request key negotiation + This packet is used by clients to request key negotiation between another client in the SILC network. If the negotiation is started it is performed using the SKE protocol. The result of the negotiation, the secret key material, can be used for @@ -697,7 +698,7 @@ List of SILC Packet types are defined as follows. 26 SILC_PACKET_RESUME_ROUTER - This packet is used during backup router protocol when the + This packet is used during backup router protocol when the original primary router of the cell comes back online and wishes to resume the position as being the primary router of the cell. @@ -742,7 +743,7 @@ List of SILC Packet types are defined as follows. 255 SILC_PACKET_MAX - This type is reserved for future extensions and currently it + This type is reserved for future extensions and currently it MUST NOT be sent. .in 3 @@ -802,10 +803,10 @@ Figure 3: ID Payload .in 6 -o ID Type (2 bytes) - Indicates the type of the ID. See +o ID Type (2 bytes) - Indicates the type of the ID. See section 2.4 SILC ID Types for list of defined ID types. -o ID Length (2 bytes) - Length of the ID Data area not +o ID Length (2 bytes) - Length of the ID Data area not including the length of any other fields in the payload. o ID Data (variable length) - The actual ID data. The encoding @@ -843,15 +844,15 @@ Figure 4: Argument Payload .in 6 -o Payload Length (2 bytes) - Length of the Argument Data - field not including the length of any other field in the +o Payload Length (2 bytes) - Length of the Argument Data + field not including the length of any other field in the payload. -o Argument Type (1 byte) - Indicates the type of the argument. +o Argument Type (1 byte) - Indicates the type of the argument. 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 may be - associated with the command. By using this number the receiver + 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) value. @@ -980,8 +981,8 @@ Figure 7: Public Key Payload o Public Key Length (2 bytes) - The length of the Public Key (or certificate) field, not including any other field. -o Public Key Type (2 bytes) - The public key (or certificate) - type. This field indicates the type of the public key in +o Public Key Type (2 bytes) - The public key (or certificate) + type. This field indicates the type of the public key in the packet. See the [SILC3] for defined public key types. o Public Key (or certificate) (variable length) - The @@ -1062,7 +1063,7 @@ o Message Flags (2 bytes) - Includes the Message Flags of the 0x0010 SILC_MESSAGE_FLAG_REQUEST This is a generic request flag to send request - messages. A separate document should define any + messages. A separate document should define any payloads associated to this flag. 0x0020 SILC_MESSAGE_FLAG_SIGNED @@ -1105,7 +1106,7 @@ o Message Flags (2 bytes) - Includes the Message Flags of the Private range for free use. o Message Length (2 bytes) - Indicates the length of the - Message Data field in the payload, not including any + Message Data field in the payload, not including any other field. o Message Data (variable length) - The actual message data. @@ -1349,7 +1350,7 @@ o Argument Nums (1 byte) - Indicates the number of Argument .in 3 The following list of currently defined notify types. The format for -notify arguments is same as in SILC commands described in [SILC4]. +notify arguments is same as in SILC commands described in [SILC4]. Note that all IDs sent in arguments are sent inside ID Payload. Also note that all passphrases that may be sent inside arguments MUST be UTF-8 [RFC2279] encoded. Also note that all public keys or certificates @@ -1373,7 +1374,7 @@ sent inside arguments are actually Public Key Payloads. Sent when an client is invited to a channel. This is also sent when the invite list of the channel is changed. This notify type - is sent between routers and if an client was invited, to the + is sent between routers and if an client was invited, to the client as well. In this case the packet is destined to the client. Max Arguments: 5 @@ -1382,7 +1383,7 @@ sent inside arguments are actually Public Key Payloads. (5) [] The is the channel. The is the name - of the channel and is provided because the client which receives + 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 . The is the Client ID which invited the client to the channel. The @@ -1477,10 +1478,11 @@ sent inside arguments are actually Public Key Payloads. to the clients which are joined on the channel which mode was changed. - Max Arguments: 6 + Max Arguments: 8 Arguments: (1) (2) - (3) [] (4) <[hmac>] + (3) [] (4) <[hmac>] (5) [] (6) [] + (7) [] (8) [] The is the ID (usually Client ID but it can be Server ID as well when the router is enforcing channel mode @@ -1497,6 +1499,15 @@ sent inside arguments are actually Public Key Payloads. reclaim the channel founder rights back for the channel on any server in the network. + The and is used to add or remove + channel public key from the channel. To add one public key to + channel the SILC_CMODE_CHANNEL_AUTH mode is set and the + argument includes 0x00 value, and the is the + public key. To remove one public key from channel public key list + the includes 0x01 value and is the + public key to be removed. If the SILC_CMODE_CHANNEL_AUTH mode is + unset (and was set earlier) all public keys are removed at once. + 8 SILC_NOTIFY_TYPE_CUMODE_CHANGE @@ -1559,7 +1570,7 @@ sent inside arguments are actually Public Key Payloads. The is the server's ID. The rest of the arguments are the Client IDs of the clients which are coming from this server and are thus quitting the SILC network also. If the - maximum number of arguments are reached another + maximum number of arguments are reached another SILC_NOTIFY_TYPE_SERVER_SIGNOFF notify packet MUST be sent. When this notify packet is sent between routers the Client ID's MAY be omitted. Server receiving the Client ID's in the payload @@ -1588,7 +1599,7 @@ sent inside arguments are actually Public Key Payloads. 13 SILC_NOTIFY_TYPE_KILLED - Sent when a client has been killed from the network. This is sent + Sent when a client has been killed from the network. This is sent also to the client which was killed from the network. The client which was killed from the network MUST be removed from the network. This notify type is destined directly to the client which was @@ -1685,7 +1696,7 @@ sent inside arguments are actually Public Key Payloads. Notify types starting from 16384 are reserved for private notify message types. -Router server which receives SILC_NOTIFY_TYPE_SIGNOFF, +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 check whether someone in the local cell is watching the nickname @@ -1738,7 +1749,7 @@ 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. +channel specific key. Hence the requirement of the padding. The packet MUST be made multiple by eight (8) or by the block size of the cipher, which ever is larger. @@ -1788,7 +1799,7 @@ Channel key SHOULD expire periodically, say, in one hour, in which case new channel key is created and distributed. The payload may only be sent with SILC_PACKET_CHANNEL_KEY packet. -It MUST NOT be sent in any other packet type. The following diagram +It MUST NOT be sent in any other packet type. The following diagram represents the Channel Key Payload. @@ -1870,8 +1881,8 @@ between the sender client and the receiving client MUST decrypt the packet and always re-encrypt it with the session key of the next receiver of the packet. See section Client To Client in [SILC1]. -When private key is used to protect the message, servers between -the sender and the receiver needs not to decrypt/re-encrypt the +When private key is used to protect the message, servers between +the sender and the receiver needs not to decrypt/re-encrypt the packet. Section Client To Client in [SILC1] gives example of this scheme as well. @@ -1900,8 +1911,8 @@ MUST NOT send this payload at any time. After sending this payload the sender of private messages must set the Private Message Key flag into SILC Packet Header. -The payload may only be sent with SILC_PACKET_PRIVATE_MESSAGE_KEY -packet. It MUST NOT be sent in any other packet type. The following +The payload may only be sent with SILC_PACKET_PRIVATE_MESSAGE_KEY +packet. It MUST NOT be sent in any other packet type. The following diagram represents the Private Message Key Payload. @@ -1940,8 +1951,8 @@ Figure 16: Private Message Key Payload .in 6 -o Private Message Key Length (2 bytes) - Indicates the length - of the Private Message Key field in the payload, not including +o Private Message Key Length (2 bytes) - Indicates the length + of the Private Message Key field in the payload, not including any other field. o Private Message Key (variable length) - The actual private @@ -1991,17 +2002,17 @@ Figure 17: Command Payload .in 6 -o Payload Length (2 bytes) - Length of the entire command - payload including any command argument payloads associated +o Payload Length (2 bytes) - Length of the entire command + payload including any command argument payloads associated with this payload. -o SILC Command (1 byte) - Indicates the SILC command. This MUST - be set to non-zero value. If zero (0) value is found in this +o SILC Command (1 byte) - Indicates the SILC command. This MUST + be set to non-zero value. If zero (0) value is found in this field the packet MUST be discarded. o Arguments Num (1 byte) - Indicates the number of arguments associated with the command. If there are no arguments this - field is set to zero (0). The arguments MUST follow the + field is set to zero (0). The arguments MUST follow the command payload. See section 2.3.2.2 for definition of the Argument Payload. @@ -2040,7 +2051,7 @@ SILC commands, their arguments and their reply messages. 2.3.15 Connection Auth Request Payload Client MAY send this payload to server to request the authentication -method that must be used in authentication protocol. If client knows +method that must be used in authentication protocol. If client knows this information beforehand this payload is not necessary to be sent. Server performing authentication with another server MAY also send this payload to request the authentication method. If the connecting @@ -2049,12 +2060,12 @@ to be sent. Server receiving this request SHOULD reply with same payload sending the mandatory authentication method. Algorithms that may be required -to be used by the authentication method are the ones already +to be used by the authentication method are the ones already established by the SILC Key Exchange protocol. See section Key Exchange Start Payload in [SILC3] for detailed information. The payload may only be sent with SILC_PACKET_CONNECTION_AUTH_REQUEST -packet. It MUST NOT be sent in any other packet type. The following +packet. It MUST NOT be sent in any other packet type. The following diagram represents the Connection Auth Request Payload. @@ -2093,11 +2104,11 @@ o Authentication Method (2 bytes) - Indicates the authentication If any other type is found in this field the packet MUST be discarded and the authentication MUST be failed. If this - payload is sent as request to receive the mandatory + payload is sent as request to receive the mandatory authentication method this field MUST be set to zero (0), - indicating that receiver should send the mandatory + indicating that receiver should send the mandatory authentication method. The receiver sending this payload - to the requesting party, MAY also set this field to zero (0) + to the requesting party, MAY also set this field to zero (0) to indicate that authentication is not required. In this case authentication protocol still MUST be started but server is most likely to respond with SILC_PACKET_SUCCESS @@ -2110,7 +2121,7 @@ o Authentication Method (2 bytes) - Indicates the authentication .ti 0 2.3.16 New ID Payload -New ID Payload is a multipurpose payload. It is used to send newly +New ID Payload is a multipurpose payload. It is used to send newly created ID's from clients and servers. When client connects to server and registers itself to the server by sending SILC_PACKET_NEW_CLIENT packet, server replies with this packet by sending the created ID for @@ -2120,11 +2131,11 @@ This payload is also used when server tells its router that new client has registered to the SILC network. In this case the server sends the Client ID of the client to the router. Similarly when router distributes information to other routers about the client in the SILC -network this payload is used. +network this payload is used. Also, when server connects to router, router use this payload to inform -other routers about new server in the SILC network. However, every -server (or router) creates their own ID's thus the ID distributed by +other routers about new server in the SILC network. However, every +server (or router) creates their own ID's thus the ID distributed by this payload is not created by the distributor in this case. Servers create their own ID's. Server registers itself to the network by sending SILC_PACKET_NEW_SERVER to the router it connected to. The case @@ -2143,15 +2154,15 @@ The packet use generic ID Payload as New ID Payload. See section 2.3.17 New Client Payload When client is connected to the server, keys has been exchanged and -connection has been authenticated, client MUST register itself to the -server. Client's first packet after key exchange and authentication +connection has been authenticated, client MUST register itself to the +server. Client's first packet after key exchange and authentication protocols must be SILC_PACKET_NEW_CLIENT. This payload tells server all the relevant information about the connected user. Server creates a new client ID for the client when received this payload and sends it to the client in New ID Payload. This payload sends username and real name of the user on the remote host -which is connected to the SILC server with SILC client. The server +which is connected to the SILC server with SILC client. The server creates the client ID according the information sent in this payload. The nickname of the user becomes the nickname sent in this payload. @@ -2281,7 +2292,7 @@ is performed outside the SILC network. The server and router MUST NOT send this payload. The sender MAY tell the receiver of this payload the hostname and the -port where the SKE protocol is running in the sender's end. The +port where the SKE protocol is running in the sender's end. The receiver MAY then initiate the SKE negotiation with the sender. The sender MAY also optionally not to include the hostname and the port of its SKE protocol. In this case the receiver MAY reply to the @@ -2289,7 +2300,7 @@ request by sending the same payload filled with the receiver's hostname and the port where the SKE protocol is running. The sender MAY then initiate the SKE negotiation with the receiver. -This payload may be sent with SILC_PACKET_KEY_AGREEMENT and +This payload may be sent with SILC_PACKET_KEY_AGREEMENT and SILC_PACKET_FTP packet types. It MUST NOT be sent in any other packet types. The following diagram represents the Key Agreement Payload. @@ -2324,7 +2335,7 @@ o Hostname (variable length) - The hostname or IP address where o Port (4 bytes) - The port where the SKE protocol is bound. The sender MAY fill this field when sending the payload. If - the receiver sends this payload as reply to the request it + the receiver sends this payload as reply to the request it MUST fill this field. This is a 32 bit MSB first order value. .in 3 @@ -2346,11 +2357,11 @@ used. The payload may only be sent with SILC_PACKET_RESUME_ROUTER packet. It MUST NOT be sent in any other packet type. The following diagram represents the Resume Router Payload. - + .in 21 .nf 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -2431,7 +2442,7 @@ o Type (1 byte) - Indicates the type of the file transfer o Data (variable length) - Arbitrary file transfer data. The contents and encoding of this field is dependent of the usage of this payload and the type of the file transfer protocol. - When this payload is used to perform the Key Agreement + When this payload is used to perform the Key Agreement protocol, this field include the Key Agreement Payload, as defined in the section 2.3.20 Key Agreement Payload. When this payload is used to send the actual file transfer @@ -2450,7 +2461,7 @@ connection to the client is lost but the client remains as valid client in the network. The client is able to resume the session back by sending this packet and including the old Client ID, and an Authentication Payload [SILC1] which the server use to verify with -the detached client's public key. This also implies that the +the detached client's public key. This also implies that the mandatory authentication method is public key authentication. Server or router that receives this from the client also sends this, @@ -2579,7 +2590,7 @@ be verified from the entire ciphertext. 2.5.2 Channel Message Encryption And Decryption Channel Messages (Channel Message Payload) are always encrypted with -the channel specific key. However, the SILC Packet header is not +the channel specific key. However, the SILC Packet header is not encrypted with that key. As in normal case, the header is encrypted with the key of the next receiver of the packet, who ever that might be. Note that in this case the encrypted data area is not touched @@ -2716,9 +2727,9 @@ data area MUST already be multiple by the block size thus in this case the padding is calculated only for SILC Packet Header, not for any other area of the packet. The same algorithm works in this case as well, except that the `packet length' is now the SILC Packet Header -length. +length. -The padding MUST be random data, preferably, generated by +The padding MUST be random data, preferably, generated by cryptographically strong random number generator for each packet separately. @@ -2768,7 +2779,7 @@ header of the packet includes any bad fields the packet MUST be discarded. See above sections on the decryption process of the received packet. - + The receiver MUST also check that the ID's in the header are valid ID's. Unsupported ID types or malformed ID's MUST cause packet rejection. The padding on the reception is always ignored. @@ -2825,7 +2836,7 @@ directly connected to the server. Routers form a ring in the SILC network. However, routers may have other direct connections to other routers in the network too. This can cause interesting routing problems in the network. Since the network is a ring, -the packets usually should be routed into clock-wise direction, or if it +the packets usually should be routed into clock-wise direction, or if it cannot be used then always counter clock-wise (primary route) direction. Problems may arise when a faster direct route exists and router is routing a channel message. Currently channel messages must be routed either @@ -2834,7 +2845,7 @@ The SILC protocol should have a shortest path discovery protocol, and some existing routing protocol, that can handle a ring network with other direct routes inside the ring (so called hybrid ring-mesh topology), MAY be defined to be used with the SILC protocol. Additional -specifications MAY be written on the subject to permeate this +specifications MAY be written on the subject to permeate this specification. @@ -2870,8 +2881,8 @@ routers may keep these informations up to date. Security is central to the design of this protocol, and these security considerations permeate the specification. Common security considerations -such as keeping private keys truly private and using adequate lengths for -symmetric and asymmetric keys must be followed in order to maintain the +such as keeping private keys truly private and using adequate lengths for +symmetric and asymmetric keys must be followed in order to maintain the security of this protocol. @@ -2881,7 +2892,7 @@ security of this protocol. [SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC), Protocol Specification", Internet Draft, May 2002. -[SILC3] Riikonen, P., "SILC Key Exchange and Authentication +[SILC3] Riikonen, P., "SILC Key Exchange and Authentication Protocols", Internet Draft, May 2002. [SILC4] Riikonen, P., "SILC Commands", Internet Draft, May 2002. @@ -2901,7 +2912,7 @@ security of this protocol. [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000. -[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", +[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet Draft. [PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440, @@ -2910,7 +2921,7 @@ security of this protocol. [SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693, September 1999. -[PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key +[PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile", RFC 2459, January 1999. @@ -2956,4 +2967,32 @@ Finland EMail: priikone@iki.fi -This Internet-Draft expires XXX + +.ti 0 +6 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. -- 2.43.0