6 Author's Address
Pekka Riikonen
-Snellmanninkatu 34 A 15
+Snellmaninkatu 34 A 15
70100 Kuopio
Finland
The server also returns client's user mode, idle time, and the
fingerprint of the client's public key. The <fingerprint> is the
binary hash digest of the public key. The fingerprint MUST NOT
- be sent if the server has not verified the proof of posession of
+ be sent if the server has not verified the proof of possession of
the corresponding private key. Server can do this during the
SILC Key Exchange protocol. The <fingerprint> is SHA1 digest.
of a channel. Modes may be masked together by ORing them thus
having several modes set. The <Channel ID> is the ID of the
target channel. The client changing channel mode MUST be on
- the same channel and poses sufficient privileges to be able to
+ the same channel and posses sufficient privileges to be able to
change the mode.
When the mode is changed SILC_NOTIFY_TYPE_CMODE_CHANGE notify
The <Channel ID> is the ID of the target channel. The <mode mask>
is OR'ed mask of modes. The <Client ID> is the target client.
The client changing channel user modes MUST be on the same channel
- as the target client and poses sufficient privileges to be able to
+ as the target client and posses sufficient privileges to be able to
change the mode.
When the mode is changed SILC_NOTIFY_TYPE_CUMODE_CHANGE notify
.nf
Pekka Riikonen
-Snellmanninkatu 34 A 15
+Snellmaninkatu 34 A 15
70100 Kuopio
Finland
.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-flags-payloads-00.txt XXX
-Expires: XXX
+draft-riikonen-flags-payloads-00.txt 15 May 2002
+Expires: 15 November 2002
.in 3
-.ce 3
+.ce 2
SILC Message Flag Payloads
<draft-riikonen-flags-payloads-00.txt>
Table of Contents
.nf
-1 Introduction .................................................. x
- 1.1 Requirements Terminology .................................. x
-2 SILC Message Flags ............................................ x
-3 SILC Message Flag Payloads .................................... x
- 3.1 SILC_MESSAGE_FLAG_REQUEST ................................. x
- 3.2 SILC_MESSAGE_FLAG_REPLY ................................... x
- 3.3 SILC_MESSAGE_FLAG_SIGNED .................................. x
- 3.4 SILC_MESSAGE_FLAG_DATA .................................... x
-4 Security Considerations ....................................... x
-5 References .................................................... x
-6 Author's Address .............................................. x
+1 Introduction .................................................. 2
+ 1.1 Requirements Terminology .................................. 2
+2 SILC Message Flags ............................................ 2
+3 SILC Message Flag Payloads .................................... 3
+ 3.1 SILC_MESSAGE_FLAG_REQUEST ................................. 3
+ 3.2 SILC_MESSAGE_FLAG_REPLY ................................... 3
+ 3.3 SILC_MESSAGE_FLAG_SIGNED .................................. 4
+ 3.4 SILC_MESSAGE_FLAG_DATA .................................... 4
+4 Security Considerations ....................................... 5
+5 References .................................................... 5
+6 Author's Address .............................................. 6
.ti 0
flag that defines some generic way of sending any kind of data as a
message, and that it can be easily interpreted at the receiver's end is
important. For this reason the flag SILC_MESSAGE_FLAG_DATA was added to
-the protocol which can represent any data. This memo desribes how this
+the protocol which can represent any data. This memo describe how this
flag is used and how the associated payload is constructed and processed.
This memo also describes payloads for all the other flags that can have
associated payloads.
6 Author's Address
Pekka Riikonen
-Snellmanninkatu 34 A 15
+Snellmaninkatu 34 A 15
70100 Kuopio
Finland
EMail: priikone@iki.fi
-This Internet-Draft expires XXX
+This Internet-Draft expires 15 November 2002
.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-ke-auth-05.txt XXX
-Expires: XXX
+draft-riikonen-silc-ke-auth-05.txt 15 May 2002
+Expires: 15 November 2002
.in 3
2.1.2 Key Exchange Payload ................................ 8
2.2 Key Exchange Procedure .................................... 10
2.3 Processing the Key Material ............................... 12
- 2.4 SILC Key Exchange Groups .................................. 13
+ 2.4 SILC Key Exchange Groups .................................. 14
2.4.1 diffie-hellman-group1 ............................... 14
2.4.2 diffie-hellman-group2 ............................... 14
2.5 Key Exchange Status Types ................................. 15
3.1 Connection Auth Payload ................................... 18
3.2 Connection Authentication Types ........................... 19
3.2.1 Passphrase Authentication ........................... 19
- 3.2.2 Public Key Authentication ........................... 19
+ 3.2.2 Public Key Authentication ........................... 20
3.3 Connection Authentication Status Types .................... 20
-4 Security Considerations ....................................... 20
-5 References .................................................... 20
+4 Security Considerations ....................................... 21
+5 References .................................................... 21
6 Author's Address .............................................. 22
The SILC Connection Authentication protocol provides user level
authentication used when creating connections in SILC network. The
protocol is transparent to the authentication data which means that it
-can be used to authenticate the user with, for example, pass phrase
+can be used to authenticate the user with, for example, passphrase
(pre-shared- secret) or public key (and certificate).
The basis of secure SILC session requires strong and secure key exchange
Following diagram represents the Key Exchange Start Payload. The lists
mentioned below are always comma (`,') separated and the list MUST NOT
-include spaces (` ').
+include white spaces (` ').
.in 5
for the connecting entity is not based on public key authentication (it
is based on passphrase) then the Mutual Authentication flag SHOULD be
enabled. This way the connecting entity has to provide proof of
-posession of the private key for the public key it will provide in
+possession of the private key for the public key it will provide in
SILC Key Exchange protocol.
When performing re-key with PFS selected this is the only payload that
The length of this group is 1536 bits. This is OPTIONAL group.
The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
+
+
+
Its decimal value is
.in 6
packet.
+
.ti 0
3.2.2 Public Key Authentication
The length of status is 32 bits (4 bytes). The following status types
are defined:
-
-
0 SILC_AUTH_OK
Protocol was executed successfully.
Authentication failed.
+
+
.ti 0
4 Security Considerations
security of this protocol.
+
.ti 0
5 References
.nf
Pekka Riikonen
-Snellmanninkatu 34 A 15
+Snellmaninkatu 34 A 15
70100 Kuopio
Finland
EMail: priikone@iki.fi
-This Internet-Draft expires XXX
+This Internet-Draft expires 15 November 2002
.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.3.23 Resume Client Payload .............................. XXXXXX
- 2.4 SILC ID Types ............................................. 46
- 2.5 Packet Encryption And Decryption .......................... 46
- 2.5.1 Normal Packet Encryption And Decryption ............. 46
- 2.5.2 Channel Message Encryption And Decryption ........... 47
- 2.5.3 Private Message Encryption And Decryption ........... 48
- 2.6 Packet MAC Generation ..................................... 48
- 2.7 Packet Padding Generation ................................. 49
- 2.8 Packet Compression ........................................ 50
- 2.9 Packet Sending ............................................ 50
- 2.10 Packet Reception ......................................... 51
- 2.11 Packet Routing ........................................... 51
- 2.12 Packet Broadcasting ...................................... 52
-3 Security Considerations ....................................... 53
-4 References .................................................... 53
-5 Author's Address .............................................. 54
+ 2.3.7 Notify Payload ...................................... 23
+ 2.3.8 Error Payload ....................................... 31
+ 2.3.9 Channel Message Payload ............................. 31
+ 2.3.10 Channel Key Payload ................................ 35
+ 2.3.11 Private Message Payload ............................ 36
+ 2.3.12 Private Message Key Payload ........................ 38
+ 2.3.13 Command Payload .................................... 39
+ 2.3.14 Command Reply Payload .............................. 40
+ 2.3.15 Connection Auth Request Payload .................... 40
+ 2.3.16 New ID Payload ..................................... 42
+ 2.3.17 New Client Payload ................................. 42
+ 2.3.18 New Server Payload ................................. 43
+ 2.3.19 New Channel Payload ................................ 44
+ 2.3.20 Key Agreement Payload .............................. 45
+ 2.3.21 Resume Router Payload .............................. 46
+ 2.3.22 File Transfer Payload .............................. 46
+ 2.3.23 Resume Client Payload .............................. 48
+ 2.4 SILC ID Types ............................................. 49
+ 2.5 Packet Encryption And Decryption .......................... 49
+ 2.5.1 Normal Packet Encryption And Decryption ............. 50
+ 2.5.2 Channel Message Encryption And Decryption ........... 50
+ 2.5.3 Private Message Encryption And Decryption ........... 51
+ 2.6 Packet MAC Generation ..................................... 52
+ 2.7 Packet Padding Generation ................................. 52
+ 2.8 Packet Compression ........................................ 53
+ 2.9 Packet Sending ............................................ 53
+ 2.10 Packet Reception ......................................... 54
+ 2.11 Packet Routing ........................................... 54
+ 2.12 Packet Broadcasting ...................................... 55
+3 Security Considerations ....................................... 56
+4 References .................................................... 56
+5 Author's Address .............................................. 58
.ti 0
List of Figures
protocol that assures that the contents of the packets are secured and
authenticated. The packet protocol is designed to be compact to avoid
unnecessary overhead as much as possible. This makes the SILC suitable
-also in environment of low bandwith requirements such as mobile networks.
+also in environment of low bandwidth requirements such as mobile networks.
All packet payloads can also be compressed to further reduce the size
of the packets.
Marks that the payload of the packet is compressed.
The sender of the packet marks this flag when it
compresses the payload, and any server or router
- en route to the receipient MUST NOT unset this flag.
+ en route to the recipient MUST NOT unset this flag.
See section 2.8 Packet Compression for description of
packet compressing.
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
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
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
server in the network.
+
+
8 SILC_NOTIFY_TYPE_CUMODE_CHANGE
Sent when user mode on channel has changed. This type MUST be
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
Router server which receives SILC_NOTIFY_TYPE_SIGNOFF,
SILC_NOTIFY_TYPE_SERVER_SIGNOFF, SILC_NOTIFY_TYPE_KILLED,
SILC_NOTIFY_TYPE_NICK_CHANGE and SILC_NOTIFY_TYPE_UMODE_CHANGE
-MUST chech whether someone in the local cell is watching the nickname
+MUST check whether someone in the local cell is watching the nickname
the client has, and send the SILC_NOTIFY_TYPE_WATCH notify to the
watcher, unless the client in case has the SILC_UMODE_REJECT_WATCHING
user mode set. If the watcher client and the client that was
watched is same the notify SHOULD NOT be sent.
+
+
.ti 0
2.3.8 Error Payload
diagram represents the Private Message Payload.
-
-
-
-
-
-
.in 5
.nf
1 2 3
.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
Server or router that receives this from the client also sends this,
without the Authentication Payload, to routers in the network so that
they know the detached client has resumed. Refer to the [SILC1] for
-detailed description how the detaching and resuming prodecure is
+detailed description how the detaching and resuming procedure is
performed.
The payload may only be sent with SILC_PACKET_RESUME CLIENT packet. It
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
.nf
Pekka Riikonen
-Snellmanninkatu 34 A 15
+Snellmaninkatu 34 A 15
70100 Kuopio
Finland
EMail: priikone@iki.fi
-This Internet-Draft expires XXX
+This Internet-Draft expires 15 November 2002
.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-spec-05.txt XXX
-Expires: XXX
+draft-riikonen-silc-spec-05.txt 15 May 2002
+Expires: 15 November 2002
.in 3
3.2.2 Server ID ........................................... 11
3.2.3 SILC Server Ports ................................... 12
3.3 Router .................................................... 12
- 3.3.1 Router's Local ID List .............................. 12
+ 3.3.1 Router's Local ID List .............................. 13
3.3.2 Router's Global ID List ............................. 13
3.3.3 Router's Server ID .................................. 14
3.4 Channels .................................................. 14
- 3.4.1 Channel ID .......................................... 16
+ 3.4.1 Channel ID .......................................... 15
3.5 Operators ................................................. 16
3.6 SILC Commands ............................................. 16
3.7 SILC Packets .............................................. 17
3.8 Packet Encryption ......................................... 17
- 3.8.1 Determination of the Source and the Destination ..... 17
+ 3.8.1 Determination of the Source and the Destination ..... 18
3.8.2 Client To Client .................................... 18
- 3.8.3 Client To Channel ................................... 19
+ 3.8.3 Client To Channel ................................... 20
3.8.4 Server To Server .................................... 20
3.9 Key Exchange And Authentication ........................... 20
- 3.9.1 Authentication Payload .............................. 20
- 3.10 Algorithms ............................................... 22
- 3.10.1 Ciphers ............................................ 22
- 3.10.2 Public Key Algorithms .............................. 23
+ 3.9.1 Authentication Payload .............................. 21
+ 3.10 Algorithms ............................................... 23
+ 3.10.1 Ciphers ............................................ 23
+ 3.10.2 Public Key Algorithms .............................. 24
3.10.3 Hash Functions ..................................... 24
- 3.10.4 MAC Algorithms ..................................... 24
+ 3.10.4 MAC Algorithms ..................................... 25
3.10.5 Compression Algorithms ............................. 25
- 3.11 SILC Public Key .......................................... 25
- 3.12 SILC Version Detection ................................... 27
+ 3.11 SILC Public Key .......................................... 26
+ 3.12 SILC Version Detection ................................... 28
3.13 Backup Routers ........................................... 28
- 3.13.1 Switching to Backup Router ......................... 29
- 3.13.2 Resuming Primary Router ............................ 30
- 3.13.3 Discussion on Backup Router Scheme ................. 32
-4 SILC Procedures ............................................... 33
- 4.1 Creating Client Connection ................................ 33
- 4.2 Creating Server Connection ................................ 34
- 4.2.1 Announcing Clients, Channels and Servers ............ 35
- 4.3 Joining to a Channel ...................................... 36
- 4.4 Channel Key Generation .................................... 37
- 4.5 Private Message Sending and Reception ..................... 38
- 4.6 Private Message Key Generation ............................ 38
- 4.7 Channel Message Sending and Reception ..................... 39
- 4.8 Session Key Regeneration .................................. 39
- 4.9 Command Sending and Reception ............................. 40
- 4.10 Closing Connection ....................................... 41
- 4.11 Detaching and Resuming a Session ......................... XXXXX
-5 Security Considerations ....................................... 41
-6 References .................................................... 42
-7 Author's Address .............................................. 44
+ 3.13.1 Switching to Backup Router ......................... 30
+ 3.13.2 Resuming Primary Router ............................ 31
+ 3.13.3 Discussion on Backup Router Scheme ................. 33
+4 SILC Procedures ............................................... 34
+ 4.1 Creating Client Connection ................................ 34
+ 4.2 Creating Server Connection ................................ 35
+ 4.2.1 Announcing Clients, Channels and Servers ............ 36
+ 4.3 Joining to a Channel ...................................... 37
+ 4.4 Channel Key Generation .................................... 38
+ 4.5 Private Message Sending and Reception ..................... 39
+ 4.6 Private Message Key Generation ............................ 39
+ 4.7 Channel Message Sending and Reception ..................... 40
+ 4.8 Session Key Regeneration .................................. 40
+ 4.9 Command Sending and Reception ............................. 41
+ 4.10 Closing Connection ....................................... 42
+ 4.11 Detaching and Resuming a Session ......................... 42
+5 Security Considerations ....................................... 44
+6 References .................................................... 45
+7 Author's Address .............................................. 47
not equivalent to IRC and does not support IRC. Some of the SILC's
features are not found in IRC but in traditional Instant Message (IM)
protocols. SILC combines features from both of these chat protocol
-styles, and SILC can be implemeneted as either IRC-like system or
+styles, and SILC can be implemented as either IRC-like system or
IM-like system.
Strong cryptographic methods are used to protect SILC packets inside
document and protocol. [SILC2] also describes the packet encryption
and decryption in detail. The SILC Packet Protocol provides secured
and authenticated packets, and the protocol is designed to be compact.
-This makes SILC also suitable in environment of low bandwith
+This makes SILC also suitable in environment of low bandwidth
requirements such as mobile networks. All packet payloads in SILC
can be also compressed.
are in the center of the cell and servers are connected to the router.
-
-
-
-
-
The following diagram represents SILC network topology.
.in 8
represents message sending between cells.
+
+
+
.in 16
.nf
1 --- S1 S4 --- 5 S2 --- 1
must not routers use each other as their primary routes. The router
connections in the network must form a ring.
-
-
-
-
-
-
Example with three routers in the network:
Also, if any other router in the network is using the cell's primary
router as its own primary router, it must also have passive connection
to the cell's backup router. It too is prepared to switch to use the
-backup router as its new primary router as soon as the orignal primary
+backup router as its new primary router as soon as the original primary
router becomes unresponsive.
All of the parties of this protocol knows which one is the backup router
backup router. The backup router usually needs to do local modifications
to its database in order to update all the information needed to maintain
working routes. The backup router must understand that clients that
-were orignated from the primary router are now originated from some of
+were originated from the primary router are now originated from some of
the existing server connections and must update them accordingly. It
must also remove those clients that were owned by the primary router
since those connections were lost when the primary router became
3.13.2 Resuming Primary Router
Usually the primary router is unresponsive only a short period of time
-and it is intended that the original router of the cell will reassume
+and it is intended that the original router of the cell will resume
its position as primary router when it comes back online. The backup
router that is now acting as primary router of the cell must constantly
try to connect to the original primary router of the cell. It is
3.13.3 Discussion on Backup Router Scheme
It is clear that this backup router support is not able to handle all
-possible situations arrising in unreliable network environment. This
+possible situations arising in unreliable network environment. This
scheme for example does not handle situation when the router actually
does not go offline but the network link goes down temporarily. It would
require some intelligence to figure out when it is best time to switch
it should have cached the Client ID from the SILC Packet Header.
If server receives a private message packet which includes invalid
-destionation Client ID the server MUST send SILC_NOTIFY_TYPE_ERROR
+destination Client ID the server MUST send SILC_NOTIFY_TYPE_ERROR
notify to the client with error status indicating that such Client ID
does not exist.
channel message destined explicitly to a client on the channel.
If server receives a channel message packet which includes invalid
-destionation Channel ID the server MUST send SILC_NOTIFY_TYPE_ERROR
+destination Channel ID the server MUST send SILC_NOTIFY_TYPE_ERROR
notify to the sender with error status indicating that such Channel ID
does not exist.
-See the [SILC2] for description of channel messege routing for router
+See the [SILC2] for description of channel message routing for router
servers, and channel message encryption and decryption process.
are running the service. It is recommended that some form of registration
is required by the server and router administrator prior acceptance to
the SILC Network. Even though, the SILC protocol is secure in a network
-of mutual distrust between clients, servers, routers and adminstrators
+of mutual distrust between clients, servers, routers and administrators
of the servers, the client should be able to trust the servers they are
-using if they whish to do so.
+using if they wish to do so.
It however must be noted that if the client requires absolute security
by not trusting any of the servers or routers in the SILC Network, it can
messages, private messages and channel messages.
It is important to note that SILC, like any other security protocol is
-not full proof system and cannot secure from insecure environment; the
-SILC servers and routers could very well be compromised. However, to
-provide acceptable level of security and usability for end user the
-protocol use many times session keys or other keys generated by the
-servers to secure the messages. This is intentional design feature to
-allow ease of use for end user. This way the network is still usable,
-and remains encrypted even if the external means of distributing the
-keys is not working. The implementation, however, may like to not
-follow this design feature, and always negotiate the keys outside SILC
-network. This is acceptable solution and many times recommended. The
-implementation still must be able to work with the server generated keys.
+not full proof system; the SILC servers and routers could very well be
+compromised. However, to provide acceptable level of security and
+usability for end user the protocol use many times session keys or other
+keys generated by the servers to secure the messages. This is
+intentional design feature to allow ease of use for end user. This way
+the network is still usable, and remains encrypted even if the external
+means of distributing the keys is not working. The implementation,
+however, may like to not follow this design feature, and always negotiate
+the keys outside SILC network. This is acceptable solution and many times
+recommended. The implementation still must be able to work with the
+server generated keys.
If this is unacceptable for the client or end user, the private keys
-negotiatied outside the SILC Network should always be used. In the end
+negotiated outside the SILC Network should always be used. In the end
it is always implementor's choice whether to negotiate private keys by
default or whether to use the keys generated by the servers.
.nf
Pekka Riikonen
-Snellmanninkatu 34 A 15
+Snellmaninkatu 34 A 15
70100 Kuopio
Finland
EMail: priikone@iki.fi
-This Internet-Draft expires XXX
+This Internet-Draft expires 15 November 2002
projects / crypto.git / commitdiff