.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH XXX
+.ds RH 15 May 2002
.ds CH
.na
.hy 0
.nf
Network Working Group P. Riikonen
Internet-Draft
-draft-riikonen-silc-pp-05.txt XXX
-Expires: XXX
+draft-riikonen-silc-pp-05.txt 15 May 2002
+Expires: 15 November 2002
.in 3
2 SILC Packet Protocol .......................................... 4
2.1 SILC Packet ............................................... 4
2.2 SILC Packet Header ........................................ 5
- 2.3 SILC Packet Types ......................................... 7
- 2.3.1 SILC Packet Payloads ................................ 16
- 2.3.2 Generic payloads .................................... 16
+ 2.3 SILC Packet Types ......................................... 8
+ 2.3.1 SILC Packet Payloads ................................ 17
+ 2.3.2 Generic payloads .................................... 17
2.3.2.1 ID Payload .................................. 17
2.3.2.2 Argument Payload ............................ 18
- 2.3.2.3 Channel Payload ............................. 18
- 2.3.2.4 Public Key Payload .......................... 19
+ 2.3.2.3 Channel Payload ............................. 19
+ 2.3.2.4 Public Key Payload .......................... 20
2.3.3 Disconnect Payload .................................. 20
2.3.4 Success Payload ..................................... 21
- 2.3.5 Failure Payload ..................................... 21
+ 2.3.5 Failure Payload ..................................... 22
2.3.6 Reject Payload ...................................... 22
- 2.3.7 Notify Payload ...................................... 22
- 2.3.8 Error Payload ....................................... 28
- 2.3.9 Channel Message Payload ............................. 29
- 2.3.10 Channel Key Payload ................................ 32
- 2.3.11 Private Message Payload ............................ 34
- 2.3.12 Private Message Key Payload ........................ 35
- 2.3.13 Command Payload .................................... 37
- 2.3.14 Command Reply Payload .............................. 38
- 2.3.15 Connection Auth Request Payload .................... 38
- 2.3.16 New ID Payload ..................................... 39
- 2.3.17 New Client Payload ................................. 40
- 2.3.18 New Server Payload ................................. 41
- 2.3.19 New Channel Payload ................................ 42
- 2.3.20 Key Agreement Payload .............................. 43
- 2.3.21 Resume Router Payload .............................. 44
- 2.3.22 File Transfer Payload .............................. 44
- 2.4 SILC ID Types ............................................. 46
- 2.5 Packet Encryption And Decryption .......................... 46
- 2.5.1 Normal Packet Encryption And Decryption ............. 46
- 2.5.2 Channel Message Encryption And Decryption ........... 47
- 2.5.3 Private Message Encryption And Decryption ........... 48
- 2.6 Packet MAC Generation ..................................... 48
- 2.7 Packet Padding Generation ................................. 49
- 2.8 Packet Compression ........................................ 50
- 2.9 Packet Sending ............................................ 50
- 2.10 Packet Reception ......................................... 51
- 2.11 Packet Routing ........................................... 51
- 2.12 Packet Broadcasting ...................................... 52
-3 Security Considerations ....................................... 53
-4 References .................................................... 53
-5 Author's Address .............................................. 54
+ 2.3.7 Notify Payload ...................................... 23
+ 2.3.8 Error Payload ....................................... 31
+ 2.3.9 Channel Message Payload ............................. 31
+ 2.3.10 Channel Key Payload ................................ 35
+ 2.3.11 Private Message Payload ............................ 36
+ 2.3.12 Private Message Key Payload ........................ 38
+ 2.3.13 Command Payload .................................... 39
+ 2.3.14 Command Reply Payload .............................. 40
+ 2.3.15 Connection Auth Request Payload .................... 40
+ 2.3.16 New ID Payload ..................................... 42
+ 2.3.17 New Client Payload ................................. 42
+ 2.3.18 New Server Payload ................................. 43
+ 2.3.19 New Channel Payload ................................ 44
+ 2.3.20 Key Agreement Payload .............................. 45
+ 2.3.21 Resume Router Payload .............................. 46
+ 2.3.22 File Transfer Payload .............................. 46
+ 2.3.23 Resume Client Payload .............................. 48
+ 2.4 SILC ID Types ............................................. 49
+ 2.5 Packet Encryption And Decryption .......................... 49
+ 2.5.1 Normal Packet Encryption And Decryption ............. 50
+ 2.5.2 Channel Message Encryption And Decryption ........... 50
+ 2.5.3 Private Message Encryption And Decryption ........... 51
+ 2.6 Packet MAC Generation ..................................... 52
+ 2.7 Packet Padding Generation ................................. 52
+ 2.8 Packet Compression ........................................ 53
+ 2.9 Packet Sending ............................................ 53
+ 2.10 Packet Reception ......................................... 54
+ 2.11 Packet Routing ........................................... 54
+ 2.12 Packet Broadcasting ...................................... 55
+3 Security Considerations ....................................... 56
+4 References .................................................... 56
+5 Author's Address .............................................. 58
.ti 0
List of Figures
Figure 7: Disconnect Payload
Figure 8: Success Payload
Figure 9: Failure Payload
-Figure 10: Reject Payload
+Figure 10: Reject Payload
Figure 11: Notify Payload
Figure 12: Error Payload
Figure 13: Channel Message Payload
Figure 21: Key Agreement Payload
Figure 22: Resume Router Payload
Figure 23: File Transfer Payload
+Figure 24: Resume Client Payload
.ti 0
protocol describes the packet types and packet payloads which defines
the contents of the packets. The protocol provides secure binary packet
protocol that assures that the contents of the packets are secured and
-authenticated.
+authenticated. The packet protocol is designed to be compact to avoid
+unnecessary overhead as much as possible. This makes the SILC suitable
+also in environment of low bandwidth requirements such as mobile networks.
+All packet payloads can also be compressed to further reduce the size
+of the packets.
The basis of SILC protocol relies in the SILC packets and it is with
out a doubt the most important part of the protocol. It is also probably
section 2.12 Packet Broadcasting for description of
packet broadcasting.
+
+ Compressed 0x08
+
+ Marks that the payload of the packet is compressed.
+ The sender of the packet marks this flag when it
+ compresses the payload, and any server or router
+ en route to the recipient MUST NOT unset this flag.
+ See section 2.8 Packet Compression for description of
+ packet compressing.
+
.in 3
Payload of the packet: See section 2.3.7 Notify Payload.
+
6 SILC_PACKET_ERROR
This packet is sent when an error occurs. Server MAY
Payload of the packet: See section 2.3.20 Key Agreement Payload
+
+
26 SILC_PACKET_RESUME_ROUTER
This packet is used during backup router protocol when the
Payload of the packet: See section 2.3.22 File Transfer Payload
- 28 - 199
+ 28 SILC_PACKET_RESUME_CLIENT
+
+ This packet is used to resume a client back to the network
+ after it has been detached. A client is able to detach from
+ the network but the client is still valid client in the network.
+ The client may then later resume its session back by sending
+ this packet to a server. Routers also use this packet to notify
+ other routers in the network that the detached client has resumed.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: See section 2.3.23 Resume Client Payload
+
+
+ 29 - 199
Currently undefined commands.
not be defined by this document.
-
-
255 SILC_PACKET_MAX
This type is reserved for future extensions and currently it
The following diagram represents the ID Payload.
+
+
+
+
+
.in 5
.nf
1 2 3
the packet payload needing the arguments. Incorrect amount of argument
payloads MUST cause rejection of the packet.
-
-
-
-
-
-
The following diagram represents the Argument Payload.
.in 5
The following diagram represents the Channel Payload.
-
-
-
-
-
-
-
-
-
-
-
.in 5
.nf
1 2 3
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Status | |
++-+-+-+-+-+-+-+-+ +
| |
~ Disconnect Message ~
| |
.ce
Figure 7: Disconnect Payload
-
-
-
.in 6
-o Disconnect Message (variable length) - Human readable
- reason of the disconnection.
+o Status (1 byte) - Indicates the Status Type, defined in [SILC3]
+ for the reason of disconnection.
+
+o Disconnect Message (variable length) - Human readable UTF-8
+ encoded string indicating reason of the disconnection. This
+ MAY be omitted.
.in 3
The following list of currently defined notify types. The format for
notify arguments is same as in SILC commands described in [SILC4].
-Also, all ID's sent in arguments are sent inside ID Payload.
+Note that all ID's sent in arguments are sent inside ID Payload. Also
+note that all passphrases that may be sent inside arguments MUST be
+UTF-8 [RFC2279] encoded.
+
+
.in 6
0 SILC_NOTIFY_TYPE_NONE
usually is Client ID but it can be Server ID and Channel ID as well.
+
+
6 SILC_NOTIFY_TYPE_NICK_CHANGE
Sent when client changes nick on a channel. The server MUST
receiving the packet distributes this type to the local clients
on the channel and broadcast it to the network.
- Max Arguments: 2
+ Max Arguments: 3
Arguments: (1) <Old Client ID> (2) <New Client ID>
+ (3) <nickname>
The <Old Client ID> is the old ID of the client which changed
the nickname. The <New Client ID> is the new ID generated by
- the change of the nickname.
+ the change of the nickname. The <nickname> is the new nickname.
+ Note that it is possible to send this notify even if the nickname
+ has not changed, but client ID has changed.
7 SILC_NOTIFY_TYPE_CMODE_CHANGE
to the clients which is joined on the channel which mode was
changed.
- Max Arguments: 5
+ Max Arguments: 6
Arguments: (1) <ID Payload> (2) <mode mask>
(3) [<cipher>] (4) <[hmac>]
- (5) [<passphrase>]
+ (5) [<passphrase>] (6) [<founder 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
packet will force the new channel key change anyway. The <hmac>
argument is important since the client is responsible of setting
the new HMAC and the hmac key into use. The <passphrase> is
- the passphrase of the channel, if it was now set.
+ the passphrase of the channel, if it was now set. The <founder
+ public key> argument is sent when the founder mode on the
+ channel was set. All routers and servers that receive the packet
+ MUST save the founder's public key so that the founder can
+ reclaim the channel founder rights back for the channel on any
+ server in the network.
+
+
8 SILC_NOTIFY_TYPE_CUMODE_CHANGE
sent only to the clients which is joined on the channel where
the target client is on.
- Max Arguments: 3
- Arguments: (1) <ID Payload> (2) <mode mask>
- (3) <Target Client ID>
+ Max Arguments: 4
+ Arguments: (1) <ID Payload> (2) <mode mask>
+ (3) <Target Client ID> (3) [<founder pubkey>]
The <ID Payload> is the ID (usually Client ID but it can be
Server ID as well when the router is enforcing user's mode
change) of the entity which changed the mode. The <mode mask>
is the new mode mask of the channel. The <Target Client ID>
- is the client which mode was changed.
+ is the client which mode was changed. The <founder pubkey>
+ is the public key of the channel founder and is sent only
+ when first setting the channel founder mode using the
+ SILC_COMMAND_CUMODE command, and when sending this notify.
9 SILC_NOTIFY_TYPE_MOTD
Channel ID> is the new one that MUST replace the old one.
+
+
11 SILC_NOTIFY_TYPE_SERVER_SIGNOFF
Sent when server quits SILC network. Those clients from this
or server receiving the packet distributes this type to the local
clients on the channel and broadcast it to the network.
- Max Arguments: 2
- Arguments: (1) <Client ID> (2) [<comment>]
+ Max Arguments: 3
+ Arguments: (1) <Client ID> (2) [<comment>]
+ (3) <Killer's ID>
The <Client ID> is the client which was killed from the network.
The killer may have set the <comment> to indicate the reason for
- the killing.
+ the killing. The <Killer's ID> is the killer, which may be
+ client but also router server.
14 SILC_NOTIFY_TYPE_UMODE_CHANGE
<removing client> is defined in the [SILC4] with SILC_COMMAND_BAN
command.
+
+16 SILC_NOTIFY_TYPE_ERROR
+
+ Sent when an error occurs during processing some SILC procedure.
+ This is not used when error occurs during command processing, see
+ [SILC3] for more information about commands and command replies.
+ This type is sent directly to the sender of the packet whose packet
+ caused the error. See [SILC1] for definition when this type
+ can be sent.
+
+ Max Arguments: 256
+ Arguments: (1) <Status Type> (n) [...]
+
+ The <Status Type> is the error type defined in [SILC3]. Note that
+ same types are also used with command replies to indicate the
+ status of a command. Both commands and this notify type share
+ same status types. Rest of the arguments are status type
+ dependent and are specified with those status types that can be
+ sent currently inside this notify type in [SILC3]. The <Status
+ Type> is of size of 1 byte.
+
+
+17 SILC_NOTIFY_TYPE_WATCH
+
+ Sent to indicate change in a watched user. Client can set
+ nicknames to be watched with SILC_COMMAND_WATCH command, and
+ receive notifications when they login to network, signoff from
+ the network or their user mode is changed. This notify type
+ is used to deliver these notifications. The notify type is
+ sent directly to the watching client.
+
+ Max Arguments: 4
+ Arguments: (1) <Client ID> (2) [<nickname>]
+ (3) <user mode> (4) [<Notify Type>]
+
+ The <Client ID> is the user's Client ID which is being watched,
+ and the <nickname> is its nickname. If the client just
+ changed the nickname, then <nickname> is the new nickname, but
+ the <Client ID> is the old client ID. The <user mode> is the
+ user's current user mode. The <Notify Type> can be same as the
+ Notify Payload's Notify Type, and is 16 bit MSB first order value.
+ If provided it may indicate the notify that occurred for the
+ client. If client logged in to the network the <Notify Type>
+ MUST NOT be present.
.in 3
Notify types starting from 16384 are reserved for private notify
message types.
+Router server which receives SILC_NOTIFY_TYPE_SIGNOFF,
+SILC_NOTIFY_TYPE_SERVER_SIGNOFF, SILC_NOTIFY_TYPE_KILLED,
+SILC_NOTIFY_TYPE_NICK_CHANGE and SILC_NOTIFY_TYPE_UMODE_CHANGE
+MUST check whether someone in the local cell is watching the nickname
+the client has, and send the SILC_NOTIFY_TYPE_WATCH notify to the
+watcher, unless the client in case has the SILC_UMODE_REJECT_WATCHING
+user mode set. If the watcher client and the client that was
+watched is same the notify SHOULD NOT be sent.
+
+
+
.ti 0
2.3.8 Error Payload
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Flags | Message Length |
+| Message Flags | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Data ~
.in 6
-o Flags (2 bytes) - Includes the flags of the channel
- messages. The flags can indicate a reason or purpose
- for the channel message. Note that the Private Message
- Payload use these same flags for the same purpose. The
- following flags are defined:
+o Message Flags (2 bytes) - Includes the Message Flags of
+ the channel messages. The flags can indicate a reason or
+ purpose for the channel message. Note that the Private
+ Message Payload use these same Message Flags for the same
+ purpose. The following Message Flags are defined:
0x0000 SILC_MESSAGE_FLAG_NONE
of the signing process and any associated payloads
of this flag.
- 0x0040 - 0x0200 RESERVED
+ 0x0040 SILC_MESSAGE_FLAG_REPLY
+
+ This is a generic reply flag to send a reply to
+ previously received request. A separate document
+ should define any payloads associated to this flag.
+
+ 0x0080 SILC_MESSAGE_FLAG_DATA
+
+ This is a generic data flag, indicating that the
+ message includes some data which can be interpreted
+ in a specific way. Using this flag any kind of data
+ can be delivered inside message payload. A separate
+ document should define how this flag is interpreted
+ and define any associated payloads.
+
+ 0x0100 - 0x0800 RESERVED
Reserved for future flags
- 0x0400 - 0x8000 PRIVATE RANGE
+ 0x1000 - 0x8000 PRIVATE RANGE
Private range for free use.
o Message Length (2 bytes) - Indicates the length of the
- 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 to
other parts of the packet.
o MAC (variable length) - The MAC computed from the
- Message Length, Message Data, Padding Length and Padding
- fields. This protects the integrity of the plaintext
- channel message. The receiver can verify from the MAC
- whether the message decrypted correctly. Also, if more than
- one private key has been set for the channel, the receiver
- can verify which of the keys decrypted the message
- correctly. Note that, this field is encrypted and MUST
- be added to the padding calculation.
+ Message Flags, Message Length, Message Data, Padding Length,
+ Padding and Initial Vector fields in that order. This
+ protects the integrity of the plaintext channel message.
+ The receiver can verify from the MAC whether the message
+ decrypted correctly. Also, if more than one private key
+ has been set for the channel, the receiver can verify which
+ of the keys decrypted the message correctly. Note that,
+ this field is encrypted and MUST be added to the padding
+ calculation.
o Initial Vector (variable length) - The initial vector
that has been used in packet encryption. It needs to be
used in the packet decryption as well. What this field
includes is implementation issue. However, it is
- RECOMMENDED that it would be random data or, perhaps,
+ RECOMMENDED that it would be random data, or perhaps
a timestamp. It is NOT RECOMMENDED to use zero (0) as an
initial vector. This field is not encrypted. This field
is not included into the padding calculation. Length
of this field equals the cipher's block size. This field
- is, however, authenticated.
+ is, however authenticated.
.in 3
diagram represents the Private Message Payload.
-
-
-
-
-
-
.in 5
.nf
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Flags | Message Data Length |
+| Message Flags | Message Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Data ~
.in 6
-o Flags (2 bytes) - This field includes the flags of the
- private message. They can indicate a different reason or
- purpose for the private message. See the section 2.3.9
- Channel Message Payload for defined flags. Note that
+o Message Flags (2 bytes) - This field includes the Message
+ Flags of the private message. They can indicate a different
+ reason or purpose for the private message. See the section
+ 2.3.9 Channel Message Payload for defined flags. Note that
the Channel Message Payload use the same flags for the
same purpose.
.ti 0
2.3.12 Private Message Key Payload
-This payload is used to send key from client to another client that
-is going to be used to protect the private messages between these
-two clients. If this payload is not sent normal session key
-established by the SILC Key Exchange Protocol is used to protect
-the private messages.
+This payload is optional and can be used to send private message
+key between two clients in the network. The packet is secured with
+normal session keys. By default private messages are encrypted
+with session keys, and with this payload it is possible to set
+private key for private message encryption between two clients.
+
+The receiver of this payload SHOULD verify for example from user
+whether user wants to receive private message key. Note that there
+are other, more secure ways of exchanging private message keys in
+the SILC network. Instead of sending this payload it is possible to
+negotiate the private message key with SKE protocol using the Key
+Agreement payload directly peer to peer.
This payload may only be sent by client to another client. Server
MUST NOT send this payload at any time. After sending this payload
.in 3
+
+
.ti 0
2.3.16 New ID Payload
represents the New Client Payload.
-
-
-
-
-
-
-
-
-
-
-
.in 5
.nf
1 2 3
-
-
.in 5
.nf
1 2 3
The payload may only be sent with SILC_PACKET_FTP packet. It MUST NOT
be sent in any other packet type. The following diagram represents the
-File Transfer Payload
+File Transfer Payload.
.in 5
.nf
.in 3
+.ti 0
+2.3.23 Resume Client Payload
+
+This payload is used by client to resume its detached session in the
+SILC Network. A client is able to detach itself from the network by
+sending SILC_COMMAND_DETACH command to its server. The network
+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 uses to verify with
+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,
+without the Authentication Payload, to routers in the network so that
+they know the detached client has resumed. Refer to the [SILC1] for
+detailed description how the detaching and resuming procedure is
+performed.
+
+The payload may only be sent with SILC_PACKET_RESUME CLIENT packet. It
+MUST NOT be sent in any other packet type. The following diagram
+represents the Resume Client Payload.
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Client ID Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Client ID ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Authentication Payload ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 24: Resume Client Payload
+
+
+.in 6
+o Client ID Length (1 byte) - The length of the Client ID
+ field not including any other field.
+
+o Client ID (variable length) - The detached client's Client
+ ID. The client that sends this payload must know the Client
+ ID.
+
+o Authentication Payload (variable length) - The authentication
+ payload that the server will verify with the detached client's
+ public key. If the server doesn't know the public key, it must
+ retrieve it for example with SILC_COMMAND_GETKEY command.
+.in 3
+
.ti 0
the packet is received and decrypted the data area MUST be decompressed.
Note that the true sender of the packet MUST apply the compression and
the true receiver of the packet MUST apply the decompression. Any
-server or router en route MUST NOT decompress the packet.
+server or router en route SHOULD NOT decompress the packet.
.ti 0
However, there are some issues when routing channel messages to group
of users. Routers are responsible of routing the channel message to
other routers, local servers and local clients as well. Routers MUST
-send the channel message to only one router in the network, preferrably
+send the channel message to only one router in the network, preferably
to the shortest route to reach the channel users. The message can be
routed into either upstream or downstream. After the message is sent
to a router in the network it MUST NOT be sent to any other router in
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 counter clock-wise direction,
-or if it cannot be used then always clock-wise (primary route) direction.
+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
in upstream or downstream, they cannot be routed to other direct routes.
4 References
[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
- Protocol Specification", Internet Draft, April 2001.
+ Protocol Specification", Internet Draft, May 2002.
[SILC3] Riikonen, P., "SILC Key Exchange and Authentication
- Protocols", Internet Draft, April 2001.
+ Protocols", Internet Draft, May 2002.
-[SILC4] Riikonen, P., "SILC Commands", Internet Draft, April 2001.
+[SILC4] Riikonen, P., "SILC Commands", Internet Draft, May 2002.
[IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
RFC 1459, May 1993.
[SFTP] Ylonen T., and Lehtinen S., "Secure Shell File Transfer
Protocol", Internet Draft, March 2001.
+[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
.ti 0
5 Author's Address
.nf
Pekka Riikonen
-Snellmanninkatu 34 A 15
+Snellmaninkatu 34 A 15
70100 Kuopio
Finland
-EMail: priikone@silcnet.org
+EMail: priikone@iki.fi
-This Internet-Draft expires XXX
+This Internet-Draft expires 15 November 2002
projects / silc.git / blobdiff