.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH XXX
+.ds RH 20 June 2003
.ds CH
.na
.hy 0
.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
.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
5 References .................................................... 49
6 Author's Address .............................................. 51
Appendix A ...................................................... 51
+Full Copyright Statement ........................................ 53
.ti 0
.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].
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
.in 6
Example: Arguments: (1) <nickname> (2) <username@host>
.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:
in the parentheses have the same meaning as in the upper
command sending specification.
-Every command reply with <Status Payload>, it is mandatory
+Every command reply with <Status Payload>, it is mandatory
argument for all command replies and for this reason it is not
described in the command reply descriptions.
down by defining the server name of the nickname. The <count> 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
<Client ID> is provided server MUST use it as the search value
instead of the <nickname>. One of the arguments MUST be given.
It is also possible to define multiple Client ID's to search
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
Reply messages to the command:
Max Arguments: 11
- Arguments: (1) <Status Payload> (2) <Client ID>
- (3) <nickname>[@<server>] (4) <username@host>
- (5) <real name> (6) [<Channel Payload
- list>]
+ Arguments: (1) <Status Payload> (2) <Client ID>
+ (3) <nickname>[@<server>] (4) <username@host>
+ (5) <real name> (6) [<Channel Payload
+ list>]
(7) [<user mode>] (8) [<idle time>]
(9) [<fingerprint>] (10) <channel user
mode list>
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,
Arguments: (1) <nickname>[@<server>] (2) [<count>]
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 <count> 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 <count> 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
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.
It is also possible to search the entity by its ID. If the
<ID Payload> 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
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.
Arguments: (1) <nickname>
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:
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
Reply messages to the command:
Max Arguments: 2
- Arguments: (1) <Status Payload> (2) <Channel ID>
+ Arguments: (1) <Status Payload> (2) <Channel ID>
(3) [<topic>]
The command may reply with the topic of the channel if it is
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:
the requested server.
If the <Server ID> 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:
Arguments: (1) <Status Payload> (2) <Server ID>
(3) [<statistics structure>]
- 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:
14 SILC_COMMAND_JOIN
- Max Arguments: 6
- Arguments: (1) <channel> (2) <Client ID>
- (3) [<passphrase>] (4) [<cipher>]
- (5) [<hmac>] (6) [<founder auth>]
+ Max Arguments: 7
+ Arguments: (1) <channel> (2) <Client ID>
+ (3) [<passphrase>] (4) [<cipher>]
+ (5) [<hmac>] (6) [<founder auth>]
+ (7) [<channel auth>]
Join to channel/create new channel. This command is used to
join to a channel. If the channel does not exist the channel is
The <founder auth> 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
privileges could not be gained. The hash function used with
the <founder payload> MUST be sha1.
+ If the <channel auth> is present and the channel mode
+ SILC_CMODE_CHANNEL_AUTH is set the server MUST verify the
+ <channel auth> with channel public key(s). If public key that
+ can verify <channel auth> 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
+ <channel auth> 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 <channel auth> 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
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.
Reply messages to the command:
Max Arguments: 15
- Arguments: (1) <Status Payload> (2) <channel>
+ Arguments: (1) <Status Payload> (2) <channel>
(3) <Channel ID> (4) <Client ID>
(5) <channel mode mask> (6) <created>
(7) [<Channel Key Payload>] (8) [<ban list>]
client, channel ID of the channel and topic of the channel
if it exists. The <Client ID> 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 <created> is 0x01.
+ If ban mask and/or invite list is set they are sent as well.
The <list count>, <Client ID list> and <client mode list> are
the clients currently on the channel and their modes on the
17 SILC_COMMAND_CMODE
- Max Arguments: 8
+ Max Arguments: 10
Arguments: (1) <Channel ID> (2) [<channel mode mask>]
(3) [<user limit>] (4) [<passphrase>]
(5) [<cipher>] (6) [<hmac>]
(7) [<auth payload>] (8) [<founder pubkey>]
+ (9) [<add | del>] (10) [<channel pubkey>]
This command is used by client to set or change channel flags on
a channel. Channel has several modes that set various properties
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
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
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
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
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
unset the limit. The <user limit> argument is the
number of limited users.
- Typical implementation would use [+|-]l on user interface
- to set/unset this mode.
-
0x00000040 SILC_CMODE_PASSPHRASE
the passphrase. The <passphrase> 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 <cipher> 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
channel message. The <hmac> 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 <auth payload> is the Authentication Payload
consisting of the public key authentication method and the
digital signature for that method. The passphrase or NONE
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
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
+ <add | del> argument includes 0x00 value, and the <channel
+ pubkey> is the public key. To remove one public key from
+ channel public key list the <add | del> includes 0x01 value
+ and <channel pubkey> 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 <channel
+ pubkey> 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
19 SILC_COMMAND_KICK
Max Arguments: 3
- Arguments: (1) <Channel ID> (2) <Client ID>
+ Arguments: (1) <Channel ID> (2) <Client ID>
(3) [<comment>]
This command is used by channel operators to remove a client from
-
20 SILC_COMMAND_BAN
Max Arguments: 3
Arguments: (1) <Channel ID>
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.
Arguments: (1) [<Channel ID>] (2) [<channel name>]
This command is used to list user names currently on the requested
- channel; either the argument <Channel ID> or the <channel name>.
+ channel; either the argument <Channel ID> or the <channel name>.
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.
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
<Client ID list> is formed by adding Client ID's one after another.
The <client mode list> is formed by adding client's user modes on
- the channel one after another (4 bytes (32 bits) each). The <list
+ the channel one after another (4 bytes (32 bits) each). The <list
count> of length of 4 bytes (32 bits), tells the number of entries
in the lists. Both lists MUST have equal number of entries.
-
28 - 199
Currently undefined commands.
in this document.
- 255 SILC_COMMAND_MAX
+ 255 SILC_COMMAND_MAX
Reserved command. This must not be sent.
.in 3
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.
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.
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
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
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
[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",
[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,
[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.
EMail: priikone@iki.fi
-This Internet-Draft expires XXX
-
.ti 0
Appendix A
This appendix defines the usage of the <Requested Attributes> 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
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.
.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH XXX
+.ds RH 20 June 2003
.ds CH
.na
.hy 0
.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
.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
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
.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].
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.
.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
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
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.
.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.
.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
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.
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
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
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
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.
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.
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
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
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
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.
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
.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
.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.
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
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
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.
.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
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
(5) [<invite list>]
The <Channel ID> is the channel. The <channel name> is the name
- of the channel and is provided because the client which receives
+ of the channel and is provided because the client which receives
this notify packet may not have a way to resolve the name of the
channel from the <Channel ID>. The <sender Client ID> is the
Client ID which invited the client to the channel. The <add | del>
to the clients which are joined on the channel which mode was
changed.
- Max Arguments: 6
+ Max Arguments: 8
Arguments: (1) <ID Payload> (2) <mode mask>
- (3) [<cipher>] (4) <[hmac>]
+ (3) [<cipher>] (4) <[hmac>]
(5) [<passphrase>] (6) [<founder public key>]
+ (7) [<add | del>] (8) [<channel public key>]
The <ID Payload> is the ID (usually Client ID but it can be
Server ID as well when the router is enforcing channel mode
reclaim the channel founder rights back for the channel on any
server in the network.
+ The <add | del> and <channel public key> 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 <add | del>
+ argument includes 0x00 value, and the <channel public key> is the
+ public key. To remove one public key from channel public key list
+ the <add | del> includes 0x01 value and <channel pubkey> 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
The <Server ID> 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
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
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
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.
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.
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.
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.
.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
.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.
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
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.
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
.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
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
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.
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
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.
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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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,
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
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.
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.
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
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.
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.
[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.
[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,
[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.
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.
projects / silc.git / commitdiff